如果龙卷风通过您的数据中心怎么办？

您的select应该由您的客户的服务水平协议决定，并受到预算的限制。

至less，您应该有所有关键数据的异地备份。 那到目前为止，您从头开始无法重新创build的任何数据都需要存储在别处。 离线备份更好：在龙卷风袭击时，联机备份或复制可能会有所帮助，但是如果您生气的员工丢弃数据库或销毁文件系统，会发生什么情况？

从脱机备份的基线，您可以开始探索选项，以加快恢复，以换取更高的成本。 这里有大量的选项，从用于在线备份的单个主机到完全复制的环境，在同步数据复制的同时运行主动（-active）+以获得接近零的停机时间。

如果将数据从基础架构尽可能地整齐分离，您会发现从头开始恢复要容易得多。 例如，如果使用puppet或chef而不是手工部署系统，从零开始恢复要快得多，速度要快得多。 如果可以尽可能自动化，那么重新构build系统所需的所有工作将会快得多。 保持数据分离还可以减less备份所需的数据量：如果只需要几兆系统configuration和应用程序数据，则不要分离千兆字节的操作系统。

选项可能会非常昂贵，所以您需要确定您的公司愿意花在灾难恢复上的费用以及您的客户可以容忍的停机时间。 消除对客户而言太贵或太慢的选项。

一旦你select了一个灾难恢复解决scheme，确保你练习它。 我build议至less每年一次或者每当你的架构发生变化时，以更经常发生的为准。

业务连续性远远超过只是确保您可以访问可读的备份。 但是将答案的范围局限于此，最终只有在数据中心到备份位置的端到端带宽足以处理数据变化量的情况下才是可行的。

当你在谈论一个数据中心时，那么对于大多数人来说，每周数据量是千兆字节。

即使是小规模的IME，最好的解决scheme也是分布式（或镜像）操作。 正确计划，与单个数据中心相比，应该有很less的成本开销。

但是，如果您必须将所有数据复制到备用位置，或者甚至只是将数据复制到远程存储，那么

1）不要使用FTP – 这只是由于许多原因而做错的方式

2）对于通用文件，使用像rsync这样的优化的目的

3）对于数据库，请查看专门为您的DBMS提供的工具 – 文件结构可以大量更改，而数据不会有太大变化。 注意这包括MSWindowsregistry和MSAD数据。

我们有从我们的办公室到我们的异地数据中心的VPN。 在异地数据中心，我们有装有networking共享的服务器，我们将其configuration为备份软件（我们运行Symantec BackupExec）的目的地，即\ OFFSITEDATACENTER \ OFFSITESTORAGE

然后，我们做 – 周末到那个位置的完整备份
– 每个晚上增量

以及我们正常的“现场”备份

我们还运行VMWare VDR，每周拍摄我们的主要服务器的图像，这些图像放在使用FreeOTFEencryption的2TB SATA磁盘上，我每周都会带回家。

我们有许多独立的主动/主动或主动/半主动数据中心，它们之间距离大于50英里，电源供应器不同，安全性差，10GBps之间的网状链路也不相同，哦，我们之间也有备份磁盘。 这为我们做。

处理某种备份scheme的细节已经在这里和其他地方引起讨论。 我将从更一般的指导方针的高层观点来处理这个问题，以帮助您决定如何处理灾难恢复。 我曾经在很多情况下需要制定计划，以防万一数据中心成为吸烟坑。 谢天谢地，我们只用了一次。 要记住的最重要的事情是：

1）不要浪费你的时间来尝试过度工程，如果你不需要，精确度小于1ms，就可以让所有事情都能顺利完成。 如果完全失败的话，通常会有几个小时的恢复。

2）作为＃1的必然结果，确保预期是真实的决定和编码在某个政策。 有一个既定的目标，以实现恢复时间很重要，因为你可以花费无限的时间和资金的制作“更好”。

3）优先考虑你的系统。 恢复计划需要围绕每个系统的重要性确定清单。 不要错过显而易见的事情，比如在其他Windows服务器之前获取DNS和AD。

4）如果它不在现场，并且不在networking上，那只是一个副本。 这与要记住的另一个关键事项是一致的：RAID不是备份计划。

5）testing，testing，testing！ testing你的计划的每一寸，你可以。 如果您能在维护周期内获得周末的价值，请断开上行链路和/或build筑物的电源，并testing您的团队的反应时间和效果。 从来没有testing过的灾难恢复计划只是一厢情愿的想法。