小服务器备份别只靠手动：rsync + cron 做每日增量备份

很多小服务器的备份都靠手动：想起来就拷一份，忙起来就拖一周。结果往往是三个痛点一起出现。第一是忘记，备份全凭记忆，没有固定节奏，恰恰在最需要恢复的那天发现上次备份是几个月前。第二是拷错，手动复制容易选错目录、漏掉配置文件，或者把正在写入的文件直接拷走，备份看起来有，恢复时却打不开。第三是覆盖旧版，只保留一份最新拷贝，一旦新版本本身有问题，或者误删后又被同步覆盖，连回退的余地都没有。解决办法不是买更贵的工具，而是把备份变成每天自动、带版本、可验证的固定流程，rsync 加 cron 就够了。

第一步，先做一次全量同步。假设网站和配置都在 /data/www，备份盘挂载在 /backup，命令可以这样写：rsync -av --delete /data/www/ /backup/www-full/。这里 -a 是归档模式，会尽量保留权限、时间戳、属主和符号链接等信息，适合做系统级备份；-v 是输出详细过程，方便在日志里看到传了哪些文件；--delete 是让目标端删除源端已经不存在的文件，保持两者一致。第一次跑完后，/backup/www-full 就是一份可直接用的完整副本。需要注意，--delete 很强，源目录一旦被误删，同步后目标端也会跟着删，所以它只适合配合后面的快照使用，不能只靠这一份。

第二步，用 --link-dest 做带日期的增量快照。思路是每天新建一个以日期命名的目录，但没有变化的文件不重复占空间，而是通过硬链接指向上一天的同一份文件。命令示例：rsync -av --delete --link-dest=/backup/www-full /data/www/ /backup/daily/$(date +%F)/。第一次可以把 www-full 作为基准，之后每天都以上一天的快照为基准。看起来每天都有一份完整目录，实际上新增的磁盘占用只有当天改动过的文件。再加一个简单的 7 天轮转，例如只保留最近 7 个日期目录，超过的删除：find /backup/daily -maxdepth 1 -type d -mtime +7 -exec rm -rf {} +。这样既能按日期回退，也不会让备份盘无限增长。

第三步，把命令交给 cron，每天凌晨 2 点自动跑。编辑定时任务：crontab -e，然后加入一行：0 2 * * * /usr/bin/rsync -av --delete --link-dest=/backup/www-full /data/www/ /backup/daily/$(date +\%F)/ >> /var/log/backup.log 2>&1。凌晨 2 点通常是业务低峰，干扰小。输出重定向到日志很关键，否则成功失败都无从查起。cron 里要写 rsync 的绝对路径，并且把日期里的百分号转义，否则 cron 会把 % 当成换行处理。设好后第二天先看日志，确认没有报错，再看新日期目录是否生成，不要只凭感觉认为它在跑。

第四步，一定要做恢复演练。备份没有验证过，就等于没有备份。演练可以很轻：从某个历史快照目录里拷回一个文件到临时目录，打开确认内容和时间戳正确，例如 cp /backup/daily/2026-10-20/config/app.conf /tmp/restore-test/，然后 diff /tmp/restore-test/app.conf /data/www/config/app.conf。能成功拷回、内容一致，才算这条链路通了。还要记住两条避坑经验。第一，正式同步前先用 --dry-run 演练一次，看看它打算传什么、删什么，确认无误再去掉 --dry-run 真跑。第二，源目录尾部的斜杠含义不同，/data/www/ 表示同步目录里面的内容，而 /data/www 则可能在目标端多套一层 www 目录，写错一次，恢复时路径就全乱了。最后，重要数据不要只放在同一台机器的另一块盘上，有条件再异地存一份，比如另一台服务器或对象存储，这样即使整机故障，备份也不会一起丢失。

总结一句话：用 rsync 做全量加增量快照，用 cron 固定每天凌晨自动执行并记日志，再定期做一次恢复演练，小服务器的备份就能从靠运气变成靠流程。