结论：CMS 迁移前的“完整备份”必须包含网站文件、数据库、配置文件与证书三层，并且每一层都要在临时环境做过还原验证；回滚预案要写到“谁、在什么条件下、执行哪几条命令、多长时间完成”这个颗粒度，否则只能算心理安慰。
为什么“备份了”和“能恢复”是两件事？
结论：没有做过还原验证的备份，不能算有效备份。
很多站长迁移失败的真实原因不是没备份，而是备份文件本身就是坏的：mysqldump 跑到一半磁盘满、数据库字符集导出成 latin1、附件目录漏了 uploads、压缩包传输中断。这些问题的共同特点是——源站一切正常，只有到需要还原的那一刻才暴露。
最低要求：全量备份完成后，在临时机器或本地 Docker 里还原一次，核对三件事——数据表数量是否一致、核心表（用户表、主题表、附件表）行数是否一致、首页和后台能否正常打开。核对通过后给备份文件打上 md5sum 校验值，异地存一份。
CMS 迁移前到底要备份哪些东西？
结论：至少 6 类资产，文件目录只是其中一类。
- 网站根目录全部文件（含自定义模板、插件、上传的附件与头像）
- 数据库全量（含用户、帖子、评论、配置项、统计表）
- Web 服务器配置：Nginx/Apache 站点配置、伪静态规则、301 跳转规则
- 运行环境清单：PHP/MySQL 版本、已装扩展、Python/Node 依赖版本，逐条记录
- 证书与域名：SSL 证书私钥、DNS 解析记录全量导出（A、CNAME、MX、TXT）
- 第三方凭据：支付密钥、短信接口、对象存储 AccessKey、邮件 SMTP 配置
备份保留策略建议按 3-2-1 执行：至少 3 份副本、2 种介质、1 份异地。迁移窗口期内保留最近 7 天的每日备份，别只留一份最新的。
数据库备份的具体命令是什么？
结论：中小站点用 mysqldump 的 --single-transaction 模式即可不停机备份。
mysqldump -uroot -p --single-transaction --quick --routines --triggers --events \
--default-character-set=utf8mb4 gj_db | gzip > gj_db_$(date +%F_%H%M).sql.gz
关键点：--single-transaction 保证 InnoDB 表一致性快照、不锁表；--routines --triggers --events 少了会丢存储过程和定时事件；--default-character-set=utf8mb4 不加容易出乱码。单库超过 10GB 建议换 mydumper 或 xtrabackup，速度差好几倍。
迁移前后用同一条 SQL 核对表数量：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema='gj_db';
两个数字必须相等，不等说明有表没导过去。
回滚预案怎么写才真能用？
结论：回滚预案的核心是三件事——触发条件、时间窗口、按顺序执行的命令清单。
触发条件要写死，不能靠现场感觉。例如：新站首页连续 5 分钟返回 5xx、登录或发帖功能不可用超过 10 分钟、出现数据写入丢失。命中任意一条即启动回滚。
时间窗口靠 DNS 撑。迁移前 24 小时把域名 TTL 从 3600 秒改成 600 秒，回滚时 10 分钟内就能切回旧 IP；不改 TTL 的话，切回要等 1 小时甚至更久。
回滚步骤建议按这个顺序写成清单：
- 恢复旧站 DNS 解析（或改回 hosts 验证）
- 停掉新站的写入入口，导出新站这段时间产生的增量数据
- 从备份还原旧站数据库与文件
- 校验表数量、首页、后台、登录
- 开放访问并观察 30 分钟
第 2 步最容易被跳过：直接在旧库上还原，等于把迁移后用户新发的帖子全部抹掉。
迁移前要不要演练一次回滚？
结论：要，而且必须在正式迁移前 24 至 48 小时完整走一遍。
演练内容不是“看一眼备份文件在不在”，而是真的把备份还原到临时环境、真的改一次 hosts 指向、真的记录每一步耗时。演练结束后你会得到一份可信的时间表，比如“全量还原 22 分钟、DNS 生效 8 分钟、验证 10 分钟，总回滚窗口约 40 分钟”，这个数字才是决定你敢不敢在白天操作迁移的依据。
迁移当天的时间线怎么排？
结论：选访问量最低的时段，提前公告，留只读窗口。
推荐节奏：T-7 完成第一次全量备份与还原验证；T-1 再跑一次全量并异地归档；T-0 站点切只读（禁止发帖回帖），做最后一次增量备份，然后迁移、验证功能清单（首页、列表页、详情页、登录、发帖、附件上传下载、后台登录、伪静态 URL 是否 404）。全部通过后再开写入。
迁移完成后别忘了收尾：查看站内“更新日志”这类记录入口，把本次功能迭代、配置变更和故障修复记录写进去——本站的更新日志就是专门用来记录功能迭代、规则调整、重要配置变更和线上故障修复的，下次出问题时有据可查。
一句话收束：备份的价值在还原，预案的价值在演练。三层备份 + 一次真实回滚演练 + 提前改小 TTL，这三件事做到位，CMS 迁移就只是个排期问题，不是事故问题。
