云服务器用久了迟早会撞上两个绕不开的东西快照和镜像。很多人第一次接触它们是在控制台上随手点了个创建快照然后看着进度条发呆心里犯嘀咕——这玩意儿到底存了啥跟镜像又差在哪我能不能拿它当备份用更常见的场景是一台跑了两年的业务机要迁移、要扩容、要重装这时候才发现平时没做快照只能硬着头皮一台台重配环境。这篇就围绕云服务器 ECS 的快照与镜像把原理、区别、实操步骤和踩过的坑一次讲透适合刚上手云主机的新人也适合用了几年但一直没搞明白底层逻辑的老用户。1. 快照和镜像到底在存什么先把底层逻辑捋清楚1.1 快照不是复制整个硬盘而是记录数据块的变化刚接触快照的人最容易有的误解是以为点一下创建快照就等于把整块云盘拷了一份。实际上主流云平台的快照机制底层是基于数据块的增量存储。第一次给某块云盘做快照时确实是全量的——把这块盘上所有已写入的数据块记录下来但从第二次开始只有发生变化的数据块才会被写入新的快照。这个设计带来的直接好处是快照创建速度快、占用空间小、对业务性能影响低。你可以理解为给一本书拍修订记录第一版拍全本之后每次只拍改动的几页。恢复的时候系统会按时间顺序把全本加历次修订拼回去得到你指定的那个时间点的完整状态。这里有个关键点必须说清楚快照是针对单块云盘的不是针对整台实例的。一台 ECS 上挂了三块盘系统盘 两块数据盘你只对系统盘做了快照那数据盘上的东西是不在里面的。这个认知差是新手翻车的重灾区后面会专门讲。1.2 镜像是一台机器的装机模板含系统盘和配置镜像Image解决的是另一个问题我要快速搞出一台跟现在这台一模一样的机器。它本质上是一个包含操作系统、应用环境、配置文件的完整模板可以直接用来创建新实例。镜像的来源大致分三类公共镜像云厂商提供的纯净系统比如各种版本的 Linux 发行版和 Windows Server开箱即用但没有业务环境。自定义镜像你自己基于某台实例或某个快照制作出来的带着你的应用、配置、数据如果做的时候包含数据盘。共享/市场镜像别人做好的、带特定软件的镜像比如预装了某种运行环境的。自定义镜像的制作底层往往就是拿一个系统盘快照转换而来。所以快照和镜像不是并列关系而是上下游关系快照是数据块的存档镜像是基于存档封装出的可启动模板。1.3 一张表看清两者的核心差异维度快照镜像作用对象单块云盘整台实例至少含系统盘主要用途数据备份、回滚、容灾批量部署、环境复制、迁移能否直接启动实例不能需先转镜像或挂载恢复能直接创建新实例存储粒度数据块级、增量整机模板典型场景升级前留一手、误删恢复新机器快速上线、多机同构计费方式按快照容量计费镜像本身通常免费占用的是底层快照/存储空间看懂这张表很多该用哪个的纠结就迎刃而解了要保命用快照要复制用镜像。2. 快照的实操从创建到回滚的完整链路2.1 创建快照前必须确认的三件事点创建快照之前我养成了一个固定习惯先确认三件事能避免九成的返工。第一确认要备份的是哪块盘。在控制台的云盘列表里看清楚盘符和挂载点别把数据盘当成系统盘。系统盘一般挂载在根目录数据盘是额外挂载的名字和容量都不一样认准了再操作。第二确认业务是否在写数据。快照创建瞬间如果盘上正在大量写入可能出现数据一致性问题——比如数据库正在写事务快照抓到的可能是半个事务的状态。稳妥做法是业务低峰期做或者对数据库先做一次逻辑备份比如导出 SQL 文件再打快照。这一点很多人忽略等到恢复时发现数据对不上才追悔莫及。第三确认快照保留策略。手动快照不会自动清理做多了会一直占着存储空间产生费用。如果平台支持自动快照策略建议按每天一次、保留 7 天这类规则配置既覆盖了常见故障窗口又不至于无限膨胀。2.2 手动创建与自动策略的取舍手动创建适合有明确动作前的场景要升级内核了、要改配置文件了、要装一个不确定能不能跑起来的大软件了先手动打一个心里有底。操作路径一般是控制台找到目标云盘点创建快照填个能看懂的名字——名字一定要带日期和用途比如sys-20240612-before-kernel-upgrade别用默认的随机名过一周你自己都不认识。自动快照策略适合日常兜底。配置时关注两个参数执行时间和保留数量。执行时间选业务最闲的凌晨保留数量根据你的恢复需求定一般 7 到 15 份够用。要注意自动策略是滚动覆盖的超过保留数量的最旧快照会被删掉所以别指望它做长期归档。提示自动快照策略绑定的是云盘不是实例。实例释放后如果云盘还在策略继续生效云盘一起释放了快照是否保留取决于你释放时的勾选项务必看清楚。2.3 回滚快照不是恢复文件是整盘回到过去这是最容易误解的一步。回滚快照不是让你挑几个文件恢复而是把整块云盘的数据状态退回到快照创建的那一刻。也就是说快照之后你在盘上做的所有改动——新建的文件、改过的配置、装的软件——全部消失。所以回滚前必须做两件事一是确认快照之后没有需要保留的新数据如果有先想办法导出来二是给实例做一次停机回滚过程中盘是不可用的业务会中断选在维护窗口操作。回滚完成后实例需要重启起来之后验证关键服务是否正常。我遇到过回滚后某个服务起不来的情况排查发现是快照时间点早于该服务的配置文件写入时间属于回滚到了更早的状态这种就得靠回滚前确认时间点来规避。2.4 用快照恢复单块盘而不是整机有时候你只想恢复数据盘不想动系统盘。做法是用快照创建一块新的云盘挂载到实例上然后把需要的数据从新盘拷回原盘。这样系统盘完全不受影响风险最低。具体步骤是快照列表里找到目标快照选择创建云盘容量不能小于快照对应原盘创建好后在实例的云盘管理里挂载进系统后lsblk确认新盘符mount挂到临时目录拷完数据再卸载、解挂、释放临时盘。这套流程比整盘回滚安全得多适合只误删了一个目录这种局部故障。3. 镜像的制作与使用把一台机器变成可复制的模板3.1 自定义镜像的两种制作路径做自定义镜像有两条路选哪条取决于你的现状。路径一基于实例直接创建镜像。控制台选中运行中的实例点创建自定义镜像平台会自动对该实例的系统盘以及你勾选的数据盘做处理并封装成镜像。这条路径最省事适合这台机器环境已经调好了我想复制它的场景。注意创建镜像过程中实例最好停机或至少停止写入保证一致性。路径二基于系统盘快照创建镜像。如果你已经有一个系统盘快照可以直接用它转成镜像。这条路径适合我有一份历史快照想把它变成可部署的模板。好处是快照是某个确定时间点的状态转出来的镜像干净可控。两条路径产出的镜像本质一样区别只在入口。我个人的习惯是日常用路径一快速复制重要版本用路径二从快照转因为快照有明确的时间戳追溯起来清楚。3.2 制作镜像前必须做的瘦身和清理直接拿一台跑了很久的机器做镜像往往会带上一堆不该带的东西导致镜像体积大、启动慢、甚至泄露敏感信息。制作前建议做这几步清理清理临时文件和日志/tmp、/var/log下的历史日志、各种缓存目录能删就删。清理软件包缓存不同发行版命令不同Debian 系用apt cleanRedHat 系用yum clean all能省不少空间。移除机器专属信息主机名、SSH 主机密钥、网卡绑定的固定 IP 配置、机器 ID 等。这些如果带进镜像新实例起来会出现主机名冲突、网络配置错乱的问题。以 Linux 为例/etc/machine-id这类文件在制作前清空让新实例首次启动时重新生成。确认没有硬编码的密钥配置文件里的访问密钥、数据库密码如果镜像会被多人使用或跨环境部署务必换成启动时注入的方式。注意清理动作本身有风险建议在制作镜像前先给系统盘打一个快照清理搞砸了还能退回去。这个快照保底、镜像产出的组合是我做镜像的标准动作。3.3 用镜像批量开机器时的网络与初始化处理镜像做好后创建新实例最容易出问题的是网络配置。如果原机器把 IP 写死在了配置文件里新实例起来可能网络不通。正确做法是让网络配置走 DHCP 或由平台在启动时注入。另一个关键是初始化脚本。好的镜像应该配合实例的用户数据User Data机制在首次启动时执行一段脚本完成改主机名、配时区、拉取环境变量、注册到监控等动作。这样同一个镜像能开出配置各异的机器而不是每台都手动改。我一般会在镜像里预置一个开机自检脚本首次启动时检查主机名是否唯一、网络是否通、关键服务是否起来有问题就往日志里写一条明显的标记方便批量部署后快速定位哪台机器没起来。3.4 跨地域复制镜像的注意事项业务扩展到另一个地域时镜像需要复制过去。复制过程本质是把镜像的底层数据传到目标地域耗时取决于镜像大小和网络状况大镜像可能要等挺久。复制前确认目标地域的存储空间和配额够用复制后在新地域用该镜像创建实例验证一遍别等正式部署时才发现镜像有问题。另外镜像复制是一次性的源镜像后续更新不会自动同步到副本需要重新复制这点要记在运维文档里。4. 那些年踩过的坑快照与镜像的典型故障排查4.1 只备份了系统盘数据盘丢了这是新手最常犯的错。以为做了快照就等于整机备份了结果系统盘有快照数据盘没有数据盘一出问题直接傻眼。排查思路很简单出事后先列一下实例挂了几块盘再逐个查每块盘有没有对应时间点的快照。预防办法是给所有云盘统一绑定自动快照策略别只盯着系统盘。4.2 快照回滚后服务起不来前面提过根因通常是回滚到了比预期更早的时间点或者快照创建时业务正在写入导致数据不一致。排查链路是先确认回滚用的快照时间戳再对比服务配置文件的修改时间看是不是配置比快照新。如果是数据不一致检查数据库的恢复日志必要时用逻辑备份补数据。经验是数据库类服务快照前先做逻辑备份双保险。4.3 镜像开出的新机器主机名冲突、网络异常典型症状是新实例起来后主机名跟老机器一样或者网络配置指向了老机器的 IP。根因是制作镜像时没清理机器专属信息。修复办法是进系统手动改主机名、重置网络配置但更根本的是回到镜像制作环节把清理步骤固化进流程。建议把清理清单写成脚本每次做镜像前跑一遍。4.4 快照费用悄悄涨上去了手动快照做多了没人清理月底账单出来吓一跳。排查方法是按云盘维度统计快照数量和总容量找出长期不用的历史快照。治理办法是建立保留策略手动快照标注用途和过期时间定期清理日常备份交给自动策略设置合理的保留份数。快照是保险不是仓库别拿它当长期归档用。5. 一套可复用的备份与复制策略把上面的内容串起来我实际在用的策略是这样的日常靠自动快照兜底关键动作前手动快照保命环境复制靠自定义镜像跨地域靠镜像复制。具体落地时给所有云盘绑定每日自动快照、保留 7 份重大变更升级、迁移、大改配置前手动打一个带清晰命名的快照需要批量部署时从调好的机器做镜像配合初始化脚本开新机跨地域扩展时复制镜像并先验证再上线。这套组合跑下来既不会因为没备份而提心吊胆也不会因为快照堆积而账单失控。真正用熟了会发现快照和镜像不是两个孤立功能而是一条从数据存档到环境复制的完整链路理解了这条链路云服务器的运维才算真正入门。
