测试恢复：提前检查您的备份
如何进行试恢复、结果应记录什么，以及哪些典型意外只有在演练中才会暴露，而不是在真正的灾难中。
更新于 2026年8月23日
从未实际恢复过的备份不算备份，只是希望。每季度做一次恢复演练，只需一小时，就能把希望变成经过验证的事实。
需要检查什么
发生故障前，您需要回答三个问题：
- 完整性。 备份是否包含启动所需的一切：数据、设置、密钥、证书、计划任务。
- 可读性。 归档能否打开，数据库转储能否无错误地恢复。
- 时间。 完整恢复需要多少小时。您需要提前知道这个数字，而不是在压力下才发现。
如何开展演练
最可靠的做法是在另一台机器上进行，而不是生产机器。租用一台 VDS-1 一个月，从零开始恢复到它上面，并记录耗时。
export RESTIC_REPOSITORY="sftp:backup@backup.example.com:/srv/restic"
export RESTIC_PASSWORD_FILE=/root/.restic-pass
restic snapshots
restic restore latest --target /restore
ls -la /restore
恢复数据库：
docker compose up -d db
gunzip -c /restore/var/backups/db.sql.gz | docker compose exec -T db psql -U postgres app
docker compose exec -T db psql -U postgres app -c "select count(*) from users;"
启动应用并在浏览器中打开——这是最后一步。在页面打开之前，恢复都不算完成。
还有一种更轻量但也很有用的做法：只把数据库恢复到一个单独的容器中，运行在同一台机器上，确认数据存在且是最新的。
不仅要检查解包是否成功，还要检查数据的日期。一个创建得很可靠、但从一个月前就不再包含所需目录的备份，在快照列表中看起来完全正常。请对比表中的记录数量和最新文件的时间戳。
通常会暴露出的问题
- 忘记
.env文件。 数据在，但访问数据的密码不在。 - 忘记证书。 网站能启动，但 HTTPS 无法响应。
- 忘记计划任务。 一切正常，但备份不再创建——而您一个月后才发现。
- 没有记录启动顺序。 应用先于数据库启动并崩溃。
- 仓库密码只存在于已丢失的机器上。 备份还在，但无法访问。
- 恢复需要十小时，而不是两小时。 接收端带宽或磁盘柜，参见磁盘速度。
写下操作顺序
根据演练结果，写一份简短的操作说明，并保存在机器之外：
- 订购一台同档或更高档的机器——开通大约需要一分钟。
- 安装 Docker，从备份中恢复
/opt/myapp。 - 恢复数据库转储，检查记录数量。
- 恢复
/etc/nginx和证书，启动 Web 服务器。 - 将域名指向新地址。
- 从
crontab.txt恢复计划任务。 - 检查：网站能打开、登录正常、备份重新开始创建。
第 5 条最容易被低估。DNS 记录不会立即更新，如果您打算进行迁移，应提前将记录的 TTL 降低到 300 秒。
多久做一次
生产服务每季度一次，其他所有服务每半年一次。此外，在任何重大变更之后都要做：新数据库、新服务、移动目录。把演练写进日历，否则它永远不会发生。