服务器出问题时，最让人着急的通常是数据找不回来。不少团队是在误删文件、或者系统升级失败之后，才想起要做备份。阿里云快照可以把云盘在某个时间点的数据状态存下来，出事时拿来回滚，损失通常能控制在可接受的范围里。先说清楚快照是什么，再用一个误删配置的案例讲它实际怎么用。
快照是什么，和备份有什么区别
快照是云盘在某一时刻的数据副本。阿里云快照采用增量机制，第一次创建时会完整记录数据，之后只保存发生变化的部分，所以创建速度快，占用的空间也比较省。快照依附于云盘，它更像给磁盘拍的一张可以回头看的照片，不能替代异地副本。如果需求是跨地域容灾或长期归档，还需要再搭配其他备份方案。
设置自动快照的三个步骤
临时操作前手动建一个快照，能保护这次改动。但日常运维全靠人记得去做，迟早会漏，所以更适合用自动快照策略。
- 先新建快照策略。在ECS控制台的“快照与镜像”页面新建自动快照策略，设定执行时间和周期。比如每天凌晨2点执行一次，选在业务访问量低的时段，备份对线上的影响会小一些。
- 再设置保留时长。保留天数取决于数据的重要程度。业务数据一般保留7到30天，系统盘可以适当缩短。保留时间越长，积累的快照越多，存储成本也会随之上升，所以要定期回头看一下。
- 最后绑定云盘。把策略应用到需要保护的系统盘和数据盘上。如果一台实例挂了多块盘，而且这些盘的数据需要彼此对应，就用快照一致性组，让同一实例的多块盘在同一时间点生成快照，避免恢复后数据错位。
五个常见使用场景
- 系统升级前，操作系统补丁或应用版本更新之前，手动创建一次快照。升级失败时可以直接用它回退，不用在故障现场硬修。
- 误删数据后，从最近的快照创建新云盘，挂载到实例上，只取回需要的文件。这样不必整盘回滚，也不会覆盖掉删除之后产生的新数据。
- 数据迁移与测试时，用生产环境的快照创建测试实例，在隔离环境里验证改动。确认没问题后再动线上，避免测试直接影响业务。
- 安全事件响应时，发现异常先保留当前快照作为取证依据，再进行清理和修复。顺序反过来，很可能把现场破坏掉。
- 日常定时保护靠自动策略形成连续的恢复点，应对硬件故障或人为误操作。恢复点越连续，能选择的回退时间就越多。
案例：一次误删配置文件的恢复过程
某电商团队的运维同事在清理服务器时，误删了Nginx的站点配置目录。好在团队已经给应用服务器配置了每天凌晨的自动快照。他在控制台找到前一天的快照，用它创建了一块新云盘，挂载到临时实例上，从中复制出配置文件，再同步回生产服务器。整个过程大约花了40分钟，线上服务只受到短暂影响。
复盘时，团队把“重大变更前手动创建快照”写进了变更流程。这次事情说明，快照的价值在于提前把恢复路径备好。出事以后再临时找办法，时间和压力都会多出不少。
使用注意事项
快照能保护数据，但有些限制要提前弄清楚。
- 快照不替代数据库备份。它保存的是云盘数据，数据库仍应配合专门的逻辑备份策略，两者各管一块。
- 留意存储费用。保留策略设得太长，成本会慢慢累积。建议定期检查，清理已经过期、不再需要的快照。
- 回滚系统盘前先停机。回滚系统盘通常需要先停止实例。操作尽量放在业务低峰期，并先确认回滚点的时间是否符合预期，别回到一个更旧的状态才发现不对。
- 定期做恢复演练。快照是否真的可用，只有恢复一次才知道。不要等到真正需要的那天才第一次尝试。
小结
快照的作用，是为数据留下可以回溯的时间点。先把自动策略配好，再把关键变更前的手动快照纳入流程，误操作和故障出现时，能回退的余地会大很多。
