云备份能建不代表能恢复：一次恢复演练前先核对的 7 项

一、问题：备份任务成功，为什么恢复还是会翻车？

很多团队都有过这样的经历：备份策略配好了，每天都能看到备份成功的记录，心里很踏实。等到真正需要恢复的那一天，才发现事情没有那么简单——备份副本找不到了，恢复出来的实例起不来，数据库能打开却缺了最近一天的数据，或者恢复操作直接把正在跑的生产实例覆盖了。

问题的根源不在备份本身，而在“没有验证过恢复”。备份成功只证明“数据被抄了一份”，恢复成功才证明“这份数据在需要的时候真的能用”。两者之间隔着不少环节：备份副本是否还在保留期内、目标资源规格够不够、跨区域复制有没有完成、恢复后业务能不能正常启动。任何一环断掉，恢复都会失败。

所以，正确的做法不是等故障来了再恢复，而是平时就做恢复演练：用备份创建一个新资源，验证数据和业务，再把演练资源清理掉。演练的成本是一次性的，故障时恢复失败的成本却是业务中断。

二、前提：先把这几件事定下来再动手

动手演练之前，先确认四件事，避免演练本身变成新的风险。

第一，确认演练对象。不要一上来就拿核心生产系统做演练，先从一台非核心云服务器、一块非核心云硬盘或一个测试数据库开始。等流程跑顺了，再逐步覆盖核心系统。

第二，确认演练方式。恢复演练必须用备份创建新资源实例，禁止直接恢复源实例。这是最重要的一条红线：直接恢复源实例会覆盖现有数据，一旦恢复结果不对，连回退的余地都没有。

第三，确认目标资源。演练用的新实例配置要与原资源相当，存储空间不能小于原资源。云服务器演练要准备与待演练服务器配置相同的实例，数据库演练要保证新实例的引擎、版本与原实例一致，存储空间大于或等于原实例。

第四，确认时间和人员。演练要安排在业务低峰期，指定一名操作员全程跟进并记录。恢复任务耗时与数据量有关，不要在演练中途无人值守，也不要把演练和生产变更安排在同一窗口。

三、分步操作：一次可复用的恢复演练流程

下面以云服务器备份演练为例，给出一套可以直接套用的流程。云硬盘、文件系统和数据库的演练思路相同，只是恢复入口和目标资源不同。

第一步，选备份副本。登录云备份管理控制台，选择区域，进入云服务器备份的备份副本列表，按服务器 ID 找到需要验证的服务器，选一个有代表性的备份副本。不必每个备份都演练，但要保证在一定期限内，每种资源的每类备份至少有一次被恢复验证过，抽样要随机，不要每次都只挑最新的一份。

第二步，用备份创建新资源。不要点“恢复到原实例”。云服务器演练的常见做法是：用选中的备份副本创建镜像，再用该镜像申请一台新的云服务器；数据库演练则是选择备份后恢复到新实例。关键点只有一个：新资源与原资源隔离，演练结果再差也不会影响线上。

第三步，等新资源就绪。创建镜像、申请新实例、恢复数据库都需要时间，等实例状态变为正常、数据库状态变为正常后再进入下一步。不要在状态还在“创建中”时就急着登录验证，那样看到的往往是半成品。

第四步，对比数据。把新资源与原资源逐项对比：关键目录和文件是否都在，文件大小和修改时间是否符合预期，数据库的库表数量、关键业务表的行数是否对得上。只看“恢复任务成功”四个字是不够的，任务成功不等于数据正确。

第五步，验证业务。数据对得上，还要看业务能不能跑起来。启动应用服务，检查服务端口是否监听，登录业务页面走一遍核心流程，例如下单、查询、报表导出中的一到两条主流程。只读验证优先，不要在演练实例上直接写生产数据。

第六步，记录结果。操作员要详细记录演练周期、演练对象、备份副本、恢复耗时、验证结果和发现的问题。记录不是为了应付检查，而是为了下一次演练和真实故障时有据可查：上次恢复花了多久，这次有没有变慢，哪个环节反复出问题。

第七步，清理演练资源。验证完成后，及时释放演练用的新实例、镜像和临时磁盘。演练资源如果长期不清理，不仅产生费用，还可能被误当成生产资源，后续排查时会多出很多干扰项。

四、验证：怎样才算恢复成功？

给恢复成功定一个可执行的标准，不要凭感觉。

第一，恢复任务本身成功，任务没有报错中断。

第二，恢复出来的资源能够正常启动和使用，服务可以正常访问。

第三，恢复的数据与原来一致，正确性与预期匹配，关键文件能打开、关键数据能读出来、业务主流程能走通。

只要有一条不满足，就要按恢复失败处理：先保留演练现场和任务记录，排查是备份副本问题、目标规格问题还是操作步骤问题，不要反复重试同一个失败操作，更不要把有问题的备份当成“下次再说”。

五、常见坑：这 6 个错误最容易把演练变成事故

第一，直接恢复源实例。这是最危险的操作，覆盖后原数据可能无法找回。演练永远用备份创建新资源。

第二，只验证最新备份。最新备份往往是最干净的一份，老备份、跨区域复制的备份、保留期快到期的备份反而更容易出问题，抽样时要覆盖不同类型和不同时间点。

第三，目标规格缩水。为了省钱把演练实例配得很小，结果业务起不来，就误以为是备份有问题。演练实例配置要与原资源相当，否则验证结论本身就不可信。

第四，跨区域恢复不等复制完成。跨 Region 复制的备份要在目标区域完成复制后才能在异地恢复，复制还没完成就动手，恢复入口可能根本找不到这份备份。

第五，恢复后不改连接信息。演练实例如果沿用了生产数据库的连接串、域名或密钥，验证时可能误连生产库，或者生产流量误打到演练实例。演练环境要单独隔离，连接信息要单独配置。

第六，演练完不清理。演练实例、临时镜像、测试数据库长期挂着，既花钱又容易在后续排查中被误认。验证完成就清理，并把清理结果也写进演练记录。

六、小结清单

• 备份成功不等于恢复成功，恢复能力要靠演练验证。
• 演练用备份创建新资源，禁止直接恢复源实例。
• 先从非核心资源开始，逐步覆盖核心系统。
• 目标实例配置与原资源相当，存储空间不小于原资源。
• 抽样要随机、要覆盖不同类型和时间点，每种资源每类备份在一定期限内至少验证一次。
• 验证三件事：任务成功、资源可用、数据与业务与预期一致。
• 记录演练周期、过程、结果和问题，验证完成后及时清理演练资源。

出处：华为云云备份 CBR 最佳实践《通过数据备份开展定期恢复演练》（https://support.huaweicloud.com/bestpractice-cbr/cbr_07_0021.html），其中明确了“恢复演练以使用备份创建新资源实例进行，禁止直接恢复源实例”、抽样验证原则和恢复成功判定标准；产品能力可参考云备份 CBR 产品页（https://www.huaweicloud.com/product/cbr.html），其中说明 CBR 针对病毒入侵、人为误删除、软硬件故障等场景，为服务器、云硬盘、云桌面、SFS Turbo 提供统一备份服务，并支持跨 Region 复制实现异地灾备。