云服务器快照是什么？快照备份、恢复与使用注意事项

云服务器快照常被理解为“给磁盘拍一张照片”。这个比喻方便入门，但容易让人误以为快照会立刻复制整块磁盘，也容易忽略数据库一致性、跨盘关系和恢复验证。快照能快速保留某个时间点的块设备状态，特别适合系统升级、批量变更和短期回滚，但它并不是完整的数据保护方案。

这篇文章会解释写时复制与增量快照的原理，区分快照、镜像和备份，并给出创建前停写、fsfreeze、恢复前检查和演练步骤。不同云平台在快照实现、地域复制、保留和计费上存在差异，实际能力与价格必须以服务商官网为准。

快照怎样保存一个时间点的磁盘状态

云硬盘通常被划分为许多数据块。第一次创建快照时，平台需要记录该时间点所有有效数据块的内容或引用关系；后续快照通常只保存相对前一次快照发生变化的块，因此常被称为增量快照。用户看到的每个快照仍然像一份完整磁盘，可以独立发起恢复，增量链的拼接和引用由平台在后台处理。

很多快照系统使用写时复制思路。创建快照后，当某个已有数据块即将被覆盖，平台先保留旧版本，再把新数据写入当前磁盘。也有系统采用重定向写，把后续变更写到新位置，让快照继续引用旧块。具体实现会因存储架构不同而变化，但共同目标都是避免每次快照都同步复制整盘，从而缩短创建入口的等待时间并节省重复数据占用。

“快照已创建”与“后台数据已完全复制到持久存储”可能是两个阶段。部分平台会先快速生成一致的时间点视图，再异步上传或固化数据。只有控制台显示快照状态可用后，才能把它视为可恢复对象。实例磁盘很大、首次快照或变更块很多时，后台完成时间通常更长。

增量并不意味着恢复必须由用户手工按顺序应用每个快照。成熟平台会维护依赖关系，删除某个旧快照时，仍被后续快照引用的有效数据通常会被保留或合并。不过，删除后的空间释放速度、快照依赖和最低保留粒度以平台规则为准，不能用本地文件的思维推断。

快照还分为崩溃一致性与应用一致性。崩溃一致性类似服务器突然断电时的磁盘状态：已经提交到块设备的内容会保留，仍在应用缓存中的数据可能没有落盘。文件系统一般能通过日志恢复结构，但数据库事务和多文件关系是否正确，取决于数据库自身恢复机制。应用一致性则要求在快照点暂停或协调写入，让相关数据处于可解释、可恢复的状态。

快照、镜像和备份有什么区别

三者都能用于恢复或复制，但目标与边界不同：

镜像更像创建服务器的模板。它通常包含可启动操作系统、基础软件和初始化配置，用来批量启动实例。镜像中的主机名、机器标识、SSH 主机密钥和应用凭据需要在克隆后处理，不能把一台生产机不加清理地复制给多个环境。镜像也不适合高频保护持续变化的数据库数据。

备份强调可恢复的数据副本和保留策略。MySQL 逻辑备份可以恢复到新库并检查表，文件备份能找回单个目录，对象存储版本能找回被覆盖对象。备份可以放到不同账号、不同地域甚至不同服务商，从而隔离源平台故障和账号风险。

快照与备份不是互斥关系。常见做法是在变更前创建快照，用于数小时或数天内快速回滚；同时按日执行应用一致性备份，并将备份保存到异地独立存储。关键数据还应保留多个历史版本，防止逻辑损坏在一段时间后才被发现。

创建快照前怎样保证数据一致性

普通文件系统至少要同步缓存

在低写入的普通文件服务器上，创建前可先让用户态缓冲与内核脏页尽量落盘：

sync

sync 只能推动文件系统写回，不会让数据库自动进入一致备份状态，也不能阻止下一秒又有新写入。业务仍在修改多个关联文件时，单独执行它不足以获得应用一致性。

更可靠的方法是在短维护窗口停止写入服务。先从负载均衡摘除节点，等待请求结束，暂停定时任务和队列消费者，再优雅停止应用或数据库。示例中的服务名必须替换成真实单元：

sudo systemctl stop myapp.service
sudo systemctl stop mariadb.service
sync

快照状态进入平台要求的阶段后，再按正确依赖顺序启动：

sudo systemctl start mariadb.service
sudo systemctl start myapp.service

风险提示：停止服务会造成维护窗口，顺序错误可能导致写入失败。操作前应确认流量已切走、队列已暂停、数据库完成正常关闭，并准备控制台回滚。不能把示例服务名直接复制到生产环境。

fsfreeze 适合短时冻结独立数据盘

fsfreeze 可以暂停某个已挂载文件系统的新写入，并把脏数据刷到磁盘。它适合独立挂载的数据盘，例如 /data：

findmnt /data
sudo fsfreeze --freeze /data
# 立即在云控制台或 API 发起该数据盘快照
sudo fsfreeze --unfreeze /data

冻结期间，对该文件系统的写操作会阻塞。必须提前准备解冻命令并把冻结窗口压到最短，确认快照在哪个状态即可解冻。不要随意冻结根文件系统，因为 SSH、日志和系统服务也可能需要写根盘，远程会话可能卡住。若操作失败，应通过云控制台执行解冻，并确认应用恢复。

fsfreeze 只保证文件系统层面的静止，不理解数据库事务。数据库可能还有自己的内存页、日志和跨盘关系。应优先使用数据库官方备份锁、备份工具或正常停写流程，再结合文件系统冻结。

多块磁盘必须形成同一个一致性点

应用数据、数据库日志和数据文件分布在多块云盘时，逐块手工点击快照可能形成不同时间点。例如先快照数据盘，几秒后再快照日志盘，中间仍有事务写入，恢复后两者可能不匹配。应使用平台提供的一致性快照组或多盘快照能力，并让应用先进入一致状态。

数据库主从架构可以在经过确认的副本上制作备份或快照，以减少主库停写时间，但必须先检查复制延迟、只读状态和数据完整性。一个落后十分钟的副本即使快照技术完全成功，恢复点也仍然落后十分钟。

数据库要采用应用感知流程

MySQL、PostgreSQL、Redis 等都有自己的持久化和备份机制。生产库不应只执行 sync 后拍盘。更稳妥的方案是使用官方物理备份工具、逻辑导出、托管服务备份，或在维护窗口正常停止数据库后创建快照。

如果使用数据库锁协调快照，必须理解锁的生命周期、会话断开和复制影响。网上常见的一条锁表命令并不构成完整方案：执行锁的会话必须持续保持，快照开始与解锁时机要严格控制。团队没有成熟自动化时，短暂停写加正常关闭通常比半套锁表脚本更安全。

恢复快照前必须完成哪些验证

快照恢复是高影响操作。直接把生产盘回滚到旧时间点，会覆盖快照之后的数据，并可能让应用、数据库和外部系统状态不一致。恢复前至少确认以下事项：

1. 确认目标资源：核对账号、地域、可用区、实例、磁盘标识和挂载点，避免选错同名资源。
2. 确认恢复点：记录快照创建时间、时区、来源磁盘、状态和应用一致性方式，确认满足恢复点目标。
3. 保护当前状态：即使当前磁盘已损坏，也应先创建快照或独立副本，保留后续取证与补数据机会。
4. 评估数据差异：列出快照时间之后可能丢失的订单、消息、上传和配置，确定是否能从日志或其他系统补回。
5. 确认依赖关系：数据库、应用、对象存储、消息队列和第三方系统的状态是否需要一起回退。
6. 准备维护与回滚：停止写入、通知相关人员、保留原盘，不要在第一次尝试时直接覆盖唯一副本。
7. 验证权限与网络：恢复到新实例时，确认安全组、私有地址、密钥、主机身份和加密密钥是否可用。

首选方法是从快照创建一块新云盘或新实例，在隔离网络中验证，而不是覆盖原盘。挂载前先查看设备和文件系统：

lsblk -f
sudo blkid

把恢复盘挂载到临时目录时，设备名必须来自实际环境。只读挂载可以降低误写风险：

sudo mkdir -p /mnt/restore
sudo mount -o ro /dev/实际恢复分区 /mnt/restore

某些日志型文件系统即使只读挂载也可能尝试日志恢复，严格取证场景应使用文件系统专用的只读、禁止日志重放选项，并由熟悉该文件系统的人员操作。不要猜测设备名，更不能对生产盘运行格式化命令。

验证不能只看“能挂载”。文件级验证应检查关键目录、文件数量、大小、权限和抽样校验和；数据库应在隔离实例启动，执行一致性检查、关键表行数、最近业务记录和只读查询；应用应完成登录、查询、上传和后台任务等冒烟测试。

还要验证恢复耗时。快照创建新盘后，部分平台可能在首次读取冷数据块时延迟较高，预热策略因平台而异。演练应记录从发起恢复到业务可用的完整时间，并与恢复时间目标比较。没有实际演练的恢复时间只是估计。

验证通过后再制定切换方案，包括停止生产写入、补齐增量数据、更新挂载或连接地址、启动顺序、健康检查和回滚条件。原盘至少保留到业务稳定且数据负责人确认，不能切换成功后立即删除。

快照为什么不能替代异地备份

第一，快照与源磁盘常由同一云账号和平台管理。账号凭据泄露、权限误配或自动化脚本错误可能同时删除实例与快照。独立账号、跨地域和不可变备份能扩大故障隔离边界。

第二，快照会忠实保存逻辑错误。如果误删除数据、程序写坏文件或勒索软件加密内容，在发现问题前创建的新快照也会包含损坏。需要多个历史恢复点和足够长的保留周期，才能回到问题发生之前。

第三，快照通常是块级状态，单文件或单表恢复不一定方便。独立文件备份和数据库备份能提供更细粒度的恢复，也更容易做内容校验。把整盘恢复到临时环境只为找回一个配置文件，时间与成本都更高。

第四，快照的跨平台迁移能力有限。服务商级故障、账号冻结、地域不可用或产品变更时，同平台快照可能无法满足恢复需求。使用开放格式的数据库导出、对象副本和文件归档，可以在其他环境重建业务。

可以采用“三份数据、两种介质或系统、一份异地”的思路：生产数据是一份，同平台快照是一份，独立账号或异地存储中的应用备份再一份。关键备份设置不可变保留或删除保护，并把恢复权限与日常实例管理权限分离。

快照和备份都必须演练。只看到任务显示成功，不能证明数据可读、密钥可用和恢复步骤完整。建议定期随机选择恢复点，在隔离环境完成恢复并记录校验结果、耗时和问题。

计费、保留和权限管理注意事项

快照通常按实际占用的存储量和保留时间计费。增量快照只记录变化块，但删除文件并不一定立刻减少已有快照占用，因为旧快照仍需要保留删除前的数据块。频繁改写大文件、数据库数据文件或大容量临时文件，也可能产生较多变化块。

不能根据磁盘“已用文件大小”直接推算快照账单。文件系统删除、块回收、压缩、增量依赖和平台计量都会影响结果。跨地域复制、快照归档、快速恢复和出站流量也可能另行计费，具体价格以官网为准。

保留策略应与恢复目标匹配。例如，短期变更保护可以保留数个小时到数天；日常数据保护可按日、周、月建立不同层级。不要无限保留每小时快照，也不要只保留最近一个版本。应根据数据变化率、发现逻辑错误所需时间、合规要求和预算确定周期。

自动快照策略要监控失败、超时和配额。磁盘标签与实例名称可能变化，仅靠名称匹配容易漏盘。策略应记录磁盘唯一标识、快照状态、应用一致性执行结果和删除审计。删除旧快照前确认不再受合规保留和事件调查约束。

权限遵循最小化原则。应用运行账号通常不需要删除快照；备份自动化账号可以创建和列出快照，但删除权限应单独控制。为关键快照启用删除保护、跨账号复制或不可变策略，并对大量删除、共享范围变化和加密密钥操作设置告警。

加密磁盘的快照通常也受密钥约束。即使快照对象还存在，密钥被删除、禁用或权限丢失也可能导致无法恢复。备份设计必须同时保护密钥、记录密钥标识，并演练跨账号授权。不能把密钥与唯一备份放在同一个容易同时删除的权限边界内。

常见问题

在线创建快照会不会影响业务？

平台通常允许在线快照，但后台读取变化块可能带来一定 I/O 影响，具体取决于实现。更重要的是在线写入会影响应用一致性。关键数据库应使用应用感知流程或维护窗口。

增量快照删除中间一个，后续快照还能恢复吗？

主流平台通常会维护引用并保留后续恢复所需数据，用户不需要手工拼链。但删除语义、空间释放时间和限制应以平台文档为准，重要数据删除前先做恢复验证。

执行 sync 后就一定是应用一致性吗？

不是。sync 只推动文件系统缓存写回，不理解数据库事务、应用缓存和多盘关系。应暂停写入并使用数据库官方备份机制，必要时配合 fsfreeze 或一致性快照组。

快照恢复应该直接覆盖原磁盘吗？

不建议第一次就覆盖。优先创建新盘或新实例，在隔离环境验证文件、数据库和应用，再安排切换，同时保留当前磁盘作为回滚与补数据来源。

有每日快照还需要数据库备份吗？

需要。数据库备份能获得更明确的应用一致性和更细恢复粒度，也能存到异地独立账号。快照适合快速整盘恢复，两者应组合使用。

总结

• 云硬盘快照通过写时复制、重定向写和增量块等机制保存时间点状态，每个快照对用户仍表现为可独立恢复的完整视图。
• 快照用于快速回滚，镜像用于批量创建环境，独立备份用于长期、细粒度和跨故障域的数据保护。
• 关键业务创建快照前必须停写或使用应用感知机制；fsfreeze 只冻结文件系统，不能替代数据库一致性流程。
• 恢复前要核对资源与恢复点、保护当前状态，并优先在新盘或隔离实例验证，不能直接覆盖唯一生产副本。
• 快照通常与源环境共享账号和平台风险，不能替代跨账号、跨地域、可验证且具备不可变保护的异地备份；计费与限制以官网为准。