本文约 1,931 字，预计阅读 5 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：快照很好用，但它不是备份
快照的价值：几分钟恢复整台机器，包括系统、环境、配置、数据——不用重装、不用配环境。故障时的救命稻草。
但很多人把快照当备份用，结果踩坑：回滚后，昨天写的十篇文章也没了，因为快照是整机级别的，它不区分”系统”和”数据”。
原理分析：快照和备份的区别
| 维度 | 快照（Snapshot） | 文件/数据库备份 |
|---|---|---|
| 粒度 | 整个磁盘 | 单个目录或数据库 |
| 恢复对象 | 整台服务器 | 单个文件或表 |
| 恢复速度 | 快（分钟级） | 取决于体积 |
| 跨机恢复 | 通常受限（同地域） | 任意服务器 |
| 回滚副作用 | 全部数据回退 | 只影响恢复的部分 |
| 成本 | 按容量计费 | 低 |
还有一个技术点：快照通常是增量的，第一次是全量，之后只存变化块。但删除中间的快照一般不会导致数据丢失（云厂商会做引用管理），具体行为要看厂商文档。
保姆级实操
第一步：配置自动快照策略
阿里云：ECS → 存储与快照 → 快照策略 → 创建：
重复日期：每周一、周四
时间点：03:00
保留时间：14 天（或保留 5 份）
腾讯云：CVM → 快照 → 定期快照策略，配置类似。
关键取舍：
- 频率：更新频繁的站点每天一次，展示型站点每周两次；
- 保留：至少覆盖 7 天，重要站点 30 天；
- 时间：选业务低峰，且避开数据库备份时间（避免冲突）。
第二步：手工快照（操作前必做）
做任何高风险操作前打一个手工快照：
- 升级 PHP / 数据库大版本；
- 批量替换数据库；
- 更换主题或大版本插件更新；
- 迁移、改 DNS 之前。
命名要有意义：
before-php82-upgrade-20261010
第三步：回滚前的准备（关键）
回滚会把整个磁盘回到快照时间点，包括之后新产生的所有数据。所以回滚前必须：
- 先导出当前数据库：
mysqldump --single-transaction --quick wordpress > /root/emergency-$(date +%F-%H%M).sql
-
把导出文件放到快照之外的地方（另一台机器、对象存储），因为回滚会覆盖本机磁盘；
-
确认回滚影响范围：如果服务器上有多个站点，回滚会影响全部。
第四步：执行回滚
阿里云：ECS → 快照 → 选择快照 → 回滚磁盘 → 确认 → 停止实例 → 回滚 → 启动实例。
腾讯云：类似流程，需要关机。
回滚后：
# 检查站点
wp core version
wp option get home
systemctl status nginx php8.2-fpm mysql
第五步：回滚后找回新数据
如果回滚后需要找回快照之后的新文章：
mysql -e "CREATE DATABASE wp_recover;"
mysql wp_recover < /root/emergency-20261010-1400.sql
# 导出需要的文章，再导入生产库
用 WP-CLI 导出单篇文章再导入更精细（见第 059 篇）。
第六步：用快照做”克隆测试环境”
快照的另一个高价值用法：从快照创建一台新服务器，作为测试环境。
ECS → 快照 → 创建自定义镜像 → 用镜像开一台按量付费实例 → 测试 → 释放
这样测试环境与生产完全一致，测完销毁，成本极低。
常见踩坑与失败案例
- 直接回滚导致数据丢失 —— 最常见的误用。回滚前一定先导出当前数据库。
- 案例：某站被挂马，运维直接回滚到三天前的快照，站点干净了，但三天内的 200 多条订单也一起消失了。正确做法是：先导出当前数据库 → 回滚 → 清理 → 再把订单数据增量导回。
- 快照创建时未停止写入导致数据不一致 —— 数据库正在写入时打快照，可能得到不一致的 InnoDB 文件。阿里云/腾讯云支持”应用一致性快照”（需安装插件），或选择在低峰期操作。
- 以为快照是异地备份 —— 快照通常与云盘在同一地域，地域级故障时一起受影响。重要数据仍要跨地域复制。
- 快照费用累积 —— 长期保留大量快照会产生不小费用，配置自动删除策略。
- 只有系统盘快照 —— 数据盘（如 uploads 单独挂载）要单独配置快照策略。
总结
快照是整机级快速恢复手段，最适合用在”高风险操作前的保险”和”系统级故障恢复”。它不能替代应用级备份，因为回滚是”全有或全无”的。正确用法是快照 + 应用级备份双轨：日常用 mysqldump/插件做细粒度备份（能找回单篇文章），重大操作前打快照（能整机回退），并且回滚前永远先导出当前数据库。记住这条顺序，快照就从”危险按钮”变成”可靠保险”。
