备份能解压不等于能恢复：给博客设计一次恢复演练

我现在已经有自动备份，但备份脚本返回成功，只能证明完成了某些检查。真正出故障时能否恢复，还需要单独验证。这篇是我根据实战笔记整理的演练方案，不把计划写成已经完成的恢复成绩。

先明确两个目标

RPO 是最多能接受丢失多长时间的数据，RTO 是故障后希望多长时间恢复服务。例如每天备份一次，在没有其他增量记录时，故障点与最近一次成功备份之间的数据都有丢失风险。备份任务失败一天，这个间隔还会继续扩大。

恢复时间则包含准备环境、找到备份、解压导入、修复配置和验证功能，并不是 mysql 导入命令运行了多久。

演练必须与线上隔离

优先使用本地虚拟机或独立测试目录与数据库。不要在生产数据库里练习 DROP、覆盖导入，也不要用测试站点连接线上数据库。测试环境应避免给真实用户发邮件、执行生产定时任务。

正式动手前列出需要的东西：网站归档、数据库备份、程序版本、PHP 扩展、Nginx 与 PHP-FPM 配置、上传文件以及恢复顺序。涉及秘密的文件只在受控环境恢复，完成后重新检查权限。

按顺序验证

1. 选定同一批或时间接近的备份，记录时间和文件大小。数据库与上传文件时间差过大，可能出现文章引用了尚未备份的图片。
2. 校验已有校验值，执行 gzip -t 与 tar -tzf。校验值证明文件与记录一致，不证明备份内容正确。
3. 安装匹配的依赖，把网站解到测试目录。
4. 建立独立测试库与专用账号，再导入 SQL。
5. 调整测试站点的数据库连接、站点 URL 和 Nginx 配置，防止跳回线上。
6. 验证首页、文章、分类、图片和后台登录，再在测试环境验证评论或编辑功能。

只读检查示例：

gzip -t 数据库备份.sql.gz
tar -tzf 网站备份.tar.gz | head

执行时替换成真实文件名。先看归档内部路径，再决定如何解压，避免覆盖错误位置。

不能遗漏上传图片

Typecho 数据库里可能保存图片地址，图片实体在 usr/uploads。只有数据库没有文件，会出现文章文字都在、封面却全部失效的情况。还要检查 HTTPS 域名、绝对路径及文件归属，不能只统计文章行数。

演练结束留下什么

记录选用的备份时间、开始和结束时间、实际恢复步骤、失败点及功能检查结果。测试站点能打开后，再比较关键表、文章内容和上传图片。只有做完这些，才能写“这批备份已在隔离环境恢复验证”。

对我来说，下一步的目标不是再增加几个压缩包，而是让另一位同学拿着恢复文档也能把测试站点还原出来。

恢复到测试库前再确认 SQL

先确认 SQL 是否包含 CREATE DATABASE、USE 或跨库限定表名；仅把 mysql 命令末尾换成测试库，不一定能防止脚本切回生产库。优先在独立虚拟机恢复，用无生产访问权限的账号操作。恢复后核对文章、图片、用户权限及测试写入，并记录所用备份时间点与总耗时。本文仍是演练方案，没有虚构恢复成功与耗时。

内容复核与修订：2026-10-29。实验示例与本站运行记录分别说明；原始归档日期保留。