VPS 定时任务怎么配（2026）：crontab 语法、systemd timer 与防重叠、失败通知

这条是 cron 里最反直觉的规则：

0 0 13 * 5    # 每月 13 号执行，「或者」每周五执行

不是"13 号且是周五"，而是满足任一条件就执行。想要"13 号且是周五"，只能在脚本里自己判断：

0 0 13 * *  [ "$(date +\%u)" = "5" ] && /srv/scripts/task.sh

注意上面的 \% —— 下面马上讲。

这是 crontab 里最常见的语法坑。 在 crontab 中，% 有特殊含义（表示换行，后面的内容会作为标准输入传给命令）。所以这样写是错的：

# ❌ 错误：% 被当成换行符，命令会被截断
0 3 * * * tar czf /backup/$(date +%F).tar.gz /srv/app

必须转义成 \%：

# ✅ 正确
0 3 * * * tar czf /backup/$(date +\%F).tar.gz /srv/app

更省事的做法是把命令写进脚本文件，crontab 里只调脚本 —— 脚本里的 % 不需要转义，而且复杂逻辑也好维护。这是我推荐的默认做法。

cron 执行任务时用的环境和你 SSH 登录时完全不同。它的 PATH 通常只有 /usr/bin:/bin，你在终端里能跑的命令，在 cron 里可能报 command not found。

三种处理方式，从好到差：

# 1. 脚本里用绝对路径（最稳）
/usr/bin/docker compose -f /srv/app/compose.yml up -d

# 2. crontab 顶部设 PATH
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
0 3 * * * docker compose -f /srv/app/compose.yml up -d

# 3. 脚本开头 source 环境（依赖 shell 配置，最不稳）

用 which docker 查绝对路径，然后写进脚本里。nvm 装的 node、pyenv 装的 python 尤其容易踩这个坑，因为它们的路径是在 shell 启动时才注入的。

默认情况下 cron 会把任务的输出通过邮件发给用户 —— 而 VPS 上通常没配邮件系统，结果就是输出丢失，或者堆在 /var/mail/ 里慢慢占空间。

# ✅ 正常输出和错误都写进日志
0 3 * * * /srv/scripts/backup.sh >> /var/log/backup.log 2>&1

# 只要错误，成功时不记
0 3 * * * /srv/scripts/backup.sh > /dev/null

# ❌ 全部丢弃 —— 出错了你永远不知道
0 3 * * * /srv/scripts/backup.sh > /dev/null 2>&1

2>&1 的位置很重要，必须在 >> 之后。写成 2>&1 >> file 的话，错误还是会输出到原来的地方。

日志文件会一直涨，记得配轮转（下面有）。

crontab -e          # 编辑当前用户的
crontab -l          # 查看
crontab -r          # 删除全部（危险，没有二次确认）
sudo crontab -e     # 编辑 root 的
sudo crontab -u www-data -e   # 编辑指定用户的

crontab -r 没有确认提示，手滑就全没了。 养成先 crontab -l > ~/crontab.bak 备份的习惯。

用户很关键：crontab -e 和 sudo crontab -e 编辑的是两份不同的任务表。任务没跑起来时，先确认你查的是不是编辑的那一份。

系统级的任务也可以直接放文件：

# /etc/cron.d/backup —— 注意这里多一个「用户」字段
0 3 * * * root /srv/scripts/backup.sh >> /var/log/backup.log 2>&1

/etc/cron.d/ 下的文件格式和 crontab -e 的不一样 —— 时间字段后面要多写一个执行用户。少写这个字段是另一个常见错误。

格式是 星期 年-月-日 时:分:秒，星期可省略。

还有一组简写（官方定义的等价形式）：

写完一定要验证，这个命令会告诉你接下来几次的实际触发时间：

systemd-analyze calendar "Mon..Fri *-*-* 09:00:00" --iterations=3

比起 cron 的"写完等明天看看跑没跑"，这是 systemd timer 的一大优势。

Persistent=true —— 把上次触发时间记在磁盘上。如果机器在计划时间处于关机状态，下次启动后会立即补跑一次。这是 cron 完全没有的能力（cron 只会错过就算了）。做备份这类任务时建议开。

RandomizedDelaySec=300 —— 在计划时间基础上随机延迟 0-300 秒。看起来没用，但如果你有多台机器在同一时刻跑备份、或者多个任务都定在整点，加上它能避免负载尖峰和请求撞车。

AccuracySec= —— 默认是 1 分钟，意味着任务可能在计划时间之后最多 1 分钟才触发。systemd 这么做是为了把多个定时器合并唤醒、省电。需要精确到秒就显式设置：

[Timer]
OnCalendar=*-*-* 03:00:00
AccuracySec=1s

很多人以为 systemd timer 和 cron 一样准时，实际默认不是 —— 这是"日志时间总是差几十秒"的原因。

# 列出所有定时器，包括下次触发时间和上次执行时间
systemctl list-timers --all

# 只看某一个
systemctl list-timers backup.timer

# 看执行日志（这是 systemd timer 最大的好处）
journalctl -u backup.service -n 50 --no-pager

# 手动触发一次测试（不用等到点）
sudo systemctl start backup.service

systemctl list-timers 应该是你配完之后的第一个动作 —— 它会直接显示 NEXT（下次触发）和 LAST（上次执行），一眼看出配得对不对。

#!/usr/bin/env bash
set -euo pipefail

• -e 出错就退出，别带着错误继续跑
• -u 用了未定义变量就报错
• -o pipefail 管道里任一环节失败就算失败

不加这些，脚本会"看起来成功"地做错事 —— 比如 mysqldump 失败了但后面的 gzip 照常执行，你得到一个空的备份文件，而且退出码是 0。

# ❌ 依赖当前目录和 PATH
cd app && ./backup.sh

# ✅
cd /srv/app || exit 1
/usr/bin/mysqldump ...

任务跑得比间隔还慢时，第二个实例会在第一个还没结束时启动 —— 两个 rsync 同时写一个目录，或者两个备份同时导数据库，结果都很难看。

cron 用 flock：

*/5 * * * * /usr/bin/flock -n /tmp/sync.lock /srv/scripts/sync.sh

-n 表示拿不到锁就直接退出（而不是排队等待）。锁文件在脚本结束时自动释放，就算脚本崩了也不会残留死锁。

systemd timer 默认就不会重叠 —— 如果上一次的 service 还在运行，这次触发会被跳过。这是它相对 cron 的一个实在优势。

log() { echo "[$(date '+%F %T')] $*"; }

log "backup started"
# ... 实际工作
log "backup finished, size=$(du -h "$DEST" | cut -f1)"

排查问题时，"这个任务昨天到底跑没跑、跑了多久"是最先要回答的问题。

任务静默失败是最糟的情况 —— 你以为备份了三个月，真要恢复时发现一个都没有。

#!/usr/bin/env bash
set -euo pipefail

notify_fail() {
    curl -fsS -X POST "https://your-webhook-url" \
        -d "text=backup.sh 失败，主机 $(hostname)，退出码 $?" || true
}
trap notify_fail ERR

# ... 实际工作

trap ... ERR 会在脚本出错时触发。webhook 可以用 Telegram Bot、飞书、Slack 或者任何能收 POST 的地方。末尾的 || true 别省 —— 通知本身失败时不要让脚本再次报错。

更完整的做法是用「死人开关」（healthchecks.io 这类）：任务成功时 ping 一下，长时间没收到 ping 就告警 —— 这样连"任务根本没触发"都能发现，比只在失败时通知更可靠。

#!/usr/bin/env bash
# /srv/scripts/backup-db.sh
set -euo pipefail

DEST=/srv/backups
KEEP_DAYS=14
STAMP=$(date +%F-%H%M)

mkdir -p "$DEST"

# --single-transaction 避免锁表
/usr/bin/mysqldump --single-transaction --quick \
    --databases myapp \
    | gzip > "$DEST/myapp-$STAMP.sql.gz"

# 校验产物不是空的
[ -s "$DEST/myapp-$STAMP.sql.gz" ] || { echo "backup is empty!"; exit 1; }

# 清理超过保留期的旧备份
find "$DEST" -name 'myapp-*.sql.gz' -mtime +$KEEP_DAYS -delete

30 3 * * * /srv/scripts/backup-db.sh >> /var/log/backup-db.log 2>&1

那行 [ -s ... ] 检查很重要 —— 没有它，mysqldump 权限不足时你会得到一堆 20 字节的"备份文件"，而且清理逻辑照常把旧的真备份删掉。

备份要传到别的地方，留在同一台机器上等于没备份。配合 rsync 推到另一台，或者传对象存储，做法见 VPS 文件传输指南。而且必须演练过恢复才算数，见 VPS 备份恢复演练。

# 每周日清理 30 天前的日志
0 4 * * 0 find /var/log/myapp -name '*.log' -mtime +30 -delete

但更好的做法是用 logrotate，它是专门干这个的，还能压缩和保留轮次：

# /etc/logrotate.d/myapp
/var/log/myapp/*.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    create 0640 www-data adm
}

logrotate 本身由系统的定时任务调用，不需要你另外配。

Docker 的日志是另一回事，见 Docker 占满磁盘怎么办。

certbot 装完就自带定时任务，不需要你自己写：

systemctl list-timers | grep certbot
sudo certbot renew --dry-run

自己加一条反而可能重复执行。要确认它真的在跑，用上面两条命令。续期失败的排查见 Let's Encrypt 证书续期失败怎么办。

不要在容器里装 cron。 容器的设计是一个进程一件事，塞个 cron 进去会让日志、信号处理、重启策略都变复杂。

正确做法是在宿主机上定时 exec 进去：

0 3 * * * /usr/bin/docker exec myapp-container /app/scripts/task.sh >> /var/log/task.log 2>&1

或者用 docker compose run --rm 起一个一次性容器跑任务。