灾难恢复计划

现在是时候回顾一下您的DR计划了.

发生了很大的变化 灾难恢复 十多年来，我们从卡特里娜飓风中得到了第一手的教训. 服务器虚拟化现在使许多系统的恢复比以前更容易和更快, 云计算的兴起为我们提供了比我们之前想象的更多的选择.

飓风季节正式来临, 这是检查灾难恢复解决方案当前状态的好时机.

什么是灾难恢复?

第一个, a bit of terminology; This article is about 灾难恢复, 就我们的目的而言，哪一个处理的是对灾难后企业重要的技术系统的继续或恢复——而不是业务连续性, 它涵盖了保持企业运行的所有方面.

任何灾难恢复讨论都涉及术语恢复时间目标(RTO), 需要多长时间才能启动并运行, 和恢复点目标(RPO), 指的是数据丢失的时间段. 灾难恢复通常以小时为单位度量RTO和RPO. 高可用性是处理以秒或分钟计算的RTO和RPO的另一个主题.

最后，请记住，灾难恢复不同于备份. 灾难恢复侧重于恢复整个系统，备份侧重于恢复数据. 如果我需要找到上个月删除的邮件，我需要备份. 如果我需要在我的大楼失火后启动我的电子邮件系统, 我需要灾难恢复. 尽管如此，还是有一些产品能够很好地实现这两种功能.

利用云计算

我最喜欢的完成灾难恢复的方法是通过使用完全由云软件即服务(SAAS)提供商管理和托管的应用程序来解决问题. 当正确的 基于云计算的 应用程序以合适的价格满足您的需求(并具有自己的文档化灾难恢复计划), 我说用它. 这种方法非常适用于电子邮件, 文档, 某些业务应用程序, ,很快, 如果不是今天, 电话系统.

当然, 目前还没有满足每种需求的SAAS应用程序, 下一个最佳选择是将自我管理的遗留应用程序从办公室的服务器转移到弹性数据中心或云基础设施即服务(IAAS)提供商. 像之前一样, 确保您的提供者和设计满足灾难恢复预期仍然很重要.

远程工作

这里的问题是，许多应用程序在远程托管时不能很好地执行. 有时使用远程桌面或Citrix是一个解决方案, 但事实并非如此, 下一种方法是将应用程序保持在本地，并将它们复制到云或分支机构. 有很多方法可以做到这一点, 从一次处理一个应用程序或服务器的低成本解决方案，到能够同步数百台服务器并实现自动故障转移的企业解决方案. 假设你的互联网连接大小合适, 复制可以很好地工作, 但它肯定需要良好的文档和定期的测试，以确保一切尽可能顺利进行.

其他方法可能包括在停机期间针对特定需求使用完全不同的应用程序, 求助于笔记本电脑上的单个用户，而不是完全网络化的应用程序, 或者放弃灾难恢复，并依赖于那些可接受RTO较高的应用程序的备份.

好消息是，无论发生什么事，保持你的公司继续运营从来没有这么容易过, 如果你在过去一两年没有回顾你的计划, 现在是时候了.