备份任务每天凌晨跑，日志里一片绿色对勾，你很安心。直到某天网站真的挂了，你去恢复备份，才发现：仓库密码不知道在哪、数据库导出的文件根本不在备份里、快照恢复出来却没人知道怎么启动服务。备份成功不等于能恢复——没经过恢复演练的备份，只是心理安慰。本文用 Restic 为例，带你设计一次真正能验证恢复能力的演练。
第一步：先定义“丢了什么最难受”
动命令之前，先回答两个问题，写下来：
- 能接受丢失多长时间的数据？（比如 24 小时——这决定备份频率是每天一次还是每小时一次；）
- 最长能停机多久？（比如 4 小时——这决定恢复流程要不要提前写成脚本，而不是到时候现查文档。）
然后列出要保护的东西：网站程序目录、上传目录、数据库、Nginx/应用配置文件、TLS 证书、以及恢复本身需要的密码和密钥。很多人备份了全站，却把仓库密码只放在被备份的那台机器上——机器没了，密码也没了。
第二步：用 Restic 建一个规范的仓库
Restic 的特点是快照、加密、去重，支持本地、SFTP、S3 等多种后端。它提供的是工具，不是完整策略，策略要你自己定。先初始化仓库，密码文件权限设为 600：
chmod 600 /root/.restic-passwd export RESTIC_PASSWORD_FILE=/root/.restic-passwd restic -r sftp:user@backup.example.com:/srv/restic-repo init
注意：仓库密码丢了，备份就是一堆打不开的乱码。把密码（或密码文件的一份拷贝）独立保管在另一个地方，比如密码管理器里，并确保紧急情况下能拿到。
备份不要只放同一台 VPS 的另一个目录——那只能防误删，防不了整机故障或账号被封。至少一份副本要放在机器之外。
第三步：数据库不能直接拷文件
运行中的数据库文件不能当普通文件直接复制，那样得到的很可能是一份恢复时打不开的备份。正确做法是先按数据库官方方法导出，再把导出文件纳入 Restic 备份：
# MySQL/MariaDB：单事务导出，保证一致性 mysqldump -u root -p'你的密码' --single-transaction mydb > /backup/mydb.sql # 然后把网站文件、配置和导出文件一起备份 restic -r sftp:user@backup.example.com:/srv/restic-repo backup \ /var/www /etc/nginx /backup/mydb.sql
PostgreSQL 用 pg_dump，WordPress 这类应用还要记得备份 wp-config.php 里的数据库账号信息。恢复时也要用匹配的数据库版本、字符集和权限配置，否则“数据都在，服务起不来”。
第四步：安排一次小规模恢复演练
这是全文最关键的一步。在隔离目录（千万别直接覆盖生产）恢复一份快照：
# 列出快照，选一份来演练 restic -r sftp:user@backup.example.com:/srv/restic-repo snapshots # 恢复到隔离目录 restic -r sftp:user@backup.example.com:/srv/restic-repo \ restore 最新快照ID --target /tmp/restore-drill # 核对文件和权限 ls -la /tmp/restore-drill/var/www # 仓库完整性检查（能发现部分数据损坏问题） restic -r sftp:user@backup.example.com:/srv/restic-repo check
然后在测试环境里把站点真正启动起来：导入数据库、起 Web 服务、打开页面点几个核心功能。restic check 能发现数据损坏，但发现不了“文件都有，但没人知道怎么启动”的流程问题——只有真实启动一次才能发现。把演练中用到的每一步、每一处卡点都记下来，这就是你的恢复手册初稿。
演练时建议掐表记录两个数字：下载恢复用了多久（决定你的 RTO 是否现实）、从“开始恢复”到“服务可用”一共几步（步骤越多，半夜人越容易出错）。如果发现恢复要翻五个文档、找三个人要密码，说明你的恢复流程本身就需要重构——把密码集中进密码管理器、把启动步骤写成脚本，下次演练再验证。
第五步：删除旧快照前，先定好保留规则
每天、每周、每月各保留多少份，要根据数据变化频率和存储成本定。Restic 的保留策略长这样：
restic -r sftp:user@backup.example.com:/srv/restic-repo \ forget --prune --keep-daily 7 --keep-weekly 4 --keep-monthly 6
注意：--prune 会真正删除数据，历史恢复能力随之消失。不要把网上的 forget 命令直接粘到生产仓库，先在测试仓库试，确认保留份数符合预期再动生产。一个可靠的备份方案应该能随时回答：最近一次成功恢复是什么时候？恢复需要哪些账号和密码？演练记录在哪？
常见坑
备份任务绿色对勾 = 高枕无忧。任务成功只证明“拷过去了”，恢复演练才证明“拿得回来、用得起来”。
仓库密码只存在被备份的机器上。机器没了等于备份也没了，密码必须异地独立保管。
直接备份运行中的数据库文件。大概率得到损坏的备份，务必先用 mysqldump / pg_dump 导出。
备份和生产放在同一台机器、同一个账号下。防误删可以，防整机故障、账号被封、勒索加密不行，至少一份异地副本。
常见问题
多久做一次恢复演练？至少每季度一次，重要业务每月一次。演练本身很快，贵的是第一次——把流程写下来之后，后面都是重复动作。
演练一定要用生产数据吗？用最近的真实快照演练效果最好，但要在隔离环境做，演练完清理掉，避免测试数据污染和敏感信息泄露。
Restic 和定时任务怎么配合？把备份命令写进 cron 或 systemd timer，输出重定向到日志并加失败告警。记住监控“失败”，而不是只看“成功”。
保留策略里的数字怎么定？看两点：数据变更多快（决定每天几份）、存储预算多少（决定留几个月）。先定一个保守值，跑几个月看实际占用再调。
参考资料
资料核查：2026年10月8日。本文根据公开官方资料独立整理撰写；封面为 AI 生成的概念插画，不是产品实拍。
