小服务器备份别只靠定时任务：tar 全量 + rsync 增量的一次实操整理

前段时间帮朋友看一台小服务器，情况很典型：上面跑着一个小网站和数据库，运维同学很负责地写了条定时任务，每天凌晨把网站目录打包一份。听起来没问题，直到有一次磁盘报警，他顺手删了几个旧包，才发现近三个月的备份里有好几个是空的——打包时源目录权限报错，tar 中途退出了，cron 却照常返回了成功。那次之后，我把这台机器的备份重新理了一遍，思路就一句话：全量打底、增量跟进、定期验证，缺一环都不算备份。

一、先把全量做扎实

全量不用天天做，每周一次就够，关键是做完要校验。我的做法是周日凌晨做一次完整打包，命令大致如下：

tar -czpf /backup/full/site-$(date +%F).tar.gz \
  --exclude='*.log' --exclude='cache/*' /var/www/site

这里有几个细节值得抠一下。第一，-p 要保留权限，恢复时才不会出现文件能解开却跑不起来的尴尬；第二，--exclude 把日志和缓存排除在外，不然包会越打越大，还全是没用的东西；第三，打完立刻用 tar -tzf 列一下包内容，并把包的 SHA256 写到同目录的校验文件里。校验这一步很多人会省，恰恰是最不能省的。

二、每天的增量交给 rsync

全量之间每天的变化，用 rsync 同步到备份盘，配合 --link-dest 做硬链接快照，既省空间，又能按天回溯：

rsync -a --delete --link-dest=/backup/inc/latest \
  /var/www/site/ /backup/inc/$(date +%F)/
ln -sfn /backup/inc/$(date +%F) /backup/inc/latest

--delete 要格外小心：它会把目标端多余的文件删掉。第一次上这个参数之前，先加 -n 干跑一遍，确认删除列表里没有误伤。源路径末尾的斜杠也不能写错，/var/www/site/ 和 /var/www/site 同步出来的目录结构是不一样的，写错一次，恢复时就得多翻一层。

数据库不能只靠拷文件。MySQL 这类服务，我的做法是先 mysqldump 导出一份 SQL，再把导出的文件纳入上面的备份流程；正在写库的时候直接打包数据目录，恢复出来很可能是不一致的状态。

三、保留份数要提前定好

我的保留策略很简单：全量留 4 周，增量快照留 14 天，超出的一律清理。清理脚本里一定要先算好磁盘占用再删，见过有人把清理条件写反，把最新的全量删掉的。每个月留一份全量放到另外一台机器或者对象存储上，算是异地兜底，机器本身出问题、磁盘整个挂掉的时候才有得救。

四、没演练过的恢复等于没备份

备份做完，我会定期在测试目录里做一次恢复演练：解开最近的一份全量，再把之后某一天的增量覆盖上去，然后把服务在测试端口跑起来，至少确认首页能打开、登录能走通。演练不用很频繁，一个月一次就够，但一定要真的跑通，而不是看一眼备份文件大小就安心。

五、几个容易踩的坑

一是备份和源数据放在同一块盘上，盘坏了就全没了，至少要分盘，最好异地一份；二是定时任务不检查返回值，tar、rsync 出错了也没人知道，脚本末尾一定要判断退出码并把失败发出来；三是备份里混进了密钥和配置文件，打包前先确认排除规则，恢复用的包也不要随手发给别人；四是只备了网站文件忘了数据库和配置文件，恢复时才发现缺了一半。

总结下来，备份这件事拼的不是工具多高级，而是流程闭不闭环：全量、增量、保留、校验、演练，五个环节都跑通一次，心里才算有底。