随着服务器虚拟化的到来，有些人声称灾难恢复(DR)和保持业务连续性(BC)能够更的容易实现了，甚至认为这些都是属于过去的事情了。
这种情况的出现是很容易理解的。现如今，与任何一名虚拟化管理员交流时，都会谈到使用传统的备份和磁带的想法和理念似乎已经是一个遥远的记忆了。
自虚拟化技术采用初期开始，我们就已经看到高可用性集群和诸如vMotion等功能的引进，似乎解决了大部分数据保护方面的需求。
但是，如果仔细推敲，我们就会发现这些说法是有些夸张的。
定义灾难恢复
能够确定一个定义的基准总是好的。而且，这在灾难恢复规划方面也是相当有必要的——读者可以点击这里以便了解全面的指南。灾难恢复和保持业务连续性在其各自的定义方面稍有不同：
· 业务连续性描述的是确保业务持续运作的过程。
· 灾难恢复描述的是在某次灾难袭击后恢复服务的过程。在大多数情况下，企业将希望尽可能的避免这种情况，或者至少将其可能性降至最小化。
目前，在灾难恢复和保持业务连续性方面，还有两大被广泛应用的定义。即恢复时间目标(RTO)和恢复点目标(RPO)——二者都为数据恢复确立了一个服务水平：
· 恢复时间目标确定了将业务恢复到正常运营状态的预期或目标时间。一个零RTO意味着服务必须立即恢复，或者没有中断。一小时的RTO需要在一小时内恢复应用程序至正常使用状态。
· 恢复点目标则表示的是必须将服务恢复至历史时期的某点。一个零RPO意味着服务必须从那一历史时间点开始，所有数据均必须恢复，不能丢失(针对银行应用程序是必须的)。而24小时的RPO则意味着只需恢复到昨天的数据即可(可用于测试/开发环境)。
制定一套灾难恢复计划
在理想的情况下，所有的应用程序应该恢复至RTO等于零，且RPO等于零，但从可行性和成本方面来看则是站不住脚的。
相反，任何灾难恢复和保持业务连续性规划都应该始于建立灾难场景，对灾难场景的重要性和影响进行评估，并将其应用到每款应用程序中。例如，故障场景包括：
· (火灾、停电、洪水、地震)造成的损失或损害。
· (火灾、水灾、危险灾害、化学事件、辐射)造成无法访问基础设施。
· (心怀不满的员工或网络攻击)犯罪行为或恶意伤害。
· (软件错误，升级失败，数据损坏)造成系统或应用程序故障。
我们可以评估每款应用程序发生故障失败所造成的影响，并用它来决定我们的RTO/RPO服务级别目标(SLO)。同样，这里也有一些例子：
· 电子邮件系统的停机影响——高冲击;RTO = 30分钟，RPO =零。
· 银行核心应用程序的停机影响——关键性冲击;RTO =零，RPO =零。
· 隔夜报告程序的停机影响——低影响;RTO=4小时，RPO = 24小时。
在今天这样一个永远在线的世界中，大多数面向客户的应用程序预计都将需要保持24/7全天候的运行。这会降低一定的SLO，但应用程序的设计可以通过从后端功能分离前端接入访问来尽量减少。
显然，无论一款应用程序是否已经被虚拟化，其技术是否独立，业务恢复的要求必须首先确立。事实上，应该始终由企业的业务部门来提供他们具体需求方面的指导，而不是让IT强加标准，这一直是传统的经营运作模式。
虚拟化如何帮助灾难恢复
虚拟化将服务器的物理资源抽象成逻辑结构，代表硬盘，网卡、磁盘控制器。处理器、内存和网络端口以配置文件中的参数来表示，硬盘则用本地或共享存储的文件来表示。
因此，备份虚拟机(VM)是复制一个文件副本和配置数据的一个简单的情况。此外，可以实现迁移虚拟机到替代硬件，即使物理硬件是不相同的。这使得能够更容易的管理硬件故障问题。虚拟化的功能解决了灾难恢复和保持业务连续性在以下几个方面的问题。
简单的备份/恢复
恢复通常是基于创建一个备份和在一个灾难恢复的情况下从这些备份副本恢复的需要。为了满足这种需求，虚拟机管理程序所提供的功能，允许备份可以通过复制VM的内容。为了确保数据的完整性，虚拟机运行的代理软件或工具在复制VM文件时停止或暂停I/O。
一个简单的备份可以用来提供文件、应用程序或虚拟机级别的恢复，这取决于备份软件的复杂性。备份整个虚拟机快照会影响一些系统允许存储系统快照的功能，结合虚拟快照卸载处理工作，同时保持数据的完整性。
虚拟机迁移
虽然不是严格意义上的数据恢复过程，能够在物理硬件之间动态地迁移虚拟机的能力减少了硬件故障的影响。VM迁移本身并不能防止服务器故障，但可用于当发生局部故障时迁移虚拟机，无论是在服务器或其它组件(例如网络)。
虚拟机迁移也可以在当服务必须从一款硬件(为了维护)移除或为了减轻数据中心失败的风险(如应对即将到来的风暴或飓风可能对数据中心运营的影响)时，作为一个控制过程。从这个意义上说，虚拟机迁移更类似于保持业务连续性，确保服务器继续运行，即使是在发生潜在或实际事件的情况下。
高可用性/容错能力
这些是管理程序的功能，使虚拟机能够在硬件故障的情况下保持运行。提供了两个层次的服务。高可用性监控虚拟机，并在服务器发生故障的情况下，在替代硬件上重新启动。这导致了一个小故障的应用程序重新启动。其他在替代硬件运行ghost虚拟机映像，使得该映像在服务器发生故障的情况下成为生产服务的一体，一般没有应用程序中断。
当然，使用这些功能可能需要共享存储硬件(用于存储虚拟机的配置和数据)，同时也是收费的。一些供应商支持使用基于阵列的复制与高可用性/容错功能相结合的能力。这使得硬件配置能够跨越一个很短的距离(几百米)，并创建一个Metro cluster。Metro cluster能够减轻数据中心的中断或严重的硬件故障，而无需部署复杂的应用程序集群。
连续备份
某些第三方应用程序使用虚拟化来拦截虚拟机的写I/O，并创建一个远程备份映像。这个过程是异步发生的，并提供了在故障的情况下的虚拟机副本，可用于在主站点发生故障时加强故障转移复制。使用这种系统的应用程序的RPO将取决于数据可以迁移到场外的速度。
应用程序弹性
正如所讨论的那样，虚拟化通过抽象物理硬件组件提供好处。在执行灾难恢复/业务连续性时需要考虑的另一件事是在应用程序本身直接内置恢复功能。
应用程序的弹性是通过运行许多应用程序实例来实现的，每一款均可能失败，当然也能够通过替代硬件来重新启动。这种设计是不直接依赖于虚拟化，但可以通过多个管理程序和硬件的配置来实现很好地工作。在未来，我们将看到业务连续性/灾难恢复的弹性将借助container容器的使用来实现，这是一种应用程序虚拟化的形式，并已经开始在被广泛采用。
参照诸如RTO和RPO等灾难恢复/业务连续性原则，我们可以应用恢复选项以满足应用程序的需求。有些应用程序会得到充分的高可用性/容错能力，而其他应用程序可能只是使用虚拟机管理程序的快照进行备份。在某些情况下，持续备份或全高可用性/容错能力与基于阵列的复制可以是合理的。其完全只是基于具体要求来应用技术。
