云端灾难恢复时所要谨记哪些？

　　灾难恢复是在安全规划中保护企业免受重大负面事件影响的领域。在信息技术领域，灾难恢复步骤包括恢复服务器或备份主机、用户交换机(PBX)重建或提供局域网(LAN)来满足当前的业务需求。本次课课家教育平台为大家带来了云端灾难恢复时所要谨记哪些?大家一定要认真阅读哦~

　　当云计算的概念开始出现时，有很多人谈论在紧急情况下可以提供负担得起的，可管理的“二级”数据中心是多么的美好。希望在采用云计算之后，可以不再需要一个二级或备份数据中心作为解决潜在灾难的手段。而在云计算出现后，有些企业已经从拥有自己的云端转向租用云。对于那些刚刚成长的企业来说，他们需要这样一个灾难恢复选项，许多公司立即采用云计算，这是因为与其投资建设一个数据中心，不如采用名副其实的云计算。

　　与传统的灾难恢复架构一样，采用基于云计算的辅助站点不仅需要复制数据中心，还需要不断地进行数据更改，并保持警惕，以确保这些更改及时地复制到其辅助站点。而采取的形式取决于在灾难发生时企业的记录计划，以及所认为的灾难。

　　因为它总是动态的和可用的，云计算提供支持多级灾难恢复的能力。从单个应用程序到整个数据中心，有很多方法可以确保这些应用程序和对业务至关重要的数据的可用性。此外，云计算提供商提供的各种资源成本模型使组织能够挑选并选择支持短期恢复的资源成本模型，或者使用传统的高可用性模型，实现大规模的即时故障转移。

　　当然，组织可以回到传统的“全有或全无”模式，在整个数据中心在云计算中实时复制，并利用全局服务器负载均衡立即重定向用户的主站点被灾难或意外丢失的连接。这种方法的优点是组织可以在“双活”架构模型中利用这两者，其中诸如地理位置，性能或甚至利用率的因素可以实时确定用户指向哪个“数据中心”。在两个数据中心都是活动的，以避免甚至短暂的停机时间的情况下，这样的模型可以通过提供除了其明显的存在价值之外的益处而对组织有益。

　　公平地说，这种方法随着时间的推移是昂贵的。保持两个数据中心与实时数据的实时复制并不容易，实现的成本也较高，即使在云计算中。但是，这种投资的回报是有价值的，特别是如果企业的主要数据中心处于易受自然灾害影响的地理位置。因为预防的成本总比灾难损失要低得多。

　　成本较低的方法可能涉及基于云计算的灾难恢复架构，其中只有关键应用程序保持活跃，而其他的则停滞，除非需要。根据用户，合作伙伴，员工的期望，组织可以根据商定的服务等级协议(SLA)平衡运营成本，包括灾难发生时的恢复时间。被认为非必要的应用程序和系统可能根本不可用，而被认为关键的应用程序和系统将立即可用，而次级层中的应用程序和系统可能被是几小时甚至一整天，然后再次访问。企业同意在云中恢复访问的及时性将决定其需要复制其各自数据的频率，从而影响维护的总体成本。

　　无论企业的方法如何，这是了解其云提供商最好的方法。云计算提供商的一个好处是，他们倾向于在许多地理位置拥有物理数据中心，企业需要知道自己将备份数据中心设置在哪里。如果所在的云与其主要数据中心在同一个城市的话，容易遭遇与企业数据中心相同的灾害。因此，就像企业建设物理数据中心一样，企业基于云计算的辅助数据中心需要在地理位置上与主要数据中心分开。

　　如果企业是完全在云计算中运行业务的少数组织，那么就让企业成为第二个云提供商，因为很少有云计算提供商出现严重中断的情况。这样，企业可能不再需要其辅助数据中心的灾难恢复服务和关于如何处理云计算的故障的计划。

　　鉴于灾难恢复的整个概念是基于这样的前提：随机的，不可预测的事件将通过将其从互联网上切断而使企业的业务中断，如果企业对物理数据中心执行灾难恢复计划，企业应该计划在一个基于云计算的数据中心上执行。对于企业主要数据中心的位置来说，应该有一个更好的可执行计划。

　　干货：以下是将云服务添加到灾难恢复计划的七招。

　　选择要慎重：

　　现在有许多选择。除了上述四家公司外，还有Zerto、HotLink和Veeam等提供商，它们都提供专业的云灾难恢复服务。不过认真打量一番这些提供商，我们就会发现它们之间的不同。有些适合不太需要频繁访问的批量存储，而另一些则更适合复制。当然，定价模式和费用也大不一样。对某一种类型的流量而言是经济高效的云服务，而对另一种类型的流量则可能不那么合适。

　　使用云改善RPO/RTO：

　　恢复时间目标(RTO)是指用户愿意等待、直到站点恢复如初的时间。恢复点目标(RPO)则是指万一出现灾难，用户愿意失去的数据量。Zetta公司的产品副总裁Chris Schin指出，就传统的灾难恢复解决方案而言，RPO只适用于被迁移到灾难区域以外某个异地位置上的一个备份集。如果灾难发生时备份仍在现场，那备份到磁带或闪驱上的任何近期数据都恢复不了。

　　如果你使用物理存储介质将数据迁移到异地，灾难场景下的RPO并不取决于备份软件的参数，而是取决于那些磁带被送到异地磁带库的频率。如果是每周一次，那么PRO最多就是为期一周的数据量，哪怕你之前每小时快照一次。

　　迁移工作负载：

　　把备份之外的工作负载也放到云端。她建议，可以把一些工作负载整个放到云端，看看效果如何。她说：“毫无疑问，使用云基础设施来备份数据具有优势，不过，你不仅可以备份文件和数据，还能将物理服务器的整个工作负载(包括操作系统、应用程序和数据)直接移到任何云上，比如亚马逊云服务、RackSpace或SoftLayer。”

　　考虑全面的云灾难恢复：

　　一些公司正在想方设法成为所有备份数据的云存储库，其中谷歌走得最远，它竭力推销Google Apps，希望将用户的全部数据都存储到云上，并负责处理相关的灾难恢复。

　　使用多个云：

　　虽然这个行业的技术巨擘们拼命吆喝使用一个综合云里面的多个数据中心，但LC Technology International公司的CEO David Zimmerman则提议，使用多家云服务提供商来用于灾难恢复，以降低风险。他说：“别仅仅使用一个云，而要使用多个云来降低风险，可将数据备份到每个云，实现冗余机制。由于成本日益下降、可靠性日益提高，云大有希望，不过企业仍应该小心行事。”

　　物理系统作为补充：

　　降低风险的另一个办法就是，继续保留某种基于物理系统的灾难恢复方案。如果整个云被黑客盯上了，或者丢失了网络，这实际上相当于将全部鸡蛋都放在云这一只篮子里面。

　　莫忘保护不足的工作负载：

　　Sash Sunkara支了另一个妙招。她特别指出，在许多数据中心，受保护的工作负载往往被分成两类：关键任务型，这种工作负载即使停止运行几分钟都不行;低优先级型，这种工作负载在归档时可能需要花几小时、甚至几天才能恢复。前者通常由非常昂贵、先进的高可用性和集群解决方案加以保护，这类解决方案能实时同步复制系统。后者往往由磁盘归档或磁带备份加以保护，成本非常低廉，但恢复速度也很慢。

　　小结：了解应用程序和它们的依存关系。明确哪些应用程序需要抵抗灾难的能力。要考虑到(主站点和备份站点)存储和网络架构之间任何潜在的差异，确保程序即使在不同的环境下，也能够按照预期实现把故障转移到备份站点。当然如果大家还想了解更多相关方面的内容的话呢，课课家教育平台欢迎大家咨询!