快照回滚能救误删，但救不回这2种情况

快照回滚能救误删但救不回这2种情况，这话我放在方案的第一页，不是最后一页。因为多数人按回滚按钮时脑子里想的是“回到昨天下午三点”，实际发生的却是“整块盘退回昨天下午三点，那之后所有写入一起消失”。差别挺大的吧。

快照回滚能救误删但救不回这2种情况，得先弄明白它拍的是什么

快照这机制，说白了不复杂。块级快照拍的是某个瞬间磁盘上哪些块是什么内容；文件级快照拍的是目录树和文件本身。两套路子。共同点呢，它只认“那一刻的状态”，不认“你做过什么动作”。你误删一个目录，回滚能把它变回来，是因为那一刻它还在；可它没法只挑一个文件退回，也没法把你手滑的那一下单独撤销。这跟厂商大方不大方没关系。是快照本身就没这个精度。

误删这部分，快照是真能救

敲错 `rm -rf` 把整站目录清了、`nginx.conf` 改崩了起不来、换主题把首页覆盖成白屏、被挂马删掉半套程序文件，这类事我处理过不止一次，只要快照时间点在出事之前，回滚完站点就能喘气。前提是快照得在，别把自动快照关掉，省下的那点存储费，不够一次事故折腾的。

第一种救不回的：快照时间点之后写进去的数据

最常见的翻车现场，大概就是这样。站点下午三点拍了快照，晚上十点你发现——坏了，上午误删了一个文件。回滚吧，回的是下午三点。那之后几个小时里用户注册、下单、评论、后台改过的价格，全跟着一起蒸发了。有人觉得回滚是“只把删掉的那部分补回来，别的都不动”。想得美。数据盘上的块是整片替换的，写入按块覆盖，没人能给你挑着恢复。

回滚不是撤销键。

所以动手之前先想一件事：从快照点到眼下，有没有产生过不能丢的数据。有的话，先把这部分单独导出去——订单表导一份、上传的附件目录 `rsync` 到另一台机器，再谈回滚吧。数据库的增量还能靠 binlog 往前滚一段，附件和日志可没有这种后悔药。

第二种救不回的：快照压根没拍到，或者拍到了你自己弄丢的

快照只覆盖策略里勾选的那几块盘，挂在机器外面的东西一概不管——对象存储里的文件、另一台机器上跑的数据库、第三方接口那边已经写出去的数据、CDN 上缓存的旧页面（这个丢了不心疼），还有后加的数据盘如果忘了加进自动快照策略，回滚时它一动不动，你还在那儿以为一起回去了呢。

内存里的东西也不在快照范围里，Redis 没落盘的队列、PHP 进程手里没写完的会话，回滚加重启之后就是没了，业务侧得能接受这个呗。

拍不到就回不来。

还有一种更冤的：快照自己没了。保留期到了被自动清理，或者更糟，快照和实例挂在同一个账号下，密钥泄露、账号被撞库，人家顺手把快照一起删了再来找你谈条件。勒索软件现在会先翻快照，这可不是传说。至少留一份到另一个账号或另一个地域，手工同步，别全指望控制台里的自动策略。

回滚之前，我一般会先干这几步

先留退路，再动手。

打快照这件事我放第一位，给当前状态再拍一份，哪怕它是坏的、是崩的，也比没有强——万一回滚过去发现更糟，你还有条退路。接着把现场留个底：`df -h`、出错目录的 `ls -l`、`journalctl -u nginx –since` 最近一段、数据库 `show master status` 记下 binlog 位置，这些在回滚之后往往就查不到了，而查原因偏偏要用。然后停业务，`systemctl stop nginx php-fpm`，把写入关干净，不然回滚过程中还有新块写进来，状态更乱，你会发现连日志都对不上。

别嫌麻烦。

如果是把快照恢复到一块新盘，别急着往生产上挂。`mount -o ro,noload /dev/vdb1 /mnt/check` 只读挂上去翻一翻，确认文件数、目录结构、首页文件都在，再考虑替换就好。多块盘的实例还得看顺序，LVM 那种要 `vgchange -ay` 激活卷组之后才看得到逻辑卷，这步漏了会以为数据全没了。

数据库这摊子，快照单独搞不定

云盘快照多数是崩溃一致性，说白了相当于拔电源那一刻的盘面，InnoDB 起来靠 redo 日志往前推，能恢复，但有个前提：redo 和数据文件在同一组盘上、同一时间点。不少人为了性能把日志盘单独挂一块，两块盘各拍各的快照，时间差几秒，回滚完 MySQL 直接起不来，报的还是那种看不太懂的错。

时间点对不上，白搭。

能起来的也别松气。快照只把你带回那一刻，之后的增量在 binlog 里，要手动往前滚：`mysqlbinlog –start-datetime=’2026-11-14 15:00:00′ –stop-datetime=’2026-11-14 22:00:00′ mysql-bin.000123 | mysql -uroot -p`。binlog 的过期清理受 `expire_logs_days` 控制，保留天数要是比快照保留期短，你以为能补，其实补不上。

主从结构还有一层坑：主库回滚到旧时间点，从库仍停在新位置，GTID 比主库超前，直接重连会报错，一般只能重建从库。所以回滚主库之前先把复制停掉，`stop slave`，不然它会把旧数据又追上来。

快照不是备份，这句得说透

快照和实例常在同一个存储池、同一个账号下，一次误操作、一次账号失守，两样一起没。备份是另一回事：多一份、放远处、能独立恢复。我一般让保留策略里至少有一份跨地域或者跨账号，再每季度挑一个快照恢复到临时实例，起服务、开首页、登一次后台、下一单，走一遍流程。没演练过的备份，只能算心理安慰吧。

说回那两种情况：快照点之后写进去的数据，快照覆盖不到也保不住的部分——回滚之前把这两样先单独留一份，剩下的都好办。按钮按下去只要十秒，按之前那十分钟的准备，才是真正值钱的地方。