灾难恢复（Disaster recovery，也称灾备）指自然或人为灾害后，重新启用信息系统的数据、硬件及软体设备，其核心即对企业或机构的灾难性风险做出评估、防范，特别是对关键性业务数据、流程予以及时记录、备份、保护。
灾难恢复（Disaster recovery，也称灾备），指自然或人为灾害后，重新启用信息系统的数据、硬件及软体设备，恢复正常商业运作的过程。灾难恢复规划是涵盖面更广的业务连续规划的一部分，其核心即对企业或机构的灾难性风险做出评估、防范，特别是对关键性业务数据、流程予以及时记录、备份、保护。
灾难恢复定义
本文讲述的是信息技术与管理概念。关于人体意外与急救，详见“灾难应对”。
灾难恢复，指自然或人为灾害后，重新启用信息系统的数据、硬件及软件设备，恢复正常商业运作的过程。灾难恢复规划是涵盖面更广的业务连续规划的一部分,其核心即对企业或机构的灾难性风险做出评估、防范，特别是对关键性业务数据、流程予以及时记录、备份、保护。
虚拟化恢复
通过允许虚拟机在物理服务器之间进行无缝迁移，虚拟化提供了革命性的灾难恢复计划。
构建灾难恢复站点的准备
在构建一个远程 VMware 灾难恢复站点之前，有许多问题需要考虑。
清查现有的基础设施。在彻底理清一个主要数据中心的资产之前，不能对其进行复制。
了解应用程序和它们的依存关系。明确哪些应用程序需要抵抗灾难的能力。要考虑到（主站点和备份站点）存储和网络架构之间任何潜在的差异，确保程序即使在不同的环境下，也能够按照预期实现把故障转移到备份站点。
建立恢复点目标（RPO）和恢复时间目标(RTO)。 如果数据每小时复制到第二数据中心，当灾难发生时，有可能最多丢失之间 59 分 59 秒的数据。如果这样是可接受的，不会严重地影响业务，那么 PTO 可以设定为一个小时。
为用户服务。终端用户也许不能够访问运行维护的所有的服务器和应用程序。要考虑怎样替换用户们的桌面和应用程序，明确他们怎样进行远程访问。
构建灾难恢复站点的实施
选取数据中心地址。一条可承担到主数据中心的高速连接是选择灾难恢复中心需要考虑的关键的几个因素之一。
获取、安装和准备硬件。
安装和配置 vSphere。
选择工具。
实施复制。初始化数据的复制将是最大规模的数据传输，随后的对发生改变的块进行复制将会小很多，但是复制数据的大小会依据应用程序中数据量改变的大小而定。复制的数据的大小也会依据复制的间隔（由 RPO 决定）而变化。
虚拟化在灾难恢复时中的作用
硬件独立：基于物理系统的灾难恢复解决方案都需要将相同的硬件保留到恢复站点，或必须经过很多复杂耗时的步骤在新的或不同的硬件上重建服务器操作系统。有时候碰巧恢复服务器就是同一个硬件模型，但是包含了最新硬盘控制器固件，会导致服务器镜像延迟。虚拟化使硬件从操作系统中抽象化，而且使操作系统中使用的设备驱动器统一化，不管是何种底层硬件模型，所有虚拟机都使用一个共同的驱动集。这样，在新服务器上安装服务器镜像时就省了很多设备驱动对应的麻烦，大大减少了恢复时间和配置错误的风险。
虚拟机磁盘格式文件：虚拟机将其子操作系统、应用、存储和配置（如 IP 地址）存放在一个文件里。这个文件——虚拟机磁盘格式（VMDK）或虚拟硬盘（VHD）文件，包含了整个操作系统环境以便能进行简单的虚拟机装载和保存。这个文件不仅包含了操作系统镜像和应用编码，还描述了虚拟机所需的配置，其中包括虚拟处理器、内存和设备。这个简单的可移动文件包含了组成服务器所需的一切信息、服务器环境描述、实际码和数据。从虚拟机磁盘文件启动虚拟机时系统会自动迅速设置所有参数。在灾难恢复站点进行恢复会变得很简单，只需启动 VMHD 或 VHD。
物理工具到虚拟工具：虚拟机解决方案需要利用管理工具来创建、启动、停止和保存虚拟机镜像。为了方便创建虚拟机，有很多工具可以帮助分析物理服务器和从服务器创建 VMDK 或 VHD。从物理系统创建的 VMDK 或 VHD 文件可以很快地部署到恢复站点。
硬件再利用：恢复站点的虚拟机硬件不必闲置在那里等着灾难发生，它也可以用作开发、测试或其它用途。当发生灾难时，关闭用于测试或开发的虚拟机，然后启动生产虚拟机，这个过程只需几秒钟即可完成。
灾难恢复的复杂性剖析
由于用户对于服务器虚拟化技术接受程度不断提高，业界有一种对于所谓的“万能的高可用策略”的需求。虽然这种做法可以在一定程度上通过集群故障迁移技术实现简化数据保护的步骤，但并不是所有的数据保护都支持这种做法。
首先，即使当前关于服务器虚拟化部署最乐观的预测成为现实，到 2016 年也仍然有 21%的 X86 平台的关键业务（产生收入的高性能事务处理程序）运行在高达 75%的没有使用任何虚拟化技术的物理服务器上。所以，针对虚拟化和非虚拟化的不同服务器采用不同的策略是很有必要的。
在采用了 x86 虚拟化技术的工作负载中，一些虚拟机（VMs）和它们对应的数据盘（表现为 VMDK 和 VHD 文件）相比其他虚机和数据盘次要一些。在没有使用虚拟化技术的环境中存在很多不同的虚拟程序，但并不是所有的应用程序都是关键业务相关。传统的服务器环境中，一些应用程序和虚拟机被频繁使用，也有一些使用的不是那么频繁，这些现实情况都影响着数据备份和数据复制的频率和策略。
灾难恢复计划
制定灾难恢复计划和构建基础架构是一件让 IT 经理烦恼的事。云服务提供更低的成本和更大的灵活性,但并不是没有风险的。
灾难恢复即服务意味着更多的部署和灵活性测试,但也意味着更多的不确定性。
灾难恢复(DR)会导致大量令人棘手的问题;灾难恢复系统价格昂贵, 灾难恢复配置难度较高,而且大多数灾难恢复只能在非业务时间进行故障恢复测试，灾难恢复模拟故障的内容很容易就过时了。灾难恢复服务(DRaaS)是一种云端容灾的方法,成本更低,更容易部署,有定期提供测试计划的能力,能与企业的变化保持同步。
值得注意的是,云端的灾难恢复选件可能在毁灭性的灾难之后不可用。这意味着滞留 IT 资源和数据,使企业瘫痪。
如何制定灾难恢复计划
数据中心工作人员和业务相关人员花了很多时间和精力在到制定和测试灾难恢复脚本上。
首先,预测潜在的数据中心灾难：灾害性天气,停电,供应商系统脱机,内部人员的破坏或外部攻击都是有可能的。
确定公司的灾难恢复应用程序要立即在线。审核清单和优先考虑日常运作的重点程序。
接下来, 原始资料和安装冗余数据中心基础设施——服务器、软件、网络连接、支持应用程序的载体,。灾难恢复计划无法避免成本考虑;一个离线数据中心是昂贵的。
通常, 灾难恢复计划要求复制每个应用程序的基础设施组件。此外, 灾难恢复需要和主备份站点网络连接，给备份系统当前的软件信息。
适当的工作人员需要了解如何调用备份进程。他将决定哪些系统使用和哪些员工应该更换系统备份。灾难恢复的职责包括通知他们的网络和系统提供商更改的数据和确保员工知道如何恢复系统。理想情况下,业务用户只是略有影响。IT 团队需要在灾难恢复数据期间提供最新的备份资料程序给工作人员。
IT 部门经常花很多时间在设计和分析物理灾难恢复计算环境上,而不是把时间用在编码和测试中增加价值。测试一个灾难恢复计划,数据中心团队要和相关的操作系统和所有最新的补丁一起测试需要,接收、框架、堆叠和安装硬件。他们创建灾难恢复用户帐户,部署框架或应用程序服务器环境和安装测试工具。程序员可以花一半的时间在普通的灾难恢复基础设施问题上,而不是把时间用在实际的测试程序。
因为灾难恢复过程复杂,企业通常一年一次或两次进行测试偶发性的灾难恢复计划。公司越大,对灾难恢复计划证明过程越复杂。
一旦灾难恢复程序进入计划,他们很快变成过时。应用不断变化,因此团队必须在经常审查和更新灾难恢复程序。大公司在计划的每个细节上花费员工众多的时间和高达 7 位数以上的金钱($1,000,000+)。灾难恢复花费更多以确保计划仍然是可行的。
许多企业只是口头上承认灾难恢复。在 IT 投资上，花大量的时间来缓解这 1%,甚至更低的灾难恢复风险似乎并不是个好的投资。IT 经理有一份又长又不断增长的日常优先清单,而当灾难发生时，灾难恢复是唯一重要的事。
灾难恢复服务选项
云服务在共享基础设施上不断省钱。云的虚拟化和自动化的进步使之有更大的灵活性。企业根据需要使用云资源,虽然只是在关键的应用上。暂时的案例中灾难恢复测试发生容易增加。
基于云端的灾难恢复,程序员不用在比特和字节上苦干;他们在硬件和操作系统界面上工作。因此更多的 IT 自动化的任务,生产力的提高和灾难恢复测试时间的减少。数据中心的工作人员可以做为优先程序更经常, 分配更多的资源测试整个灾难恢复服务功能。
云端灾难恢复服务的价格正在上升: 根据咨询公司预测，从 2013 年的 640,800,000 美元涨到 2018 年的 5,800,000,000 美元,复合年增长率为 55.2%。
当云端成为一个风暴
灾难恢复服务有其局限性。
“云端灾难恢复供应商无法完备份系统冗余,“剑桥公司的灾难恢复分析师 Rachel Dines 说。
灾难恢复供应商不能证明以模仿每个客户的基础设施设置建设的数据中心成本, 所以他们走捷径。灾难恢复服务提供商将构建系统处理数量有限的故障。理论上讲,如果遇到灾难恢复特定场地的问题，比如数据中心的电力中断，企业将灾难恢复他们的系统,。然而,如果发生重大自然或人为灾害,可能没有足够的空间在灾难恢复站点运行每个灾难恢复服务客户的应用程序。当发现当灾难发生时， IT 组织在危难关头唯一能做的是找到它并解决,因为灾难恢复服务比传统的灾难恢复构建有更大程度的风险。
云端的灾难恢复也增加了企业网络带宽的需求。在供应商的云端灾难恢复服务放置应用程序副本和虚拟机(VM)镜像。那些应用程序和虚拟机镜像不断更新,来自企业生产站点与灾难恢复服务供应商的数据中心的数据传输。这种加载应变可用带宽。灾难恢复服务能够很好地处理简单的应用程序,但可能降低网络性能的进程密集型系统,如客户关系管理、企业资源规划应用程序。
四种方式
对于企业——特别是自己运行虚拟桌面环境的企业——来说，确保部署可靠的灾难恢复计划是非常重要的。但是现在应该如何制定 VDI 灾难恢复计划？我们可以考虑 Hyper-V、Windows To Go、存储同步和离线虚拟桌面等四种方式。
Hyper-V 的灾难恢复
第一种灾难恢复方式不是很常用，但是据我所知已经至少有一家企业选择使用这种灾难恢复方式。这家企业在微软 Hyper-V 平台当中运行自己的灾难恢复虚拟桌面，并且将灾难恢复虚拟桌面的备份版本存储在云中以防万一。 对于大规模灾难恢复事件来说，企业 通常会和硬件供应商达成协议，供应商将一批桌面 PC 租借给企业以供紧急使用，直到企业完全从事故当中恢复为止。根据协议，这些 PC 将会运行 Windows 8 并且已经安装 Hyper-V。企业的灾难恢复计划是将虚拟桌面的备份版本推送到所有 PC 上，使用 Windows 8 当中的 Hyper-V 功能为用户提供灾难恢复虚拟桌面服务。 然而对于灾难恢复大型企业来说，完成这项灾难恢复计划需要投入异常庞大的工作量，因此灾难恢复可能是不切实际的，但是对于灾难恢复中小型企业来说，灾难恢复确实是一种十分高效的方式。这种灾难恢复方式使得企业不再依赖于任何后台基础架构，就能够恢复虚拟桌面的正常运行。 唯一的要求是 DHCP（动态主机配置协议）服务器可以为虚拟桌面分配 IP 地址。对于这种灾难恢复情况来说，企业可以使用无线路由器提供到 PC 的网络连接并且分配 IP 地址。
Windows To Go 的灾难恢复
另外一种可行方案是 Windows To Go 的灾难恢复。这种灾难恢复特性在 Windows 8 当中被首次推出，灾难恢复允许由 USB 闪存盘引导启动 Windows。 采用这种灾难恢复方案的企业需要在遭遇灾难袭击之前，制作大量的 USB 闪存盘。将这些闪存盘存储在远离办公地点的场所，在遭遇灾难袭击时分发给用户。 不幸的是，使用 Windows 7 的企业不能采用 WindowsTo Go 这种灾难恢复方式，但是可以使用 Boot to VHD 作为替代灾难恢复解决方案。 不论对于 哪种灾难恢复情况，USB 闪存盘的容量都将限制虚拟桌面镜像的大小，因此，安装有大量应用程序的桌面镜像并不适合存放在 USB 闪存盘当中。 这种灾难恢复方式的另外一种缺点是如果想要实现真正的高效恢复，就需要提前花费大量时间准备闪存盘。如果虚拟桌面镜像版本十分稳定，那么并不是什么问题，但是如果企业需要定期更新其虚拟桌面镜像，那么这种灾难恢复方式就变得不切合实际了。
存储同步的灾难恢复
另外一种在 VDI 灾难恢复领域使用更为广泛的方式是将现有环境构建在多个数据中心，或者灾难恢复直接延伸到云中，但是这种灾难恢复方式是否可行在很大程度上取决于厂商的解决方案。虽然这是一种最为可靠的灾难恢复方式，但是灾难恢复也是最为昂贵的。 横跨数据中心的基本理念是扩展虚拟桌面所在的主机集群，以便能够分布在多个数据中心。同时将保存有虚拟硬盘的存储设备复制到其他数据中心，使用这种灾难恢复方式，可以将虚拟桌面同时存储在两个不同地点。 尽管理论上，可以实现将虚拟桌面故障转移到第二数据中心，但是在第二数据中心创建一个完全分离的虚拟桌面池却是一种更为高效的灾难恢复方式；将虚拟桌面运行在其他位置也会产生网络变更需求。 在一些灾难恢复情况当中，相比于远程恢复现有虚拟桌面，将用户连接到其他位置的虚拟桌面可能会更加容易一些。
离线虚拟桌面的灾难恢复
VMware 提供的新特性允许移动办公用户离线查看和使用虚拟桌面。理论上，企业可以使用这种灾难恢复方式实现灾难准备，以灾难恢复应对能够提前通知的、即将到来的灾难，比如缓慢逼近的飓风。 但是这种灾难恢复方式的缺点也十分明显。首先，在灾难已经出现之后采用这种灾难恢复方式并不容易。其次，这种特性只能工作在 VMware 环境当中。 已经部署 VDI 环境的企业必须在灾难恢复业务连续性计划当中解决虚拟桌面问题。保证后端服务器资源在灾难袭击之后还能够正常工作是最为基础的部分，但是如果没有虚拟桌面，用户就不能正常访问这些资源。
灾难恢复现状
若处理得当，灾难恢复（DR）计划是一项复杂而耗时的任务，这有助于解释为什么在过去的几年中，调查显示有连续计划的企业数量在下降。在一个年度普华永道（PricewaterhouseCoopers）的研究中，有灾难恢复计划的企业下降到约为 39%，而同期的调查为 50%左右。这些公司中，那些真正测试灾难恢复计划的企业通常是声称有计划中的一小部分。这些只有灾难恢复计划文档但是没有实际测试的公司，其实际上对灾难恢复的准备更加让人担忧。
由于对灾难恢复必要性和实际价值的误解，相关的计划活动也少了。明显的，虽然“更少（的员工）更高效的工作”就是“使用计算机来提高效率，”并且较少员工数量实际上更加依赖于自动化资源不间断的使用以及减少（哪怕是短时间的）中断操作带来的误差，但是这些见解和确保自动化的连续性和弹性的需求并没有联系起来。
