灾难恢复技术
灾难恢复技术
你的公司可能已经制定灾难恢复计划，同时投资各项技术支持计划，但是仅仅这么做可能
还不足以保证数据能够得到恢复。过去几年，自然因素和人为因素引起的灾难越来越多，
存储管理员都在仔细审查灾难恢复（DR）计划，精心测试 DR 计划。
本手册讲解灾难恢复策略，在如何有效的进行制定灾难恢复策略时 TechTarget 中国特约专
家给出技巧性的建议。
灾难恢复技术简介
随着电子商务的发展，当今企业运营在一个极其复杂和高度联网的全球化经济环境
中，比以往更容易受中断的影响。 这种中断或停机时间的代价在各个行业中是不同的，而
对于大量使用 web 的公司而言，这种代价可能是每小时数百万美元之多。尽管这些数值大
得惊人，其原因却很明显。互联网将数百万客户径直带到了电子商店中。由于至关重要且
相互依存的业务事务越来越容易受到业务中断和停机时间的损害，因此它们现在变得更为
紧要。
z 灾难恢复方案的基本要素
灾难恢复策略
在当今商业环境下，网络宕机就意味着公司将遭受巨大经济损失，而客户也会难以接
受。做好灾难恢复准备的公司能够更好地维持运营、保住客户并避免长期损害。要在紧要
关头进行灾难恢复，通过这一系列文章学习制定灾难恢复的策略，计划。以及面对灾难时
我们应如何应对。
z 如何规划灾难恢复策略
z 管理灾难恢复
z 服务器虚拟化让灾难恢复受益
TT 存储技术专题之灾难恢复技术 第 2 页 共 32 页
z 忽视变更控制会毁掉你的灾难恢复计划
z 利用重复数据删除技术进行灾难恢复时需要考虑的四大策略
灾难恢复实例
了解了灾难恢复的重要性，及其策略后，我们来了解一些在灾难恢复过程中遇到的问
题。
z 灾难恢复清单：网络部分
z 灾难恢复计划的十大潜在问题
z Windows 管理之灾难恢复计划
z 光盘可否作为灾难恢复数据存储介质的备选方案之一？
TT 存储技术专题之灾难恢复技术 第 3 页 共 32 页
灾难恢复方案的基本要素
W. Curtis Preston 在设计备份和恢复有８年多的经验，给许多环境设计类
似的系统.给读者提供了很多有价值的建议。
问：请问在制定灾难恢复方案时要考虑哪些基本因素？
答：下文是我的书“Unix 系统备份与恢复”第一章的概括，我希望对你能有所帮助。
设计一个好的灾难恢复方案有六个主要步骤。问题的重点在于公司的首席信息官
（CIO）和首席技术官（CTO）如何有效的指挥 IT 部门正确执行以下步骤：
１.定义可以接受（不可接受）的损失程度。首席信息官（CIO）/首席技术官（CTO）
如何确定灾难恢复方案的预算？通过预先判断如果没有灾难恢复方案有可能造成多大的损
失。
２.备份所有数据。你知道你有多少数据没有备份及其原因吗？
３.把所有数据组织起来。就算你的公司把所有数据都备份到磁带上了，当灾难发生
时你能找到正好需要的磁带吗。
４.尽量避免灾难的发生。在设计灾难恢复方案的时候，大多数人仅仅考虑到自然灾
害。实际上有九种其它的灾难，你必须尽量避免它们发生。研究哪些灾难可能发生在你身
上，你的公司应该如何应对它们。
TT 存储技术专题之灾难恢复技术 第 4 页 共 32 页
５.把你做的每件事情记录下来。研究新颖的方式来帮助你的公司记录它的灾难恢复
方案，以保证这个记录在灾难后仍然可以找到。
６.测试、测试、再测试。很多灾难恢复方案之所以失败，是因为它们没有经过很好
的测试。研究其它公司如何测试它们的灾难恢复方案。有很多方法可以做到这一点，并不
会耗费掉太多的预算！
（作者W. Curtis Preston 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 5 页 共 32 页
如何规划灾难恢复策略
每家公司都会遭受各种各样的灾难，这些灾难可能源于自然灾害、恐怖袭击、员工的错误
（或恶意）行为或硬件故障。各种规模的公司都在重新审查他们的容灾计划能否应对灾
难。
丢失数据的后果相当严重。目前，越来越多的公司以电子的形式记录信息。公司越来
越依赖这些记录，越来越依赖用于处理和存储数据的工具。人们从来不会打印电子邮件、
事务处理等大多数电子记录。电子记录一旦丢失，就不可能重新创建。而大部分公司都不
允许丢失数据。
目前，公司应该遵从法规需求，即使在面临灾难时也要保留和查询电子信息。因此，
公司必须采用一定的技术和政策，保证数据安全存储、随时可用；同时也要保证灾难发生
后能及时恢复数据。要实施灾难恢复战略，首先应进行合理的规划和设计。
提高灾难恢复能力
灾难恢复计划必须包括如下三点：
必须保护备份数据。例如，在当地磁带驱动器中设置一个备份磁带，用以存储数据，
这种方法在整个数据中心着火的时候就不实用了。你需要在其它地点另外设置备份复本。
必须能通过备份使公司恢复运作。如果某个站点被洪水冲走，就必须保证某个受保护
的站点拥有足够的数据，使公司能继续正常运作。对大多数公司而言，数据虽然不代表整
个公司，但是却支撑着整个公司的运转。
恢复进程必须在公司需求描述的时间框架内正确地运行。如果你不能使公司再次运
作——或者需要花费几周时间才能修复磁带数据，那么只是简单地实行远程备份毫无意
义。
TT 存储技术专题之灾难恢复技术 第 6 页 共 32 页
明白了这几点对公司恢复需求的重要性后，你就可以开始制定灾难恢复战略了。
战略和公司需求
制定灾难恢复战略（有时也称业务连续性计划或 BCP）有许多种方法，保护公司运作
也不止一种正确的方法。一家公司制定的战略和程序可能对另一家公司就不适用。但是，
实现灾难恢复计划有一些常见的方法。
异地磁带备份是最传统的方法，即数据中心或远程办公室中会定期备份数据。然后，
复制备份磁带，将其转移到一个安全的站点，其中 Iron Mountain 公司的网络管理产品就
是这么工作的。可以根据循环周期定期召回磁带，或者需要恢复时也可以召回磁带。近些
年，备份过程开始使用 DVD 等光学介质。光学介质的价格通常高于磁带，但是其性能更
佳、可靠度更高。不过，由于容量有限，人们慢慢地不再倾心于光学介质。
远程磁盘复制越来越流行，数据中心的资源定期复制到远程站点相同的存储资源中。
银行可能会通过 WAN 链接将 EMC Centera 的内容复制到远程站点的 Centera 中。这样，就
具有双倍的资源，恢复速度也大于磁带；如果实施得当，还能在主站点失效时，接管主存
储站点。
制定灾难计划/战略时，通常要考虑成本因素。这种形式与保险相似：你在花钱避免
更大的经济损失。数据保护模式非常复杂，具有一定的成本，而你在努力降低潜在损失，
最终目标是要将两者协调。所以，一家小型医疗公司也需要每周进行异地磁带备份，因为
可能无力支付更贵的恢复需求；一家全天候工作的全球互联网供应商需要复制一个数据中
心，因为宕机时期的损失远高于灾难恢复战略的成本。请牢记上文所提必需条件的第三
条：恢复必须在时间框架内完成，与公司的恢复需求或 ROI 保持一致。要想在紧张的恢复
时间目标（RTO）内获取大量数据，必须精心制定恢复战略。
工具和产品
TT 存储技术专题之灾难恢复技术 第 7 页 共 32 页
你选择的数据保护解决方案应该体现你的恢复战略，应根据公司的恢复需求而定。如
果选用磁带作为备份和恢复介质，你可以选择与磁带驱动器平台兼容的备份/恢复软件。
通常可以在 Symantec (Veritas) NetBackup、EMC NetWorker 和 IBM Tivoli Storage
Manager 等大型数据中心找到这些产品，。
许多灾难恢复战略要求在存储阵列之间进行复制，可以由阵列生产商提供的软件来完
成这项工作。EMC 公司的 Symmetrix 远程数据设备可以在 Symmetrix 系统之间复制数据。
IBM 公司采用点对点远程复本在 IBM 阵列之间实现复制。Hitachi 数据系统公司采用
TrueCopy 在 HDS 阵列之间实现复制。但是，你也不是非得采用硬件式复制软件，
FalconStor Software、 NSI Software 和 Kashya (现属于 EMC)等公司提供的工具可以在
不同的存储阵列之间实现复制。
公司如果缺少资源管理灾难恢复站点，可以将灾难恢复任务外包给第三方服务供应
商，按月支付费用即可。此类灾难恢复供应商有 E-Vault、IBM 全球服务事业部和 EMC 公
司，EMC 最近收购了 Mozy (Berkeley 数据系统公司)。
灾难恢复战略并不能“以一应十”。实施分层灾难恢复战略意义重大，这样就可以联
合使用磁带备份、磁盘备份和数据复制。并非所有的商业流程对公司的生存都具有同等重
要的作用，因此，不同流程支持的系统和数据具有不同的恢复优先权。
文档
灾难就意味着危机，在这场危机中，你没有时间查找各种磁带，没有时间规划如何重
建备份环境。灾难恢复专家都强调，必须具有全面、及时更新的文档。这些文档应该包
括：系统准备工作的说明书、恢复步骤、正常运作恢复之前对数据中心进行后期恢复测试
/确认。文档还应该包括联系信息（如管理员电话、服务部门联系方式等）或访问密码。
文档应属于灾难恢复计划的一部分。恢复计划应有多份复本，每分复本由专职 IT 人员或
管理人员保管。请注意：严格控制恢复计划的版本，保证人员只能获得最新版本。
（作者Stephen J. Bigelow 翻译：周姝嫣 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 8 页 共 32 页
管理灾难恢复
制定灾难恢复计划的方法多种多样。每个公司都必须利用各种工具和技术制定恢复计划，
实施恢复战略，制定方法应该适应自身的商业模式、恢复需求和法规遵从。尽管方法各
异，但灾难恢复计划绝非一日就能完成。在实际应用中，实施灾难恢复计划通常要改变存
储设备，带来其它开销——开销问题必须加以解决。
恢复计划必须定期测试和更新，保证计划与公司同步发展，与 IT 基础设施同步增
长。本质上说，灾难恢复管理必须同变化管理类似——必须成为公司日常管理的一部分，
公司必须随时做好避免灾难的准备。
以下四点对于灾难恢复管理问题至关重要。
实施事宜
通常，灾难恢复战略包括现有存储和网络设施发生的变化。最终，存储管理员必须对
硬件、软件、实施、培训、设备成本等因素做出预算和安排，适应灾难恢复战略的要求。
添加硬件设备十分简单，就跟几年之前向磁带库添加磁带驱动器类似；但是现在还需要添
加更多设施，如存储系统。举个例子，从 NetApp 公司购买 NearStor 虚拟磁带库
（VTL），或从 Data Domain 公司购买重复删除存储阵列。
大多数情况下，根据最佳方案，为了恢复灾难而进行的备份应该发送到远程站点。
Iron Mountain 等公司提供的服务可以将物理磁带传送到安全的异地站点中，但是越来越
多的公司开始采用磁盘备份，在两个或多个站点之间的存储系统中实施远程复制。例如，
银行可能使用 WAN 链接从主数据中心的 EMC Centera 复制数据，也可能从备份数据中心的
二级 Centera 复制数据。
TT 存储技术专题之灾难恢复技术 第 9 页 共 32 页
灾难恢复策略需要依据软件而制定，通常包括一套或者更多的软件应用程序，如备
份、快照、镜像和复制工具。EMC 公司的 TimeFinder 等工具常用于创建数据卷的当地副
本，称为业务连续卷(BCV)。这种存储阵列技术通常用于连接 SRDF 软件，意在复制
Symmetrix DMX 卷到远程站点中。NetApp 公司的 SnapShot、SnapMirror 和 SnapVault 都
是很好的软件产品，可以联合使用，成为灾难恢复战略的一部分。另外，还有独立的硬件
复制解决方案，允许终端用户在不同的存储阵列之间复制，如 Symantec 公司的
Replication Exec 就属于此类产品。
无论软件是与存储系统绑定的，还是需要单独购买，IT 人员必须花时间才能熟悉每项
工具。精明的管理员应该能够保证关键的 IT 人员有时间学习每项工具。
部署了合适的灾难恢复设施后，还需要花很长的时间才能建立和维护最初的备份和复
本。可能需要一个晚上或一个周末的时间，才能实现完全磁带备份，才能在 WAN 的站点中
同步备份数据。最初的复制完成后，IT 部门必须分配时间，实现增量磁带备份或隔夜复
制。
安全事宜
公司依靠备份免受灾难影响，但是备份本身是否容易受到灾难影响？如果公司数据不
受 IT 部门的直接控制，那么数据安全就显得非常重要。选择远程站点应该首先其评价物
理安全。
磁带存储或远程数据中心设备都应该上锁，只有少数的授权人员才能接近。消防人员
和灭火系统须采用气体灭火，才能保护电子设备和数字媒介（避免用水灭火）。存放地点
应该保证不会受到水灾、地震或其它自然灾害的影响。根据公司特点，还应该考虑恐怖袭
击等人为灾害。应事先检查远程设备。如果设备由 Iron Mountain 等公司管理，还应该用
点时间讨论公司的安全和灾难计划，明确 Iron Mountain 等公司对你的数据应该承担什么
责任。
TT 存储技术专题之灾难恢复技术 第 10 页 共 32 页
数据本身需要通过加密技术保证安全。一般说来，只有私人信息必须保证安全，如社
会保险和信用卡卡号等客户记录，不过公司复制数据时通常会选择加密所有的数据，以维
护开放 WAN 的安全。通过备份软件可以实现加密功能，通过将加密产品集成到网络中也可
以实现加密功能，如 Decru 公司的 DataFort。
然而，在选择数据加密之前，应该首先评价其影响；你可能会选择其它技术来实施灾
难恢复战略，需要评价加密措施对这些技术会产生什么影响。例如，如果对数据加密，数
据重复删除技术就会丧失大部分（如果不是全部）精简数据的能力。
测试和培训
如果不能付诸实施，即使最先进的灾难恢复计划也无济于事。灾难恢复管理中一个重
要的部分就是定期测试和培训，培养新的 IT 人员，加速灾难恢复进程，在具体的恢复时
间目标（RTO）内实施恢复。
灾难恢复过程可能会干扰生产环境，因为需要将环境中一部分内容异地复制，才能真
正测试恢复程序和支持程序的技术。在测试 DR 计划的同时，还必须制定合理的计划、采
取适当的维护。
为了避免浪费生产时间、避免产生意外问题，一些公司往往会利用现有开发环境进行
测试。这就有机会与生产网络采用相同的恢复性测试。这种方法虽然不能真正测试生产设
备的可恢复性，却能为 IT 人员提供必需的参考价值。这种方法的实施步骤包括：IT 人员
讨论、评价 DR 计划，提出建议，改进灾难恢复进程。
没有指导手册指明灾难恢复计划应该多久测试一次，不过至少每年一次。除去常规测
试，还可以根据需要进行附加测试，如人事调动、IT 设备变动时，就需要对灾难恢复计划
进行测试。如果你的公司与灾难恢复供应商签署了协议，协议内容通常会包括测试时间。
这样，你就能远离生产环境，不加干扰地测试灾难恢复计划。不过，通常你需要提前安排
测试时间。公司应该考虑知道，将一部分 IT 资源分配给灾难恢复计划测试，可能与常规
责任不符。同理，要避免对生产环境造成不必要的干扰，需要制定合理的计划。
TT 存储技术专题之灾难恢复技术 第 11 页 共 32 页
更新计划
最后，灾难恢复计划并非一劳永逸。存储资源、应用程序、IT 人员、业务流程、公司
实体（合并和收购）等都难免发生变化。变化发生后，灾难恢复计划必须及时更新，体现
这些变化。例如，在系统中添加 2 TB 的存储容量、或者配置新的存储阵列后，灾难恢复
计划就必须反应这些变化。另外，过去文件无需加密，而新的法律可能会要求对文件加
密。
这些变化可能对灾难恢复战略产生负面影响。前面的例子中，添加了 2TB 同样的存储
容量。由于存储越多，意味着备份时间越长，因此我们有必要考虑采用别的备份技术，或
者增加 WAN 网络带宽，从而维持可以接受的 RTO 和 RPO，实现数据复制。无论是哪种情
况，公司的变化管理过程都必须包括灾难恢复计划。在实施灾难恢复之前，就确保 IT 人
员变化不会对恢复能力产生影响。变化管理应该保证，在应用程序和基础设施的早期开发
阶段，灾难恢复计划就已包括其中。
（作者Stephen J. Bigelow 翻译：周姝嫣 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 12 页 共 32 页
服务器虚拟化让灾难恢复受益
大到服务器虚拟化，小到 VMware 基础架构，这些讨论都是围绕服务器整合和绿色数据中
心的，不过，服务器虚拟化技术对于 IT 行业影响最大的却非灾难恢复莫属了。
长期以来，为任务关键型的应用制定的灾难恢复（DR）计划需要对这些应用进行复
制，并且在容灾点拥有备用的服务器，一旦通知，就可以立刻接手运行。
大多数企业可以通过对这些备用服务器进行虚拟化来节省资金。一个单独的异地服务
器可以当作备用域控制器、SQL 服务器、Exchange 服务器以及其它服务器来使用。你不但
可以节省所有这些物理服务器的费用，而且可以节省容灾点的空间和能源费用。
既可以节省费用，同时又可以继续提供与旧的昂贵物理服务器相同的保护水平，这无
疑是一件好事。但是真正的受益之处在于改善了应用的恢复时间，应用不需要专门的备用
服务器。多数企业很快就意识到他们可以将一些应用从第二级提升到具有备用服务器，因
为这些备用服务器从本质上来讲是免费的。
解决不同硬件的裸机恢复问题
在过去，第二级的应用仅限于从磁带中得以恢复，作为其保护模式，这种方法会导致
多天的恢复点和恢复时间。即使你已经复制了该应用的数据，通常也不太可能有一个完全
一样的服务器来恢复该应用备份。要么需要对不同的的硬件进行裸机恢复，要么就购买一
个新的操作系统和应用安装，在这个过程中还要有安装数据库所需的所有补丁备份。
这个“硬件不同”的问题已经得到了解决，因为虚拟机实际上是虚拟的机器——它们
都是运行同一套驱动程序，如果它们从一台主机转移到另一台主机，你区分不出来。此
外，VMware,或者甚至微软的 Virtual Server 或 Hyper-V 的虚拟机快照仅是文件而已，所
以恢复一台虚拟机就只是将文件安装到新的主机上。
TT 存储技术专题之灾难恢复技术 第 13 页 共 32 页
与以往的依赖磁带进行转移不同的是，现在你定期对你的虚拟机安排快照，然后通过
复制连接，将它们转移到容灾点。如果你的网管能够正确考虑通信的优先级，它就不会对
实时的复制造成干扰。
真正的乐趣在于一旦灾难宣布，你必须开始转换到备用服务器。因为在转换的那一
刻，人们揣着忐忑不安的心情启动灾难恢复的基础设施，全速进行接管，容灾点开启大量
的计算马力（当然，大量的计算马力也意味着大量的钱）。
趋向于更节俭的公司会充分利用专为企业设计的虚拟计算机管理软件（Vmotion），
因为这个软件可以在这些虚拟化服务器运行时，动态地从一台主机转移到另一台主机。此
外，灾难恢复提供商喜欢 SunGard（一家专业数据恢复公司）公司推出的“服务器共享”
服务。通过共享的服务器，你每个月只需要支付灾难恢复提供商一小笔钱，这样，在你宣
布紧急状态时，，就可以在容灾点获得服务器使用的权利。一旦你宣布进入紧急状态，你
就获得这些服务器的独家使用权，并且可以在服务器上安装 VMWare ESX。
然后，一旦新的主机开始投入使用，你便可以根据负荷量的不同，利用 VMotion（或
者更好的 VMware DRS）动态地将虚拟服务器分配并安装到新的主机。这样，将提高你的应
用性能……可能在你的用户进入新的工作区使用这些应用之前就完成了恢复。
注：还有一种办法虽然需要更长的恢复时间，但是可以使用厂商的服务器速递项目，
这样一旦灾难发生，就能立刻速递给你新的服务器。
（作者Howard Marks 翻译：史静 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 14 页 共 32 页
忽视变更控制会毁掉你的灾难恢复计划
你从这篇文章中可以学到这些：讨论了灾难恢复上的变更控制(或者缺乏变更控制-change
control)的影响，并且提出了一些很好的实践信息。
你的灾难恢复(DR)计划文档仍然涉及 9 磁道磁盘、或者仍然描述了从 Windows NT
服务器上的恢复过程?虽然大多数公司的计划中并没有我说的这样过时的技术，但是
大多数参与公司数据灾难恢复计划的信息技术从业者当被问及它们公司目前的灾难恢复计
划怎样时，他们都会无可奈何的以微笑回应。并且，他们中的很多也承认灾难恢复是需要
被注意的。有很多的原因可以解释为什么 DR 计划已经和公司的架构不再同步了;下面的一
些是常见的原因：
● 被开发的机会仅仅是用来满足审核的需求的，并且该计划已经过时
● 计划从根本上并没有得到测试以及维护
● 计划仅仅在固定的时间点上得到维护(例如：一年一次或者再一次测试后)
● 变更控制(或者变更管理)并没有将灾难恢复考虑在内
● 缺乏正规的变更控制流程
最近在《灾难恢复杂志》公布的 Gartner 公司的调查显示：大约 51%的回馈者对灾难
恢复环境作周期性的改变，而 35%的回馈者依赖于产品变更管理过程才做出改变。
到目前为止，忽视变更控制是灾难恢复计划或者灾难恢复环境最大的敌人。事实上，
不存在或者不充分的变更管理是灾难的起因。有很多的例子证实都是由非常差的灾难恢复
计划所导致的，当然也会由常规的软件升级所导致。一些小的以及中型企业(SMB)当遇到
TT 存储技术专题之灾难恢复技术 第 15 页 共 32 页
变更控制时都由于缺乏资源以及资金而面临挑战，而且解决问题比防止问题发生会花更多
的时间。
下面是变更控制相关条目的摘要列表，任何规模大小的需要信息技术部门的企业都需
要考虑以下几点涉及到灾难恢复的因素：
● 如果还没有变更控制过程的列表，那么请实现一个。该列表不必非常详细，但是
在复查前不应该允许做任何信息技术方面的变动
● 在评估变更影响前，确保变更控制将灾难恢复环境以及计划文档考虑进去。要包
含一些简单问题以及一些验证形式
● 灾难恢复必须是系统开发周期的一部分并且不要成为事后想法
● 灾难恢复计划必须成为计划中的一部分，而不应该在项目结束时才被考虑
● 灾难恢复协调员(或者负责灾难恢复的人员)需要参与到变更复查过程
● 不要等到下次灾难恢复测试才更新你的灾难恢复环境，以反映你对环境的变化过
程
● 灾难恢复计划以及灾难恢复环境应该在产品系统阶段就被重点考虑，并且应该据
此进行设计和维护
那些使用厂商提供热点(hot-site)的企业应该得到提醒：虽然一个灾难恢复环境物理
上不一定存在直到真正有需求时，但是这些企业需要让厂商知道产品环境中的每一个配置
上的变化，而这些变化则会影响到灾难恢复环境。这一工作不应该在续约的时候才去做，
而应当在变更前就做，这样就可以确保任何引起的技术以及契约问题在计划阶段就已经确
定了。
TT 存储技术专题之灾难恢复技术 第 16 页 共 32 页
就像我们测试我们的灾难恢复计划和过程(基本的)，同样建议去测试你的变更管理过
程。变更控制的少量存在不会自动确保该过程的效率。测试变更管理过程和进行变更后复
查一样简单，并且它能够确保变更的每一个方面及其可能的影响都在实现前就作了考虑。
需要让变更管理过程实现成熟化的信息技术公司也许会遵从信息技术业内最好的建议
或者指导，比如在信息技术基础架构库(ITIL)框架中提到的一些建议。
无论是世界级还是入门级的变更控制，它不仅仅保护你的公司免遭非常差的 IT 变更
计划影响，并且它也可以帮助产品和灾难恢复 IT 环境完全同步，同时确保所有的相关文
档以及过程得到很好地维护。
（作者Pierre Dorion 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 17 页 共 32 页
利用重复数据删除技术进行灾难恢复时需要考虑的四大策略
你会学到以下知识：采用重复数据删除技术部署灾难恢复时，需要考虑四大策略，本文对
此做了简要概述。
数据重复删除已经成为数据中心的一项重要技术，正在逐步替代磁带，成为数据备份
存储的介质。在制定 IT 灾难恢复战略时，必须考虑这一点。以下是需要考虑的一些措
施：
1 磁盘备份
数据重复删除技术通常利用磁盘作为存储介质，也就会涉及数据镜像和快照技术等功
能，大多数情况下，数据通过备份软件写到磁盘上后，必须以同样的格式写回（恢复）到
主机中，才能实现再次访问。尽管数据重复删除技术的供应商会提醒我们，磁盘速度大于
磁带速度，但将数据备份到磁盘中不属于数据镜像功能。换句话说，如果应用程序的宕机
时间很短，数据重复删除技术就不是保护数据的最佳选择。
2 数据复制是必须的
除非重复删除的数据已经进行异地复制，否则其灾难恢复的能力就很差。一些公司会
选择采用即时重复删除技术备份数据，但是依然会使用磁带进行异地存储和灾难恢复。很
多情况下，一旦复制到磁带中，数据就不能再重复删除。所有备份应用程序都能实现重复
删除技术时，这个问题终将得到解决。同时，利用磁带进行异地存储，会抵消数据精简和
磁盘备份带来的好处，数据恢复能力回落到传统的磁带备份水平。
3 网络带宽
TT 存储技术专题之灾难恢复技术 第 18 页 共 32 页
数据重复删除技术有一个优点，就是能够将精简的数据组复制到远程站点，占用的网
络带宽远小于常规复制技术所需的网络带宽。然而，虽然所需网络带宽减少，但开始复制
时，数据重复删除技术还是会花费大量的时间和带宽，因为精简数据不能立即获得，需要
备份以后慢慢获得。在某些情况下，首次复制路径通过本地配置的复制目标获取，在有限
的网络带宽条件下实现各项功能；随后，将二级数据重复删除技术产品发送到异地站点，
恢复重复删除数据的复制功能。
在计划大型恢复战略时，尤其与灾难恢复相关的战略时，必须考虑所有可能的带宽限
制条件。选择合适的灾难恢复站点同样很重要，这样才能实现远程复制目标，不用重新部
署存储，就能实现缺乏带宽或者空间造成的大型恢复。
4 性能
值得一提的是，数据重复删除技术产品处理数据的方法存在一些差异。这些差异会对
恢复能力产生重大影响，不容忽视。一些重复删除技术也称为“带外技术或异地技术”，
意思就是先把数据写到磁盘上，再以数据重复删除技术处理数据，最后将数据写回磁盘。
这种方法在备份过程中具有一定的性能优势，可以在复制过程中创建延迟，从而影响影响
某些数据的恢复点目标（RPO）。如果在数据进行异地复制之前，就发生了灾难性故障，
影响主存储目标，那么这种情况就会导致数据丢失，只能根据最后的异地复本进行恢复。
数据重复删除技术大大提高了备份性能和存档数据的存储性能。只要你考虑外部因
素，选择能满足公司恢复需求的解决方案，重复删除技术无疑会成为非常合适的灾难恢复
战略。
（作者Pierre Dorion 翻译：周姝嫣 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 19 页 共 32 页
灾难恢复清单：网络部分
从这篇技巧中，你可以知道：这份由四个主题——网络总则、局域网、广域网与计算机和
网络基础应用组成的清单可以帮助你集中你的精力在灾难恢复计划上，以确保你的网络安
全有充分保障。
网络总则
当准备一个指定的灾难恢复(DR)的计划时，记住要考虑“局部灾害”。比如，如果你
的互联网电路已经出故障有 48 小时，但所有其它的服务都还能正常运行， 那你怎么办?
并不是所有的灾害都包括“彻底毁灭你的原始数据中心” 。
用图解法来表示你目前的网络并确定网络设备。这些设备的危险程度如何?这些设备
如何适用于确定的公司基建危险程度的商业影响研究?
假定你有一个指定的灾难恢复网络，那它和你目前的网络有什么不同呢?如果灾难发
生，它能否处理加载在其上的负载呢?
你是否有足够的网络文件以应付指定的灾难恢复网络? 一旦灾害发生,每个人都将处
于惊恐之中。一个灾难恢复的成败在于是否拥有恰当的文件。
你的指定灾难恢复计划多久测试一次呢?
适当的弹性在生产网络中是否被考虑到?想想双电源吧，多余的网络路径和多余的电
路。这些网络弹性可能防止你在一开始就受到灾难。
那语音通讯又如何? 你的 IP 网络传送语音(VoIP)?
TT 存储技术专题之灾难恢复技术 第 20 页 共 32 页
执行程序的过程中,一旦执行任何新的网络设备或是改变网络，指定的灾难恢复计划
就进行更新。这会使你的指定的灾难恢复计划总在不断更新。
请务必确保你的补丁和灾难恢复升级设备和其他网络设备一样正常。
当你遇到灾难时，别忘了网络安全。没有终端用户会卸载“杀毒软件”这一关键保
护。不要等到工作 24 小时发现病毒后才更新你的指定的灾难恢复网络。你必须考虑安全
问题，因为用户们不会考虑。
局域网
究竟指定的灾难恢复局域网网络与生产网络相比如何?你并不想用催化剂
(catalyst)6500 来接通生产网络和用催化剂(catalyst)2950 来接通指定的灾难恢复网
络，尝试抛同样数量的带宽，在定的灾难恢复网络。你是你自己的设定导致了失败。
局域网管道(以太网连接) 是否是同样大小的?
你是否有所有设备的网络结构文件的备份?
广域网
究竟指定的灾难恢复广域网网络与生产网络相比如何?
带宽和服务质量(QoS)设置是否相同?
是否对指定的灾难恢复网络的生产量进行测试?
指定的灾难恢复是否能处理和生产灾难恢复相同的生产量?
一旦发生大灾难，或是灾难恢复，或是域名服务器(NDS)出现故障，你的终端用户如
何获得指定的灾难恢复网络?
TT 存储技术专题之灾难恢复技术 第 21 页 共 32 页
指定的灾难恢复网络是都和优先网络，或防火墙，或音频视频，或入侵防御系统，或
互联网隔离区等具有同样的安全性?
指定的灾难恢复网络是否和优先网络一样容易被用户获得?那么网络安全插件，如内
容过滤呢?代理服务器呢?缓存服务器呢?
如果你的广域网提供商也遭受灾难，那你怎么办?你可以考虑通过不同载体使用的指
定的灾难恢复广域网网络或者将你的指定的灾难恢复站点通过你现存的载体远离一个不同
的电话接入站点。
计算机和网络基础应用
你的指定灾难恢复计划是否包括一个动态主机配置协议服务器?或域名服务器?
你的指定灾难恢复计划是否其他重要的服务器，如 Windows 网际名字服务，或文字传
输协议，或 Windows 地址探测器等?
你的网络设备是否要求某种特定的网络服务来运行?例如，一些美国慧智公司的
Winterm 设备就要求使用动态主机配置协议服务器，并且要通过一个一般文件传输协议服
务器来下在它的配置文件。你必须考虑一些像这样并不太重要的服务器，因为它们将时刻
困扰你。
在你所有使用的网络上还有什么其它的网络基础结构应用?这些都被考虑在指定灾难
恢复网络里了吗?
请记住,这是不被视为一个完全的信息技术指定灾难恢复清单。它只涉及到指定灾难
恢复和网络。换句话说，这份清单是为那些思考网络和指定灾难恢复如何相互作用的网络
专业人士提供的。
（作者David Davis 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 22 页 共 32 页
灾难恢复计划的十大潜在问题
你的公司可能已经制定灾难恢复计划，同时投资各项技术支持计划，但是仅仅这么做可能
还不足以保证数据能够得到恢复。
过去几年，自然因素和人为因素引起的灾难越来越多，存储管理员都在仔细审查灾难
恢复（DR）计划，精心测试 DR 计划。
这些都是好消息。但也存在坏消息，大多数计划并不能实现既定功能。大多数 DR 计
划无法保护公司数据安全，下文列举了其中最主要的 10 个原因。
1 没有制定DR计划
如果不是因为 CNN，人们可能永远不会考虑灾难问题。存储管理员只关注每天发生了
什么事，如系统性能、可靠度等。相比于 DR，大多数企业更加注重备份工作，因为即使是
中等规模的企业也会经常需要恢复数据。
很少有人经历过整个数据中心或者整个站点遭破坏的灾难。解决 DR 计划缺失问题，
只有一个方法，就是要组织一人甚至多人制定一份 DR 计划。另外，这些人应该保证制定
出成功的 DR 计划。
2 没有制定业务连续性计划
许多人搞不清 DR 和业务连续性（BC）的区别。DR 计划的目的在于，保证公司的计算
机系统（以及系统中存储的数据）能在灾难后继续使用。但是对于公司而言，计算机系统
只是其中的一部分内容。公司中还有 DR 计划中不曾包括的内容：员工、通讯系统、产品
生产和输送系统、以及其它系统。
TT 存储技术专题之灾难恢复技术 第 23 页 共 32 页
很有可能出现这种情况：数据中心运行良好，但公司运作却出现问题。计算机已经配
备并运行，但是生产、输送产品的员工却因为物理资源匮乏，无法完成工作。或者，公司
客户无法与你的销售人员或客服部门联系。简单地说，DR 计划可能执行完好，但你的公司
却无法继续运作。所以，你必须保证 DR 计划与 BC 计划配套。同样，应该由一人或多人共
同承担责任，制定 BC 计划，与 DR 计划配套执行。
3 公司需求和IT人员的工作重点不一致
存储部门往往会关注难以备份的系统。例如，备份和恢复专家都会花大量时间来确保
数据库能够成功备份。专家之所以在数据库上花费最多的时间，是因为数据库是存储环境
中最大也最麻烦的问题。接下来就是客户数据库，因为客户数据库进行一致性备份时不会
丢失任何数据。
如果你问公司员工，哪个系统应该更受重视，他们肯定会说是客户数据库。在灾难发
生后恢复数据库固然重要，但是公司员工可能会认为数据库应该最后恢复，因此两周或四
周的恢复时间目标（RTO）都在可以接受的范围内。然而，他们希望客户数据库能在灾难
发生后几分钟之内就恢复使用。
因为公司和 IT 人员之间存在这些不一致，客户数据库往往以 24 小时恢复点目标
（RPO）和 8小时 RTO 的方式进行备份，而不是像员工期待的那样几分钟就完成。DR 的工
作重点、DR 设施和流程必须满足公司需求。需要有专人负责保证 DR 工作重点在公司 DR 计
划中处于核心地位。
4 需求和现实不一致
负责确定公司需求的员工应该明白，并非所有的需求都能在技术上实现。大部分公司
员工都会要求 RTO 和 RPO 达到 0 秒，心情好的话可能会降为几分钟。他们希望灾难发生后
能立刻访问数据，他们不能丢失任何数据。实际上，利用一些技术可以达到这个目标，可
财务总监可能不会同意，因为在数据中心的每台计算机中采用这些技术，需要以成本作为
代价。
TT 存储技术专题之灾难恢复技术 第 24 页 共 32 页
因此，保证公司需求得到满足固然重要，但是保证需求具有实际意义同样重要。这个
问题需要公司用户和 IT 人员协商，才能达成一致。他们之前可能会发生这样的对话：
用户：“我们需要 1 分钟的 RTO 和 RPO。”
IT 人员就像《王牌大贱谍》中的邪恶博士（Dr. Evil）似的，将小手指放在嘴边慢慢
说道：“这个目标有可能实现。但是需要耗费 100 万美元。”
用户：“太贵了，那 4 小时的 RTO 和 RPO 呢？”
IT 人员：“10,000 美元。”
用户：“成交。”
如果你的公司一般不发生这样的对话，那么你的 DR 计划很有可能与公司需求存在出
入。
5 DR计划只强调系统的RTO，不强调数据中心的RTO
大多数公司在协调 RTO 时，只是协调每个系统的 RTO。举个常见的 RTO 例子：数据中
心的任何系统必须在 4 小时内恢复。这种方法适用于操作恢复和系统断电的情况，但并不
适用整个数据系统丢失的情况。通常认为，系统需要恢复到能够访问所有系统资源的水
平。例如，大型数据库服务器需要恢复后，应该能访问磁带库中的 20 个磁带驱动器。但
是，如果需要恢复 20 或 100 台服务器，又会发生什么现象？他们不可能同时访问磁带库
里的 20 个磁带驱动器。
IT 人员和需要 DR 计划的公司部门之间进行对话，可能最为困难。因为对话必然涉及
传统备份和恢复模式的关键问题：实际中发生灾难时，存储部门往往不能满足 RTO 和 RPO
要求。除非公司离开数据也能生存几天，否则要想保证灾难后整个数据中心仍然可用，只
有一个办法，即在灾难恢复之前就已经“恢复”数据。一直以来，这个目标可以通过复制
TT 存储技术专题之灾难恢复技术 第 25 页 共 32 页
功能实现。根据数据量的大小，也可以采用其它技术实现。但是实际上，大多数公司的
RPO 和 RTO 不能保证整个数据中心在灾难发生后立刻开始恢复。
6 DR计划没有包括一致性组
多个计算机系统通常为多个商业应用程序服务。这些系统需要即时恢复到同一个恢复
点。但是通常情况下，这只是公司需求和 IT 人员工作能力之间不一致的又一处体现。除
非一致性组（一致性组是指多个卷可以组成一个组，在多个存储单元之间统一管理，以创
建一致性的数据复本。）已经创建，否则就不太可能有合适的技术，即时将一组系统恢复
到同一时间点。没有快照、复制或者持续的数据保护系统等先进技术，就不可能创建一致
性组。
7 无法实现备份
有时候，DR 问题的产生原因非常简单。一些公司具有 DR 计划，RTO 和 RPO 也能实
现，但是如果备份系统在灾难发生之前没有生效，DR 计划也就没有意义了。许多备份系统
已经部分或完全损坏。即使备份的成功率为 95%，在灾难发生那晚还是有 5%的数据没有得
到备份。很少有公司知道哪些数据没有得到备份。系统中的这部分数据是随机分配的，情
况可能没有那么糟糕。但是也有可能一直是同样的数据没有得到备份。许多公司对备份系
统的连续性故障，都不予以追踪，这部分公司的数量令人吃惊。许多备份软件包也不追踪
连续性故障，这是个无法谅解的问题。
造成很多备份系统故障的关键问题在于备份的管理方式。应该根据备份系统的成功率
来评价管理人员的工作。这个想法听起来不错，却会给管理人员带来不必要的压力。结
果，许多备份管理人员就会企图隐瞒管理不当引起的备份故障。他们认为，如果告诉别人
备份出现故障，自己就会被解雇或扣奖金。他们相信，备份会在明天、下周或者下月得到
完善，他们能在别人发现真实情况之前修复这些问题。
解决这两个问题的方法是选用保护数据、管理数据的商业软件。这些软件能提供很难
访问的备份数据的信息，列出连续性故障的清单报告。有些软件也能帮你更好地理解故障
TT 存储技术专题之灾难恢复技术 第 26 页 共 32 页
原因，所以你能彻底解决问题，而不是不断地修复问题。最后，这些软件使得备份系统管
理员无法隐瞒备份故障。这样，整个备份过程变得非常透明，公司主管可以打开 Web 浏览
器，查看公司的备份过程。
8 DR计划没有经过测试
许多公司拥有 DR 计划，而且需求恰当、技术可行。然而，由于测试 DR 计划相当耗
时、费钱，公司通常不会定期测试 DR 计划（每年至少两次）。
想想数据中心在一年中的变化有多大。只有定期测试 DR 计划，你才能发现其中的问
题。例如，DR 计划中可能没有包括新的应用程序；你的文档可能与三月前停用的软件版本
匹配；或者服务器更新了，热备援却没有同步更新。找出这些问题只有一个方法，就是测
试 DR 计划。
9 寻常人员无法实现
公司认为，员工可以随时为灾难工作做好准备。但是，灾难多种多样，这种假设是否
合理？例如，如果遇上水灾、风灾、雪灾等灾害，员工就无法在灾害发生后赶到办公室。
如果桥塌了或者路断了，你的员工就可能无法抵达恢复站点。如果你的 DR 计划假设员工
随时都能做好准备，就有点过了。你必须在 DR 计划中指定一些学识渊博的临时工。
更多地了解灾难恢复
在制定 DR 计划时，最好提供一份或多份 DR 服务的目录。简单地查看一下以下站点的
文章内容，可以帮助你了解制定综合的 DR 计划需要做哪些工作。
10 文档跟不上工作需求
如果你认为公司员工无法在灾难中及时作出反应，那就应该具有一流的文档。在实际
中，大多数文档并非一流。一些文档没有正确维护，可能已过期，有些软件已经几个月或
几年没有使用，引用的系统名称和任务名称早已不存在了。
TT 存储技术专题之灾难恢复技术 第 27 页 共 32 页
自从上次更新文件之日起就在公司上班长期员工的文档很有可能已经过时。然而，临
时工和新员工却需要最新的文档。
要避免发生这个问题，你需要更新存储环境中所有的文档。你还需要雇佣临时工测试
DR 计划，确保文档综合化、精确化、人人都可以理解。如果不是你公司的员工也能说出灾
难发生时需要做哪些工作，那么你的文档就相当完美了。如果不能，你的文档还需进一步
完善。
（作者W. Curtis Preston 翻译：周姝嫣 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 28 页 共 32 页
Windows 管理之灾难恢复计划
可以证明地是，测试 IT 灾难恢复计划的两个最重要的因素是保持计划的更新和测试该计
划在关键时刻是否是有效的。
在理想情况下，每年你都要带领灾难恢复团队只用备份磁带和新硬件在离线环境中无
差错地重建和恢复原有产品系统。听起来好像不错吧?但不幸地是，绝大多数公司没有能
力每年都对其灾难恢复计划进行全面测试。即使有这个能力的公司也需要在此基础上投入
更多。
因此我的问题是：你如何避免在凌晨 2：00 打电话给你老板，请他/她原谅你，因为
你忘记了对分布式文件系统(DFS)共享中放置重要文件的用户验证身份。
测试灾难恢复计划有 4 个主要部分。其中两个步骤是识别出源文件并口头预排计划。
另外两个步骤分别是利用现有方案和从错误中学习，将在在第二部分中详细描述。
识别源文件
源文件识别是灾难恢复计划的基本概念，但许多人都没有正确认识它。你知道灾难恢
复后如何获取所有软件的拷贝，如何重建个人应用程序吗?过于自信的一方也许会说：
“没关系，已经备份好了。”但我对此的第一反应却是：“你敢保证吗?我能获得拷贝吗?
马上可以吗?”
也许你以为大部分都备份好了，但如果你仔细审查备份，就会发现还是有些东西丢失
了，如数据库架构，存储程序，防火墙规则集和 DFS 共享。对于 DFS 共享来说，用户放置
源文件的目录是否是正确的呢?你还忽视了最基本的一点---你有微软 Windows Server
2003 的拷贝吗?
TT 存储技术专题之灾难恢复技术 第 29 页 共 32 页
你永远无法预知什么时候你的备份会失效，以至于你需要一个拷贝从头开始。
别忘了询问你的团队成员是否他们使用了一些工具进行离线备份，如针对 Windows
Server 2008 和 Exchange 2007 的自定义 LDAP 搜索脚本，VB 脚本以及 PowerShell 脚本。
口头预排
给团队成员买比萨饼，只需花费 50 美元，但如果能借此及时发现存在的问题，带来
的效益却是无价的。
你会惊讶于花半小时与你的团队成员一起吃午餐能给你带来什么。开放的讨论对于获
取你公司应对灾难能力的情况是相当有好处的。要使这一活动获得成功，你必须事先花一
些时间对议程作个计划。
评价灾难恢复准备的议程如下：
◆概述(会议目标)
◆Windows Server 组
●组长作 DRP 陈述
●假设分析
●基于分析结果要采取的措施
◆活动目录组
●组长作 DRP 陈述
●假设分析
●基于分析结果要采取的措施
TT 存储技术专题之灾难恢复技术 第 30 页 共 32 页
◆微软 SQL Server 组
●组长作 DRP 陈述
●假设分析
●基于分析结果要采取的措施
◆Exchange/Messaging 组
●组长作 DRP 陈述
●假设分析
●基于分析结果要采取的措施
◆措施项(总结)
假设分析("what if analysis")是指组内每个人都向其它小组成员问一个假设性的问
题，看他们如何应对各种可能出现的故障。
最后一步是确定下次会议的时间，确保每个组都将提出的措施付诸实践。各组组长分
别负责相应的措施。这种活动可以每季度举行一次，以保证每个人对灾难恢复都引起足够
的重视。
（作者Russell Olsen 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 31 页 共 32 页
光盘可否作为灾难恢复数据存储介质的备选方案之一？
Pierre Dorion 是 Mainland 信息系统公司的业务连续性顾问。尤其在
业务连续性，备份和灾难恢复，数据可用性及程序开发方面擅长。 在过去的六年里，他着
重研究存储架构和业务连续性服务。
问：请问光盘可否当作数据恢复存储介质来使用？如果可以，它能够通过审核员的测试
吗？
答：就我个人的经验而言，审核员一般是不会限制用户所使用的数据恢复介质的类型，除
非在特殊情况下，比如说，当各种法案法令正式开始实施后，按照规定，用户必须证明存
储介质上存放的是固定数据，不允许反复擦写，此时，对存储介质将会有严格的要求，用
户只能选用WORM光盘或一次写入光盘。
不过，在大多数情况下，审核员们最关心的问题是：用户是否参照标准规范的流程来
备份和存档信息数据。因此，用户在向审核员展示信息数据备份时，要让他们注意到你已
经制定并实施了遵从法律规定的有效的安全策略，你可以从以下几个方面入手：①数据备
份是完整可靠的；②关键任务数据已制作了多个备份盘，而且分不同地点存放，安全性有
保障；③相关数据都做了必要的备份；④备份数据的存储年限可满足有关法案法令对特定
行业业务数据的保存时间要求；⑤确保一旦有需要时，介质上存储的信息数据绝对是能够
恢复的。 （作者Pierre Dorion 来源：TT中国）
TT 存储技术专题之灾难恢复技术 第 32 页 共 32 页
TT存储技术专题之灾难恢复技术
灾难恢复技术简介
灾难恢复方案的基本要素
灾难恢复策略
如何规划灾难恢复策略
管理灾难恢复
服务器虚拟化让灾难恢复受益
忽视变更控制会毁掉你的灾难恢复计划
利用重复数据删除技术进行灾难恢复时需要考虑的四大策略
灾难恢复实例
灾难恢复清单：网络部分
灾难恢复计划的十大潜在问题
Windows管理之灾难恢复计划
光盘可否作为灾难恢复数据存储介质的备选方案之一？
灾难恢复方案的基本要素
如何规划灾难恢复策略
管理灾难恢复
服务器虚拟化让灾难恢复受益
忽视变更控制会毁掉你的灾难恢复计划
利用重复数据删除技术进行灾难恢复时需要考虑的四大策略
灾难恢复清单：网络部分
灾难恢复计划的十大潜在问题
Windows管理之灾难恢复计划
光盘可否作为灾难恢复数据存储介质的备选方案之一？
