1 备份与容灾要回答什么
想象一家小店把订单接口部署在云上：计算实例接收请求，数据库保存订单，对象存储保存附件，身份权限控制谁能读写，网络规则限制访问，监控记录错误与延迟。某天，维护脚本误删了订单。实例还在运行，监控面板也能打开，但客户已经查不到订单。此时，“机器有没有备用”并没有回答真正的问题：业务需要的数据还能不能找回来，多久能够重新接受订单，恢复后怎样确认没有漏单或重复扣款？
备份是为了恢复而保留的数据副本，通常对应某个历史时点。容灾则是面对故障时恢复业务的整体安排，涉及数据、应用、身份、网络、人员和验证。备份可以是容灾方案的重要材料，却不会自动变成可用服务。即使数据库成功恢复，如果应用拿不到凭据、域名仍指向故障入口，或者支付回调无法到达，客户仍然无法下单。讨论容灾时，要把“有副本”推进到“有经过验证的恢复路径”。
先认识 2 个目标。恢复点目标 RPO 表示业务能容忍多大的数据丢失时间窗口；恢复时间目标 RTO 表示业务能容忍多长的中断。小店提出 RPO 为 15 分钟、RTO 为 60 分钟，含义是希望故障后最多损失最近 15 分钟的数据，并在约定计时口径下于 60 分钟内恢复约定功能。它们是业务目标，不是购买某项能力后自然获得的保证。订单、附件、统计报表可以有不同目标，不能随意套用同一组数值。
目标必须配上起止定义。本课把故障发生到业务验收通过作为业务中断的观察区间；演练另记“开始执行恢复”到“验收通过”的操作耗时。发现故障、判断影响、取得权限都可能占用 RTO。RPO 则要根据实际恢复到的业务时间点判断，不能只看备份任务多久执行 1 次。备份失败、尚未完成或者数据本身已经损坏，都会使可用恢复点早于预期。
这张图提醒我们：恢复对象是能完成约定业务的系统。先问“恢复哪些功能、允许丢多少、允许停多久、谁来证明恢复成功”，再选择快照、备份和部署方式。本课聚焦云上备份/快照/复制与受限恢复验收的机制路径；同城与异地拓扑、温备/热备取舍、切换判据等架构决策留给 P13「容灾架构」。高可用接管（副本仍可信时继续服务）与本课的历史恢复点（副本已不可信时回到过去）边界，承接自 C43。
2 备份范围、频率与保留边界
备份范围从业务事实开始列。订单数据库保存订单号、金额、状态和创建时间，是关键记录；附件中的发票或凭证需要与订单关联；应用版本、配置模板、数据库结构变更记录决定旧数据能否被当前程序读懂。可以重新生成的缓存通常不需要按原样恢复，但必须知道由什么数据重建、重建期间会怎样影响服务。日志是否备份，则取决于它是否承担审计、核对或恢复证明的职责，不能把所有日志都当作订单事实。
为每类对象写清责任人与恢复方法。例如，数据库由值班人员按恢复点创建新实例，附件由对象清单核对版本，应用由保存的制品与配置模板重新部署。运行中的实例本身不一定要完整备份，但其重建依据必须能找到。依赖清单还应包含网络入口、访问规则、服务身份、证书和密钥引用。配置里出现密钥标识，并不表示密钥已经被备份；身份策略的文本也不等于恢复人员已经有执行权限。
频率回答“多密地留下恢复点”，保留期回答“能回到多早”。每 15 分钟备份并保留 24 小时，可能适合较快发现的误操作，却无法处理 3 天后才发现的数据污染。每天留下恢复点并保留 30 天，更有利于追查较早的问题，但最近数据窗口可能太大。实际方案可以组合短期较密、长期较疏的保留安排。每层都要说明可恢复的时间范围，不能把“保留 30 天”误解为这 30 天内任何时刻都可恢复。
备份结束时间和恢复点时间也不同。某项任务在 10:08 完成，数据对应 10:00，那么它提供的是 10:00 的恢复点。若任务在 10:08 报错，不能因为任务已经运行过，就把这次时间点算进保障。对外承诺之前，要观察成功率、完成延迟和最近可恢复点的年龄，并预留失败后重试的空间。恢复频率越接近业务容忍上限，连续失败留给人的处置时间就越少。
保留边界还包括副本放在哪里、谁能删除。源数据和备份若完全受同一组高权限凭据控制，凭据泄露可能同时破坏两者。可以按风险设置独立授权、删除保护或保留锁定，并明确紧急操作的流程。锁定也意味着误存的数据不能随意提前清除，因此必须结合隐私、合规和费用要求设计。地域隔离、账号隔离与删除保护解决的风险不同，不能只凭“另存了 1 份”推断故障隔离已经成立。
最后把清单变成可检查的约定：对象、责任人、频率、保留期、存放边界、加密依赖、恢复步骤和验收证据各占 1 列。这样，数据库团队说“已经备份”时，应用团队可以继续确认附件是否同样可用、旧版本程序是否还能取到。范围遗漏往往比备份工具故障更难在任务面板上发现。
3 复制、快照与恢复演练
复制把数据变化传递到另一个副本，常用于减少单个节点故障的影响。它关注的是副本之间保持接近。若错误删除也是正常写入，复制通常会把删除继续传播。因此，副本健康不代表历史数据还在。某些系统还提供延迟复制或历史恢复能力，但必须根据实际配置确认，不能从“有副本”直接推断能够回到误操作之前。复制的延迟也可能使切换后的数据少于原节点最后接收的数据。
快照保存某个时点的存储状态，经常用于创建恢复对象。底层可能只保存变化部分，用户看到的仍可能是完整的可恢复视图。本课不讨论内部实现，先检查接口承诺：快照覆盖哪些资源、何时可用、如何创建新资源、是否依赖原卷，以及删除源资源后如何访问。单个磁盘快照成功，也不一定意味着跨多个磁盘或多个服务的业务数据相互一致。
例如，订单表已经写入“附件已生成”，但附件上传尚未完成，此时分别截取的数据库和对象版本可能无法对应。解决问题的起点是定义一致性边界：哪些状态必须一起成立，哪些可以在恢复后补齐。数据库提供的备份机制通常比直接复制正在变化的数据文件更了解自身一致性要求；跨服务仍需要应用约定。入门演练可以暂停测试写入，记录订单清单和附件清单，再建立明确的恢复点；生产环境的连续写入协调留待后续深入。
备份是恢复材料，快照是常见的材料形式，复制是维持其他副本的机制，恢复演练则检验这些材料是否能组成可用业务。它们可以配合使用。例如，运行副本承担部分节点故障，历史备份处理误删，定期演练验证恢复流程。不要把 3 个不同问题压缩为“已经做了高可用”这句话，否则出现逻辑错误时，很容易只剩下同步后的错误副本。
交互中的恢复顺序从判断故障开始：先停止可能扩大损坏的写入，保留现场与时间线，再选择干净恢复点，在隔离环境中恢复，检查数据和应用，最后才按批准的方案开放业务。停止写入需要业务决策，因为它本身会影响服务；演练中只操作测试入口。恢复时优先创建新对象，保留原对象供比较和调查，避免把仅有的恢复机会覆盖掉。
演练不是只看“恢复任务完成”。它要验证备份能读、密钥能用、身份能授权、网络能连、应用能启动、业务能核对。还要记录每段耗时，找出真正拖慢恢复的环节。若下载数据只用 8 分钟，而等待权限用了 35 分钟，单纯提升存储性能很难显著改善最终恢复时间。
4 动手：完成一次受限恢复验收
这次练习使用独立的测试订单服务，不包含真实客户、支付凭据或生产数据。准备 1 个源数据库、1 个隔离的恢复位置、1 个测试应用实例，以及可以记录操作时间的演练表。恢复位置不能接收正式流量，测试身份只能访问测试资源。提前设定资源大小、预算上限、清理时间和中止条件；遇到权限范围不明、费用超出约定或网络连到生产资源时，立即停止本次测试。
先声明验收合同：订单接口能按订单号查询，订单数量与金额汇总匹配，关键附件能读取，测试应用可以新增并再次查询订单。练习目标取 RPO 为 15 分钟，RTO 为 60 分钟。演练表分别记录模拟故障时间、开始恢复时间、资源可连接时间、应用可查询时间和最终验收时间。这样得到的时间可以复核，也能区分等待、数据恢复和业务核对消耗。
第 1 步，建立基线。使用合成数据创建 120 条订单，总金额为 18600 元，并保存按订单号排序的清单、金额汇总和附件对应关系。在 09:58 写入易识别的标记订单，记录它属于这 120 条订单。金额汇总统一采用系统规定的金额单位与精度，避免浮点显示差异造成误判。为附件记录对象标识和内容校验值，记录数据库结构版本与应用制品版本。基线清单保存在测试数据库之外。
第 2 步，生成恢复材料。通过当前平台正式支持的备份或快照入口创建恢复点，等待任务成功且可用于恢复，记录其标识与数据对应时间。本例设定恢复点对应 10:00，且在模拟故障之前已经可用；若实际任务未按时完成，应顺延练习并记录真实时间。在 10:03 新增 1 条测试订单，保存它的编号，确认它不在 10:00 的清单中。此后暂停其他测试写入，避免核对范围不断变化。
第 3 步，模拟故障。到 10:05，仅在源测试数据库中删除预先选定的少量测试订单，记录受影响编号，保持备份不变。确认测试应用确实出现查询缺失，以证明练习覆盖了真实故障表现。不要清空整个测试账号，也不要删除密钥或唯一备份来制造故障。若平台不能提供可靠隔离，就用另建测试数据集的方式进行练习，不能把生产系统当作验证隔离能力的地方。
第 4 步，在 10:20 开始执行恢复，选择 10:00 的干净恢复点，并创建新的数据库对象。记录选择理由：它早于 10:05 的删除，并且有可比较的基线。用测试身份检查解密与访问权限，再把测试应用的连接配置指向新数据库。保持恢复应用的外部通知、支付调用和消息消费关闭，防止历史订单触发新的副作用。开放写入之前，先以只读查询完成基线核对。
第 5 步，执行验收。核对 120 条基线订单、18600 元汇总、09:58 标记订单和附件校验值；确认被误删的订单已经回来，10:03 新增的订单不在恢复结果中。随后只在隔离应用中新建 1 条验收订单，再按编号读回，单独记录它，避免与基线数量混淆。数量相等仍可能包含错单，因此必须同时比对订单编号及关键字段，并检查应用返回状态和错误日志。
假设最终在 11:02 验收通过，开始恢复到通过用了 42 分钟，而从 10:05 故障到通过用了 57 分钟；按本课口径，观察到的中断时间为 57 分钟，满足本次 60 分钟目标。恢复点比故障早 5 分钟，时间窗口落在 15 分钟目标内，但 10:03 的订单确实丢失，必须在报告中列明。目标允许窗口，不代表允许隐瞒实际丢失。最后保存记录，按约定清理临时资源；测试原始备份则按既定保留策略处理。
5 成本与恢复粒度取舍
备份费用不只来自存储容量。备份任务、保留副本、跨边界传输、恢复时临时创建的计算与数据库资源、解密请求和人工演练都可能产生费用。具体计费以所用服务的规则为准，不能把某个平台的单价当作通用规律。更密的恢复点通常增加任务和管理负担，更长的保留期扩大历史覆盖；底层若使用增量保存、压缩或去重，实际存储增长未必与恢复点数量成正比。
恢复粒度决定为找回少量内容需要付出多大代价。整库恢复便于得到相对完整的历史状态，但找回 1 条订单时，也可能先创建整库再提取记录。直接用旧库覆盖现库，会把其他正确的新订单一起回退。对象级恢复可能更细，却仍需要确认对象与数据库引用是否匹配。选择能力时，应拿“误删 1 条订单”“整库不可用”“附件部分损坏”等具体事件来比较，而不是只比较功能名称。
对小店而言，少量订单恢复往往包含 2 段工作：先在隔离环境恢复旧数据，再把经过审核的记录补回当前系统。补回前需要检查订单状态、唯一标识和关联记录，避免重复处理付款或库存。批量回填、事务冲突等细节超出本课范围，但方案至少要承认“恢复旧副本”和“安全合并到当前业务”是不同阶段。前者成功，不能直接把后者计为完成。
滑块使用简化模型：假设每个恢复点独立保存完整数据，不考虑压缩与增量；用数据量、间隔和保留天数估算逻辑保存量，再用恢复吞吐量估算数据传输时间。它帮助理解方向，不提供实际账单或恢复保证。把恢复点间隔缩短，会使理想条件下的时间窗口缩小，却不会自动减少权限检查、应用配置和验收耗时。传输更快也不能消除检测故障所花的时间。
合理取舍从业务分层开始。订单事实要求较小的数据窗口；能够重新计算的日报可能容忍更长等待；缓存可以重建，但要估算重建对接口的影响。每层分别确定恢复目标和证据，再计算长期费用与演练成本。如果预算无法覆盖目标，应让业务负责人选择降低目标、缩小保障范围或增加预算，不能让未被验证的假设替代取舍。
6 常见坑：只备份不演练恢复
最常见的误判是把绿色任务状态当作恢复成功。任务成功只说明某个步骤按工具规则结束，无法证明恢复人员仍有权限、历史密钥仍可用、应用版本仍兼容。只要这些依赖发生变化，原本可恢复的备份就可能变成无法落地的材料。演练应在应用重大升级、身份策略调整或密钥生命周期变化后重新安排，并根据业务风险设置常规频率。
另一个坑是只看最新备份。数据污染可能持续数天，最新的多个恢复点已经含有同样错误。此时需要结合审计日志、业务核对与故障时间线，寻找最早异常之前的干净点。若保留期短于发现延迟，即使任务全部成功，也可能没有可用历史。恢复点选择不能靠“越新越好”，而应靠“满足业务状态且损失范围已说明”。不确定时先在隔离环境验证候选点。
还有一种表面成功发生在网络和身份环节：新数据库创建好了，应用却仍访问旧地址；或者测试人员能连接，服务身份不能连接。应从应用实际使用的网络路径、身份和配置进行检查，而不是只用管理员控制台查询。恢复后也要检查定时任务、消息消费和外部调用的开关，避免服务启动立即重放历史行为。开放业务需要业务验收，不能只由资源创建状态触发。
失败路径交互把问题分成可观察的检查点。找不到备份，就核对目录、对象范围与保留规则；恢复被拒绝，就检查当前身份和所需密钥；数据可读但对不上，就检查恢复点、一致性边界与应用结构版本；业务仍失败，就检查连接、依赖和入口。检查过程中保留原始错误、资源标识和时间，避免反复尝试后只剩“后来好了”的口头描述。
演练也可能被自己的简化条件误导。例如，每次都由最高权限管理员操作、只恢复很小的数据集、完全跳过审批等待，都会低估真实耗时。可以从受限测试开始，再逐步补齐正常值班人员、接近真实的数据规模和关键依赖。测试范围之外的能力要标为尚未验证。没有测过跨地域恢复，就不能因为同地域演练成功而写成跨地域已经达标。
7 案例：加密密钥丢失使备份失效
某团队长期备份订单数据库，任务每天都显示成功。备份内容使用指定密钥加密，恢复服务通过授权获得解密能力。后来团队清理旧环境，只核对数据库和存储资源，没有追踪密钥依赖。旧密钥最终被永久删除。数周后，团队需要恢复保留期内的历史订单，备份文件仍在，容量和时间记录也正常，恢复任务却在解密阶段失败。
问题不在于有没有保存文件，而在于恢复所需的条件已经不完整。加密备份通常需要可用的密钥材料、相应版本，以及执行解密的授权。具体依赖取决于服务实现，可能还涉及包装数据密钥的上层密钥。入门阶段不必推导密码学过程，只需掌握这个结论：读取加密文件和获得可解密的数据，是不同能力。备份目录中写着密钥标识，不能让已经永久丢失的密钥重新出现。
事件处理中，团队先确认错误发生在解密阶段，再区分权限撤销、密钥停用和密钥永久删除。前 2 类在符合管理规则的情况下可能通过恢复授权或重新启用解决；若所需密钥材料已经不可恢复，且没有其他可用解密路径，这份备份就不能靠重试任务恢复。复制加密文件、提高管理员权限或更换新密钥，都不能自动解开原有密文。不能把等待时间不断延长当作恢复计划。
改进时，团队把密钥纳入恢复依赖清单，记录备份关联的密钥标识、使用范围、责任人、停用与删除流程，并把旧备份最后需要解密的日期纳入生命周期判断。密钥轮换也要确认历史版本与已有备份的可恢复性，不能只测试新写入的数据。对关键删除操作设置必要的保护和复核，在变更后使用正常恢复身份抽样恢复历史备份。
修复方案不应是把明文密钥随手放进同一个备份目录。这样既可能扩大泄露风险，也没有建立独立的恢复控制。应使用所选平台支持的密钥保护与恢复机制；若机制不允许导出密钥，就据此设计保留、授权和删除边界。最终验收证据应包含“指定历史备份能由指定恢复身份解密并完成业务核对”，而不仅是“密钥列表里还能看到名称”。
8 把恢复路径写进容灾方案
容灾方案首先要写清适用事件与不适用事件。例如，本阶段覆盖订单误删和数据库实例故障，尚未验证整个地域不可用。每种事件都要有触发条件、影响范围、目标功能和负责人。触发条件应能由监控或业务证据支持，如持续查询失败、关键记录缺失，不能只有“发生严重故障时”。误删与硬件故障可能需要不同恢复点，也不一定由同一条流程解决。
随后写出可以照着执行的依赖顺序：确认事件并控制损坏范围，定位可用备份与密钥，准备网络和身份，创建恢复资源，部署匹配应用，核对数据与业务，按决策开放入口。顺序可以根据平台调整，但依赖必须明确。例如，创建数据库前可能就需要解密授权；核对附件之前需要对象读取权限；开放入口前需要确认外部副作用的控制方式。流程中的每个等待都要有负责人和升级路径。
运行手册要记录稳定的查找方法，而不仅是几张控制台截图。截图可能因界面变化失效，资源标识和操作入口也可能随环境变化。更有用的内容包括：备份目录在哪里、如何辨认目标环境、恢复身份如何取得、所需配置由谁维护、每个步骤如何判定成功，以及失败时退回哪个检查点。凭据本身不应直接写进普通文档，应记录受控获取方式，并在演练中验证能否取得。
时间预算要覆盖完整路径。若业务 RTO 是 60 分钟，可以先为发现与决策分配 10 分钟、准备依赖分配 10 分钟、恢复数据分配 20 分钟、业务验收与开放入口分配 20 分钟。这只是设计预算，实际演练会暴露偏差。不能因为数据恢复用时符合分配，就忽略前段已经超时。若步骤串行执行，总耗时需要累加；可并行的准备也要确认人员和依赖确实允许并行。
方案还需要处置尚未恢复的数据。恢复点之后已接收的订单可能需要从其他可信记录核对补录，但支付回执、消息或访问日志是否足够，必须事先验证，不能临时假定它们完整。明确谁判断客户影响、谁批准补录、谁检查重复处理，以及何时向业务方报告。RPO 说明允许的时间窗口，业务对账说明窗口内实际发生了什么，二者应在事件报告中同时出现。
每次演练完成后，保存目标、范围、恢复点、实际耗时、核对结果、遗留问题和责任人。遗留问题要有完成期限，修复后验证受影响的步骤。流程变更、数据规模增长和人员轮换都会使旧结果逐渐失去代表性，因此方案应标注最近演练日期与适用环境。文档是否存在只是起点，最近的证据能否支持当前承诺，才决定这份方案有多可信。
9 从备份与容灾走向容灾架构（P13）
本课得到的是经过验证的恢复路径，它也为下一步选择容灾架构提供依据。如果演练表明主要时间花在创建环境和恢复大量数据上，那么预先准备部分资源可能改善恢复速度；如果主要时间花在发现错误、寻找密钥和人工判断上，增加运行副本并不会自然解决这些问题。先根据时间线定位瓶颈，再讨论架构投入，能避免花费增加却仍达不到目标。
后续 P13「容灾架构」会在本课已验证的恢复材料之上，比较冷备、温备、热备等准备程度，以及同城/异地故障边界与切换判据。现在先建立直觉：提前准备越多，故障后临时完成的工作可能越少，但日常成本、配置同步和切换管理也可能增加。多处部署还会引入数据传递、写入协调和业务入口选择等问题。不能把“复制到另一个地方”直接等同于容灾设计完成；也不能把本课的恢复手册误当成拓扑 ADR。
从备份走向架构时，要带着同一组业务问题。订单写入能否短暂停止，查询能否先恢复，附件能否延后开放，哪个地点保存可信记录，哪类故障会同时影响备份和恢复环境？按功能拆分目标，有时可以先恢复查询，再处理新订单写入。但这种降级必须事先约定并能清楚告知业务方，不能在故障后临时把“部分能用”算作原目标已经实现。
还要区分恢复演练与切换演练。前者验证历史材料能否重建业务，后者更关注运行服务如何迁移到其他资源以及如何避免错误入口与重复处理。两者都需要数据核对、身份与网络准备，也都要考虑恢复后的稳定观察。切换到新环境后，原环境何时恢复、如何回到正常运行状态，也属于需要规划的工作，后续课程会展开。
进入 P13 前，请能拿出订单服务的依赖清单、RPO 与 RTO 的计时口径、至少 1 次受限恢复的证据，以及尚未验证的故障范围。若这些材料缺失，架构图上的备用箭头就很难解释实际能承受什么。架构选择应建立在可恢复事实之上，并持续用演练校正对成本、时间和风险的判断。
放进方案里
在你的云方案中增加“备份与恢复”页，以具体业务功能开头。例如，订单查询与写入的 RPO 为 15 分钟、RTO 为 60 分钟，报表允许次日重建。注明中断从故障发生计时，到约定业务验收通过结束；演练另外记录开始恢复后的操作耗时。列出暂未覆盖的事件，尤其说明是否验证过地域级故障，避免读者把有限测试结果理解成全面保障。
把订单库、附件、应用制品、配置、身份、网络与密钥依赖放进恢复清单。每项写明责任人、恢复依据、频率、保留期、存放边界和删除保护。配置模板需要给出受控查找路径，密钥需要记录标识、历史版本使用要求及授权获取方式。区分可重建的内容与不可替代的业务事实，并说明重建会占用多少恢复时间。
附上按顺序执行的恢复流程：判断故障、控制影响、选择干净恢复点、准备依赖、隔离恢复、部署应用、业务核对、决定开放入口。给每段分配时间预算，指定执行人与验收人，并写清失败时的检查点。数据库可连接只是中间状态，订单编号、金额、附件和测试写入通过后，才按约定判定业务恢复。
最后填写最近演练日期、数据规模、恢复点、实际丢失窗口和完整耗时，并附可复核的结果。证据中关联备份标识、恢复实例标识与核对清单，保存缺失订单编号和附件校验结果；任一关键附件不可读或金额不符，都应判为验收未通过，并保持正式入口关闭。列出恢复点之后订单的核对办法、临时资源清理时间、预计费用范围和未完成事项。若演练没有达到目标，写明差距、责任人与改进期限；若尚未演练，则明确标为待验证，让下一步容灾架构设计围绕这些缺口展开。
10 小结：下一步容灾架构（P13）
备份保存恢复材料，容灾组织业务恢复。RPO 要用实际恢复点和故障时间核对，RTO 要按约定边界观察完整过程。复制可能传播误操作，快照需要确认一致性与依赖，密钥和恢复权限也必须跟着历史数据保留下来。
自测时，试着解释 3 件事：最新备份为什么可能不是干净恢复点；恢复任务成功后还需要哪些业务证据；怎样区分数据恢复耗时与业务中断时间。能结合自己的服务回答，才算把概念落到了恢复路径上。
下一步进入容灾架构（P13），将根据已验证的恢复目标与瓶颈，比较不同准备程度和故障隔离边界，并继续用演练检验架构承诺。