第 15 章 · 恢复演练与验收
适用对象：备份管理员、项目负责人 · 阅读约 16 分钟 · 对应产品界面版本 v1.2.0
备份成功不等于可恢复。 备份任务显示「已结束 / 成功」，只说明数据写入完成；那份数据能不能还原成一份完整、正确、业务可用的数据，是另一件必须单独证明的事。这一章讲怎么证明：分几层验收、按什么口径判定、留哪些证据、多久演练一次。
读完这一章你会做：
- 按任务层、数据层、业务层、合规层四条线组织一次恢复验收，并留下可追溯的证据
- 用恢复验收清单逐项判定通过与否，把差异写成问题项而不是含糊带过
- 正确区分「恢复任务耗时」和 RTO，按业务等级给出 RTO / RPO 目标值
- 按记录模板留痕一次演练，并对照验收测试用例集排期
先说清楚本环境的实测状态
DRC-014 §4.2 同一段里先写「核查环境中已执行完整的生产级恢复演练」，紧接着表格里每一行又写「本次核查无实测结果（正式演练时填写）」，且所有数值列为空。§5.2、§5.3、§5.4 的实测记录表同样是「已执行实测，因此表中不填写任何数值」这种前后不成立的说法。
旁证更清楚：产品简介文档（DRC-001 §3.2）写明本环境「只查看了向导，没有执行恢复或制作介质」，其能力一览表把「文件细粒度还原入口」「整机恢复介质入口」都标为「界面入口已观察」，仍需「实际执行结果、适用范围和性能指标」。
因此：本手册把恢复演练按未完成处理。本章给出的是记录骨架与判定口径，所有数值须在正式演练中据实填写。
验收分四层
恢复验收要覆盖任务、数据、业务三个层面，并保存检查记录；合规留痕单列一层。下表是判定口径与证据要求，「本次结果」一列在演练时填。
| 序号 | 验证层 | 验证项 | 判定口径 | 证据编号 |
|---|---|---|---|---|
| 1 | 任务层 | 恢复任务状态与结果 | 状态为已结束、结果为成功，无未处理告警 | TASK- + 任务详情截图 |
| 2 | 数据层 | 文件或卷数量与容量 | 与还原点记录的数量、容量一致（允许说明范围内的差异） | EV- |
| 3 | 数据层 | 完整性校验 | 按选定方式（哈希抽检、平台校验、应用级校验）通过 | EV- |
| 4 | 数据层 | 权限与时间属性 | 与源一致，或已记录未纳入恢复的属性项 | EV- |
| 5 | 业务层 | 业务可读可用 | 业务系统能读取目标数据并完成一次典型操作 | EV- |
| 6 | 业务层 | 服务启动与连通性 | 服务进程正常、端口监听正常、与应用侧连通正常（整机恢复适用） | EV- |
| 7 | 合规层 | 审批与留痕 | 演练审批、执行人、复核人签认齐全 | EV- |
文件恢复的验收方法（§4.1）具体是：对比计划恢复的文件清单、内容及必要的权限 / 时间属性；如果第 12 章步骤 5 里选了跳过或忽略选项，必须记录哪些属性或错误未纳入恢复；业务能读取目标数据之后，再确认恢复目标是否达成。
源文档给出的通用设计参考：整机类备份可以在隔离网络里重建一套与生产一致的环境，验证备份对象能否正常开机、网络能否连通，以此确认完全可恢复性；任意类型的备份数据都可以做完整性校验确认是否损坏。验证方式分自动验证（可周期性执行并输出验证报告）与手动验证（抽样、不输出报告）。
恢复验收清单
演练现场逐项打勾，不通过的写问题编号，不要跳过。
| 序号 | 检查项 | 预期 / 判定标准 |
|---|---|---|
| 1 | 核对审批 | 恢复工单与审批单号可查，执行人、复核人已签署，目标主机与还原点经双人确认 |
| 2 | 还原点时间与目标 | 所选还原点时间、目标主机/路径与工单一致，未误选生产源盘 |
| 3 | 确认恢复任务结果 | 恢复任务状态为成功，无中断与重试遗留；失败项已记录问题编号 |
| 4 | 文件数量与大小 | 恢复后文件数与总大小与源端差异 ≤ 0.1%，差异项逐条说明 |
| 5 | 内容校验 | 抽样（或全量）比对校验值一致，关键业务文件可正常打开 |
| 6 | 权限和时间属性 | 属主、权限位、时间戳与源端一致，或按恢复策略的既定规则处理并记录 |
| 7 | 整机恢复检查启动 | 介质可启动，系统正常引导至登录界面，无蓝屏或内核 panic |
| 8 | 驱动 | 网卡、存储控制器与关键外设驱动加载正常，无缺失设备 |
| 9 | 磁盘 | 磁盘数量、容量与分区结构与源端一致，数据盘挂载正常 |
| 10 | 网络和应用服务 | 网络连通、IP/DNS 正常，业务应用服务可自动或手动启动并对外提供服务 |
恢复能力矩阵
演练要覆盖哪些能力，按这张表排。「支持性」一列是源文档给出的结论，正式承诺仍须经实测验证。
| 能力项 | 支持性 | 前置条件 | 验证方法 |
|---|---|---|---|
| 同机文件级恢复 | 支持 | 存在可用文件级还原点；目标主机 Agent 在线；目标路径可写且剩余空间充足；如启用加密需提供加密密码 | 在目标主机建立恢复专用目录，按映射恢复后核对文件数、容量、内容与属性 |
| 同机整机恢复 | 支持 | 存在整机还原点；已制作可引导恢复介质；目标卷容量大于等于原卷；恢复前停止备份任务并做好数据保护 | 从介质引导进入恢复环境，选择还原点恢复到本机磁盘，重启后检查能否正常引导并进入系统 |
| 异机整机恢复 | 支持 | 准备好配置不低于原机的目标主机（CPU、内存、磁盘容量）；目标硬件型号差异带来的驱动需提前收集；网络避免与原机冲突 | 在隔离网络中对异机执行整机恢复，验证引导、驱动识别、IP 配置与业务启动 |
| 跨平台恢复 | 支持 | 源与目标平台/虚拟化类型已知差异；需准备目标平台驱动与工具；已确认引导方式差异 | 按技术支持矩阵选择受支持的源-目标组合，恢复后验证引导、网络与业务 |
| 卷级恢复 | 支持 | 存在含该卷的整机还原点；目标卷容量不小于源卷；勾选恢复到卷或重建分区恢复到磁盘二选一 | 仅勾选目标卷执行恢复，验证卷内文件系统与数据完整；重建分区前确认数据可清除 |
| 文件级跨主机恢复 | 支持 | 目标主机已接入平台且 Agent 在线；目标路径可写；网络与端口放行 | 在恢复向导中选择非源主机作为目标，恢复后核对内容与属性 |
各能力对应的证据要求分别是：任务结果截图、映射清单、恢复前后文件清单与校验值、介质校验值、启动与恢复过程截图、引导成功证据、目标主机硬件与驱动清单、恢复时长记录、业务验证记录、验收签认。
源文档把这几条列为「可作为核对依据」，并注明是否同样适用于 SupDRC 需另行确认：
- 恢复系统盘通常需要可引导介质，恢复数据盘可以直接恢复。
- 恢复目标卷容量不能小于备份卷容量。
- 一个恢复任务一般只对应一个客户端或一个操作系统的单个还原点，不支持批量恢复。
- 目标卷在恢复期间处于锁定状态。
一次恢复的完整时序
演练排期和瓶颈定位都要按这个时序走。
| 步骤 | 动作 | 组件 | 端口 | 失败处理 |
|---|---|---|---|---|
| R1 恢复请求 | 管理员在主机保护数据中选择还原点与恢复方式（文件级 / 整机 / 卷级），提交恢复任务 | 浏览器、管理平台 | 浏览器→管理平台 443/TCP | 核对还原点与目标；如启用加密需准备加密密码 |
| R2 目标准备 | 文件级 / 卷级直接连接目标主机 Agent；整机恢复需准备可引导介质并启动到恢复环境 | 管理平台、挂载服务器、恢复介质、目标主机 | 管理平台→目标 Agent 37000/TCP；恢复环境→备份系统 443/TCP、37000/TCP | 介质无法引导时更换引导方式或驱动；目标不可达时检查网络 |
| R3 元数据与校验 | 读取还原点元数据、校验完整性，按需解密，加载索引与链依赖 | Backup Server、元数据库、数据存储库 | 元数据库 3306/TCP；存储库 36000/TCP | 校验失败时更换更早的可用还原点；解密失败时核对密钥责任人与密码 |
| R4 数据读取与传输 | 存储库组织数据流，经数据获取器或直连发送到目标主机，可按限速策略控速 | 数据存储库、数据获取器、目标 Agent | 存储库 36001→数据获取器 35001→目标 37001 | 按重连次数与间隔自动重试；持续失败时检查带宽与存储读性能 |
| R5 写入目标 | 按文件写入目标路径，或按卷 / 磁盘写入；整机恢复可选择重建分区 | 目标主机 Agent、恢复介质 | 目标 37001 | 目标卷容量不足或锁定会失败；重建分区将清除目标磁盘数据 |
| R6 驱动与引导修复 | 整机恢复后加载存储 / 网络驱动、重建引导加载程序、修正 /etc/fstab 或系统卷标识 | 恢复介质、目标主机 | 按介质网络设置 | 引导失败时检查固件类型与引导分区；磁盘不可见时补充控制器驱动 |
| R7 业务启动 | 重启目标主机，确认服务自启、端口监听、网络与应用连通 | 目标主机、业务系统 | 按业务端口 | IP 冲突时调整网络；服务未自启时人工拉起并记录 |
| R8 验收与归档 | 按本章的验收清单核对数量、容量、内容与属性，登记 RTO/RPO 与证据编号并归档 | 管理平台、业务方 | 443/TCP | 发现不一致项时记录差异范围并在整改后重新演练 |
上表端口是源文档「已观察到的监听值」与公开默认值，方向仍以产品技术确认为准。完整的端口与网络矩阵见附录 B。
按 R1–R2（决策与准备）、R3–R5（数据恢复）、R6（驱动与引导）、R7（业务启动）四段分别记录。合成一个总数就没法定位瓶颈。R2 与 R6 往往是整机恢复的主要变量，每次演练都要单独留痕。
耗时、RTO 与 RPO
RTO（Recovery Time Objective）指灾难发生后从业务停顿到系统恢复到可支持业务运营所需的时间。 RPO（Recovery Point Objective）指发生意外灾难时可能丢失的数据量，即系统与数据能恢复到怎样的更新程度。
唯一一条可追溯的实测记录
本套资料里唯一一条可追溯的整机恢复实测记录来自同行业备份产品的运行日志。它只能当作演练窗口预估与验收标准的对标基线，不能写成 SupDRC 的性能承诺。
| 项目 | 实测数据 | 说明 |
|---|---|---|
| 恢复类型 | 异机跨平台整机恢复 | 源为超融合平台虚拟机（系统盘 300 GiB），目标为另一虚拟化平台新建虚拟机，采用 NBD 传输模式 |
| 恢复数据量 | 约 118.7 GB（有效数据约 118.93 GB） | 与同虚拟机全量备份的有效数据量吻合 |
| 起止时间 | 09:40:16 → 10:17:51 | 单次连续执行，无中断 |
| RTO（恢复耗时） | 37 分 35 秒（2255 秒） | 含传输与落盘，不含介质启动（该场景为在线异机恢复） |
| 有效吞吐 | 约 54 MB/s | 118.7 GB ÷ 2255 s ≈ 54 MB/s，对应约 430 Mbps，接近千兆链路可用带宽的 45% |
| 结果 | 成功（result=0） | 日志中未见独立的内容校验步骤——这正是本项目要求补充「校验方式与结果」字段的原因 |
由此推导的规划口径
| 恢复场景 | 目标吞吐 | 100 GB 耗时 | 500 GB 耗时 | 设定依据 |
|---|---|---|---|---|
| 文件级恢复（大文件为主） | 60–120 MB/s | 15–30 分钟 | 70–140 分钟 | 按同类实测吞吐 54 MB/s 上浮，大文件顺序读写效率更高 |
| 文件级恢复（海量小文件） | 5–20 MB/s | 1.5–5 小时 | 7–28 小时 | 小文件受元数据操作限制，应按文件数而非容量估算 |
| 整机恢复（在线异机） | 50 MB/s 量级 | 约 35 分钟 | 约 3 小时 | 直接采用同类实测数据（118.7 GB / 2255 s） |
| 整机恢复（含介质启动） | 50 MB/s 量级 + 启动与修复开销 | 约 1 小时 | 约 4 小时 | 在在线异机基础上叠加介质引导、驱动加载与引导修复 15–30 分钟 |
源文档另给出两条更粗的量级：文件级恢复 100 GB 数据约 20–60 分钟；整机恢复按数小时量级规划窗口。Linux 整机恢复可按「文件级恢复耗时 × 1.5–3 倍」作窗口预估，额外开销主要来自介质启动、引导修复与卷组处理。异机恢复通常在恢复耗时之外额外增加 0.5–2 小时的适配时间（驱动收集、引导修复、网络调整与许可处理）。
RTO / RPO 目标值建议
| 业务等级 | 建议 RTO 目标 | 建议 RPO 目标 | 达成条件 |
|---|---|---|---|
| 核心（数据量 ≤ 200 GB） | 文件级 ≤ 1 小时；整机 ≤ 2 小时 | ≤ 1 小时（日备 + 每 2 小时日志/增量） | 千兆及以上链路；驱动器与介质已预验证；恢复演练每半年一次 |
| 重要（数据量 200 GB–1 TB） | 文件级 ≤ 3 小时；整机 ≤ 6 小时 | ≤ 4 小时（每日增量） | 千兆链路且恢复流量与备份窗口错峰；预留临时恢复用存储 |
| 一般（数据量 > 1 TB） | 文件级按需；整机 ≤ 24 小时 | ≤ 24 小时（每日一次） | 优先按业务模块拆分恢复；必要时提高链路或采用瞬时恢复 |
上表按千兆链路 45% 利用率保守推算。若本项目链路为万兆或数据量远小于 200 GB，目标值可以收紧；若为跨广域网恢复，应按实际可用带宽重新推导。
上面的数字全部由同类产品的一条实测数据推导而来。把它们写成合同或验收标准里的承诺值，等于用别人的数据给自己背书。
测量口径
- RTO 从业务停顿时刻起算，到业务恢复可用为止，包含发现、决策、准备目标环境、恢复执行与业务验证。
- 如果只统计恢复任务本身的耗时，必须明确标注为「恢复任务耗时」而不是 RTO。这两个数经常差好几倍。
- RPO 取故障时刻与最近可用还原点时间之差，并注明该还原点是否通过了可恢复性验证。没验证过的还原点不能算进 RPO。
异机与裸机恢复结论
通用结论口径：异机恢复要求目标主机配置不低于原机（CPU、内存、磁盘容量），源与目标的硬件差异越大，驱动与引导修复的工作量越大；裸机恢复依赖可引导介质与独立的驱动来源，无法从被恢复系统自身获取驱动。
| 结论项 | 判定口径 |
|---|---|
| 异机整机恢复可行性 | 目标主机配置不低于原机；引导成功；驱动识别完整；业务可启动 |
| 裸机恢复可行性 | 无操作系统环境下由介质引导；目标磁盘可被恢复环境识别；驱动可加载 |
| 硬件差异容忍度 | 同厂同代硬件通常可直接恢复；跨厂或跨存储控制器需准备驱动 |
| 网络配置处理 | 异机恢复后需按新环境调整 IP、网关与 DNS，避免与原机冲突 |
| 授权与许可影响 | 操作系统与应用许可可能绑定硬件，异机恢复后需重新激活或申请授权 |
| 回退方式 | 保留原机与旧介质，验证通过前不释放原有环境 |
源文档在「本核查环境结论」一列对异机与裸机恢复标注了「已确认 + 已实测」，但这与本章开头交代的实测状态、以及产品简介文档的记载互相冲突。本手册按未实测处理，判定口径可以直接用，结论不要引用。
演练制度与记录模板
演练频率与覆盖范围
演练按业务等级制定频率和覆盖计划，至少区分四类：文件恢复、Windows 整机、Linux 整机、平台自身恢复。核心业务的建议频率是每半年一次。
演练前必须明确五件事：
- 隔离范围——演练环境与生产的边界在哪里。
- 审批记录——工单号、执行人、复核人。
- 目标资源——目标主机、临时存储、网段。
- 停止条件——出现什么情况立即中止。
- 回退方案——中止后怎么回到演练前的状态。
演练记录模板
演练过程与结论按下面 14 个字段逐项记录，记录人与复核人分别签认。
| 序号 | 填写字段 | 序号 | 填写字段 |
|---|---|---|---|
| 1 | 编号 | 8 | 预期结果 |
| 2 | 业务 | 9 | 实际结果 |
| 3 | 版本环境 | 10 | RPO/RTO |
| 4 | 源数据与还原点 | 11 | 证据附件 |
| 5 | 目标 | 12 | 问题 |
| 6 | 开始/结束时间 | 13 | 责任人 |
| 7 | 恢复步骤 | 14 | 整改日期 |
实测记录模板
每类恢复还要单独留一份实测记录。共用字段：
记录编号 · 环境与版本 · 还原点时间与类型 · 恢复对象与目标 · 数据量 · 变化量 · 开始时间 · 结束时间 · RTO · 校验方式 · 校验结果 · 业务可用性 · 证据编号 · 执行人 / 复核人 · 异常与处置。
不同恢复类型另加的字段：
| 恢复类型 | 额外字段 |
|---|---|
| 文件级 | 源数量与容量、目标主机与路径；校验方式写明平台校验 / 哈希抽检 / 文件数与容量比对 / 业务读取验证 |
| Windows 整机 | 固件类型 BIOS/UEFI、Windows 版本与位数；介质信息（ISO 文件名、大小、校验值、是否含驱动与解密密钥）；目标主机配置（CPU、内存、磁盘容量、存储控制器型号、网卡型号）；RTO 拆分为介质启动 / 数据恢复 / 驱动与引导修复 / 业务启动四段 |
| Linux 整机 | 发行版与内核版本、文件系统、是否使用 LVM / 软 RAID；介质信息；磁盘与分区布局；RTO 拆分为介质启动 / 数据恢复 / 引导与 fstab 修复 / 业务启动四段 |
记录编号建议用「恢复类型-年份-序号」格式，例如 RST-FL-2026-001。常见异常也要写进「异常与处置」：文件占用冲突、卷组未激活、引导缺失、网卡命名变化、SELinux 上下文异常、磁盘未识别、IP 冲突。
RTO / RPO 实测汇总表按场景各留一行：同机文件级恢复、Windows 整机恢复、Linux 整机恢复、异机整机恢复、平台自身恢复。
对照验收测试用例集
恢复相关的验收用例共 5 条，出自验收测试用例集（DRC-020 §3）。每条用例都要记录前置条件、步骤、预期结果、实际结果、执行人、审核人、时间和证据编号。
| 用例 | 场景 | 前置条件 | 操作 | 预期结果 |
|---|---|---|---|---|
| AC-3-1 | 首次备份 | 代理、存储、挂载服务器及测试数据可用 | 建立策略并核对汇总；按批准方式启动，查看总任务 / 明细及还原点 | 任务结束且成功，生成对应还原点；记录数据量与耗时 |
| AC-3-2 | 文件级恢复 | 隔离目标和可用还原点；事先计算样本校验值 | 选择文件与目标，核对同名处理，恢复后比对内容、属性及权限 | 样本内容与批准还原点一致，无非授权覆盖 |
| AC-3-3 | Windows 整机恢复 | Windows 目标、介质、驱动和业务验收计划齐备 | 先测试介质启动和磁盘 / 网络识别，再按正式恢复步骤恢复并启动业务 | 系统启动、驱动和业务数据检查通过；记录 RPO/RTO |
| AC-3-4 | Linux 整机恢复 | Linux 目标、介质、驱动和业务验收计划齐备 | 验证启动与硬件识别，按正式步骤恢复，检查引导、挂载与业务 | 系统与业务正常，数据一致；记录 RPO/RTO |
| AC-3-5 | 异机恢复 | 正式支持范围已确认，隔离异机目标已批准 | 记录源 / 目标硬件、启动方式、磁盘与驱动差异，再执行专项恢复 | 批准范围内硬件识别、系统启动及业务验收通过 |
用例集把可执行性分三态：可执行（现有能力即可立即执行）、依赖已明确文档（步骤明确，按已定稿文档执行）、能力已确认（能力结论已明确，按产品技术说明执行）。恢复相关用例的归属是：
- AC-3-1、AC-3-2 属于「可执行」，与安装接入四条用例同属第一批执行，是验收核心。
- AC-3-3、AC-3-4、AC-3-5 属于「依赖已明确文档」（依赖恢复介质与异机恢复结论章节），排在第三批。
用例集第 1 节写「已执行的用例不填写通过结论」，而每条用例的状态栏又都写着「已执行」，同时所有执行记录字段（版本/环境、执行人、日期、起止时间、证据编号、复验与签认）全为空。这与 DRC-014 §4.2 是同一类前后不成立的表述。按未执行排期，不要把这些用例当作已完成的验收证据。
常见问题
备份每天都成功，还要演练吗？ 要。备份成功只证明数据写进去了。恢复正确性、引导可用性、业务一致性都不在备份任务的判定范围内。核心业务的建议演练频率是每半年一次。
演练和验收是一回事吗？ 不是。演练是把恢复真做一遍；验收是按判定口径核对演练结果并签认。一次演练如果没有留下审批、证据编号和复核签字，它就不构成验收。
「恢复任务耗时」和 RTO 差在哪里？ RTO 从业务停顿起算，包含发现故障、走审批、准备目标环境、执行恢复、验证业务这一整串；恢复任务耗时只是其中的执行段。两个数经常差好几倍，写报告时必须标清楚是哪一个。
验收时发现文件数差了 0.3%，算不算通过？ 清单第 4 项的判定标准是差异 ≤ 0.1%。超出就不通过，需要把差异项逐条说明、登记问题编号，整改后重新演练。
恢复完成但业务起不来，责任怎么划？ 按四层验收分开判：任务层和数据层通过、业务层不通过，说明数据恢复正确而应用侧另有问题。这也是为什么验收要分层——不分层就只能得出「恢复失败」一个结论，定位不到原因。
能不能用一次异机恢复演练覆盖所有场景？ 不能。演练计划至少要区分文件恢复、Windows 整机、Linux 整机、平台自身恢复四类。它们的失败模式不一样，互相不能替代。