云服务器误删能救回来吗：rsync + 定时任务做一份真正能用的备份

服务器上最贵的不是配置，是数据。网站改错一行、rm 敲错一个路径、升级把数据库写坏，这些事恢复起来往往不是“重装就行”，而是“昨天那份数据还在不在”。备份的意义不在“做过”，而在“出事那天能拿回来”。这篇只讲一套够用的做法：rsync 做增量备份、cron 每天自动跑、定期做一次恢复演练。

第一步：先分清，什么才算备份

同一台机器上把 /var/www 复制到 /backup，严格说不算备份：磁盘坏了、整机丢了，两份一起没。备份至少要满足一条：源和备份不在同一个故障域里。个人小站最现实的组合是：备份到另一台机器、对象存储，或者一块平时不挂载的外接盘。先定好目的地，再谈命令，否则后面的自动化只是在自我安慰。

第二步：用 rsync 做第一次全量

假设要备份网站目录 /var/www/html，备份目的地是另一台机器上的 /data/backup/www：

rsync -av --dry-run /var/www/html/ user@备份机IP:/data/backup/www/

先跑一遍 --dry-run 看它会传什么，确认无误再去掉这个参数正式跑。-a 保留权限、时间戳和属主信息，-v 打印过程，少了 -a，恢复出来的文件权限可能全变样，网站直接起不来。

注意源路径末尾的斜杠：/var/www/html/ 表示同步目录里的内容，/var/www/html（不带斜杠）表示把这个目录本身也复制过去。两个写法结果差一层目录，第一次跑务必用 --dry-run 核对。

第三步：增量 + 保留天数，别让备份把盘吃满

每天全量复制既慢又占地方，rsync 默认只传改动过的文件，已经是增量。真正要补的是“保留策略”：按日期分目录，每天一份，旧的自动清掉。例如备份脚本里先这样组织：

BACKUP_DIR="/data/backup/www-$(date +%Y%m%d)"
rsync -av /var/www/html/ user@备份机IP:"$BACKUP_DIR"/

再加一条清理规则，删掉 7 天前的旧目录：

ssh user@备份机IP "find /data/backup -maxdepth 1 -name 'www-*' -mtime +7 -exec rm -rf {} +"

保留几天按数据量定，小站 7 天够用；数据库备份要另外算，本文先只讲文件目录。还有一个危险参数要单独提醒：–delete 会把目标端多余的文件删掉，用来做“镜像”很合适，但第一次用必须先 --dry-run，否则源端误删的文件会在下一次备份里把备份端也同步删掉——那就不是备份，是误删的帮凶。

第四步：交给 cron，每天自动跑

手动备份最大的敌人是“忘了”。把脚本存成 /root/backup-www.sh，加上执行权限，再写一条定时任务，每天凌晨 2:30 跑：

30 2 * * * /root/backup-www.sh >> /var/log/backup-www.log 2>&1

cron 环境里 PATH 很小，脚本里所有命令都要写绝对路径，输出重定向到日志文件，否则失败了你都不知道。跑通后的第一周，每天早上看一眼日志里有没有 error 或 rsync 的报错行，这一步不能省。

第五步：没演练过的备份，等于没有备份

这是整篇最重要的一句：备份做完不算完，恢复演练才算。每月抽一次，把备份恢复到一个临时目录，对照检查：

mkdir -p /tmp/restore-test
rsync -av user@备份机IP:/data/backup/www-20261027/ /tmp/restore-test/
diff -r /var/www/html /tmp/restore-test | head -20

diff 没有输出，或者只有你预期内的改动，才算通过。演练时常暴露的问题都很具体：备份机 SSH 密钥过期了、清理规则把昨天那份也删了、权限恢复后网站 403——这些问题在演练时发现是小事，出事当天发现就是事故。

一句话收尾

备份不需要多复杂：目的地在另一台机器、每天自动跑、保留 7 天、每月恢复演练一次。做到这四条，误删、改错、升级翻车，大多都能在半小时内回到昨天的状态；做不到最后一条，前面三条只是让你在出事时更失望而已。