在过去的这个周末，我们在弗吉尼亚州遇到了严重的风暴，当然日本的危机提醒人们，事情可能会心跳加速！我问自己一个问题：“如果龙卷风袭击了我的数据中心，我准备好了吗？”
我在机架中有出色的备份系统，其中包括磁带备份。由于数据中心没有关闭，因此无法将磁带移离现场。我想要找到或创建的系统可以按计划排定备份关键项目（例如网站，数据库）并远程复制它们的系统，即我的服务器在家里。我有35兆位服务的FIOS，所以我有宽带，我需要做的是“系统”。我是一名程序员，所以我可以按计划创建一些FTP停机信息，但是我很好奇是否有什么东西可以满足现在的远程备份需求吗？我的SQL Server已备份到存储阵列，我可以关闭这些备份，甚至在此处安排我的SQL Server以按计划与生产服务器同步。我使用Windows Server 2008 R2和SQL Server 2008 R2。
在自然灾害导致我们的数据中心崩溃之类的危机中，大家都对场外策略有何建议？准备好了吗？我希望其他人问自己这个问题，并从我们经常看到的自然灾害中学习。
Answers:
您的选择应由与客户的服务水平协议决定，并受预算限制。
至少，您应该对所有关键数据进行异地备份。如今，您无法从头开始重新创建的任何数据都需要存储在其他位置。离线备份更好：当龙卷风袭来时，在线备份或复制可能会有所帮助，但是如果您生气的员工删除数据库或破坏文件系统会怎样？
从脱机备份的基准开始，您可以开始探索可以加快恢复速度以换取更高成本的选项。这里有很多选择，从单个主机用于您描述的在线备份，到完全复制的环境，其中同步数据复制运行active（-active）+，停机时间几乎为零。
如果您将数据与基础架构尽可能整齐地分离，您将发现从零开始恢复要容易得多。例如，如果使用using或Chef之类的系统而不是手动进行部署，则从头开始恢复将要快得多。如果您可以实现尽可能多的自动化，那么重做您在构建系统中投入的所有工作将更快。保持数据分离还可以减少备份所需的数据量：如果您只需要几兆的系统配置和应用程序数据，请不要剥离千兆字节的OS。
这些选择的价格可能会非常昂贵，因此您需要确定公司愿意在灾难恢复上花费多少，以及客户可以承受的停机时间。消除对您的客户来说太贵或太慢的选择。
选择灾难恢复解决方案后，请确保您实践了它。我建议至少每年一次，或者每当您的体系结构发生更改时，无论发生频率如何，都建议这样做。
业务连续性的意义远不止于确保您可以访问可读备份。但是，将答案的范围仅限于此，最终只有从数据中心到备份位置的端到端带宽足够大以处理数据更改量时才可行。
当您谈论数据中心时，对于大多数人而言，这就是每周数据的千兆字节。
IME，即使规模很小，最好的解决方案还是分布式（或镜像）操作。正确地计划它，并且与单个数据中心相比，成本开销应该很小。
但是，如果您必须将所有数据复制到备用位置，甚至只是复制到远程存储，则
1）不要使用FTP-出于多种原因，这是错误的做法
2）对于通用文件，请使用针对此目的而优化的rsync之类的东西
3）对于数据库，请查看专门为您的DBMS提供的工具-文件结构可以大量更改，而数据不会发生很大变化。注意，这包括MSWindows注册表和MSAD数据。
在这里和其他地方，有关如何处理某种备份方案的细节已引起关注。我将从通用准则的更高层次上解决这个问题，以帮助您决定如何进行灾难恢复。我曾在很多情况下必须制定计划，以防数据中心成为吸烟者。幸运的是，我们只需要使用一次。要记住的最重要的事情是：
1）不要浪费时间尝试过度设计，如果不需要的话，可以使所有故障以小于1ms的精度进行故障转移。如此严重的完全故障通常会占用数小时的恢复时间。
2）作为＃1的推论，请确保现实中确定了期望并在某处的策略中将其编码。设定目标以达到恢复时间非常重要，因为您可以花费无限的时间，而资金筹集“甚至更好”。
3）确定系统优先级。恢复计划需要围绕每个系统重要性的确定清单来构建。也不要错过显而易见的事情，例如在其余Windows服务器之前启动DNS和AD。
4）如果它不是非现场和非网络的，那只是一个副本。这正好符合要记住的另一个关键事项：RAID不是备份计划。
5）测试，测试，测试！测试您计划的每一寸。如果您能够在维护期间享受周末的休假，请断开上行链路和/或建筑物的电源，并测试团队的反应时间和有效性。从未经过测试的灾难恢复计划只是一厢情愿。