上周末，弗吉尼亚州遭遇了严重的风暴，当然，日本的危机也提醒我们，情况可能在一瞬间恶化！我问自己一个问题：“如果龙卷风袭击我的数据中心，我准备好了吗？”
我的机架中拥有出色的备份系统，包括磁带备份。由于数据中心不近，因此无法将磁带移出现场。我想找到或创建一个可以按计划备份关键项目（例如网站、数据库）并远程复制它们的系统，即我家里的服务器。我有 35 mbit 服务的 FIOS，所以我有宽带，我需要的是执行此操作的“系统”。我是一名程序员，所以我可以创建一些可以按计划通过 FTP 下载信息的东西，但我很好奇现在是否有可以满足此远程备份需求的东西？我的 SQL Server 已备份到存储阵列，我可以将这些备份下载下来，甚至可以安排我的 SQL Server 在这里按计划与生产服务器同步。我使用 Windows Server 2008 R2 和 SQL Server 2008 R2。
在发生自然灾害导致数据中心瘫痪等危机时，你们对异地策略有何建议？你们准备好了吗？我希望其他人也能问自己这个问题，并从我们经常看到的这些自然灾害中吸取教训。
答案1
您的选择应由您与客户签订的服务水平协议决定，并受您的预算限制。
至少，您应该对所有关键数据进行异地备份。也就是说，任何您无法从头开始重建的数据都需要存储在其他地方。离线备份更好：当龙卷风来袭时，在线备份或复制可能会有所帮助，但是如果您有愤怒的员工删除数据库或破坏文件系统，会发生什么？
从离线备份的基础开始，您可以开始探索以更高的成本换取更快恢复速度的选项。这里有大量的选项，从您描述的用于在线备份的单个主机一直到完全复制的环境，其中同步数据复制运行主动（-主动）+，以实现几乎零停机时间。
如果您将数据与基础架构尽可能整齐地分开，您会发现从头恢复会容易得多。例如，如果您使用 puppet 或 chef 等系统而不是手动部署，从头恢复会快得多。如果您可以尽可能地实现自动化，那么重新做您在构建系统方面投入的所有工作将快得多。将数据分开还可以减少您需要备份的数据量：如果您只需要几兆的系统配置和应用程序数据，就不要剥离几千兆字节的操作系统。
这些选项可能会非常昂贵，因此您需要确定您的公司愿意在灾难恢复上花费多少钱以及您的客户可以容忍多少停机时间。排除那些对您的客户来说太贵或太慢的选项。
一旦选择了灾难恢复解决方案，一定要加以实践。我建议至少每年一次，或者每当您的架构发生变化时，以发生频率较高者为准。
答案2
业务连续性的意义远远不止确保你能够访问可读备份。但如果将答案的范围限制在这一点上，最终它只有在以下情况下才是可行的：端到端从数据中心到备份位置的带宽足够大，可以处理大量的数据变化。
当你谈论数据中心时，对于大多数人来说，这意味着每周会产生数 GB 的数据。
IME，即使是小规模，最好的解决方案也是分布式（或镜像）操作。规划得当，与单个数据中心相比，成本开销应该很小。
但如果你必须将所有数据复制到备用位置，甚至只是复制到远程存储，那么
1）不要使用 FTP——出于很多原因，它都是错误的方法
2）对于通用文件，使用针对此目的而优化的 rsync 之类的工具
3) 对于数据库，请查看专门用于 DBMS 的工具 - 文件结构可以发生巨大变化而数据不会发生很大变化。注意：这包括 MSWindows 注册表和 MSAD 数据。
答案3
我们从办公室到异地数据中心有 VPN。在异地数据中心，我们的服务器安装了网络共享，我们在备份软件（我们运行 Symantec BackupExec）中将其配置为目标，即 \OFFSITEDATACENTER\OFFSITESTORAGE
然后我们会在周末对这个位置进行一次完整备份
，每晚进行一次增量备份
以及我们正常的“现场”备份
我们还运行 VMWare VDR 来每周拍摄我们主服务器的图像，并将其放在使用 FreeOTFE 加密的 2TB SATA 磁盘上，我每周都会将其带回家。
答案4
处理某种备份方案的细节在这里和其他地方已经讲得够多了。我将从一般准则的更高层次的角度来探讨这个问题，以帮助您决定如何处理灾难恢复。我遇到过很多这样的情况，必须做好计划，以防数据中心变成一个冒烟的火山口。谢天谢地，我们只需要用一次。要记住的最重要的事情是：
1) 如果没有必要，不要浪费时间尝试过度设计，让所有故障转移的精度小于 1ms。这种程度的完全故障通常可以免除几个小时的恢复时间。
2) 作为第 1 点的推论，确保期望值是现实确定的，并编码在某项政策中。就恢复时间而言，设定一个目标很重要，因为你可以花费无限的时间和资金来让事情“变得更好”。
3) 确定系统的优先级。恢复计划需要围绕每个系统的重要性的明确列表来制定。也不要忽略显而易见的事情，例如在其余 Windows 服务器之前启动 DNS 和 AD。
4) 如果不是异地且不在网络之外，则只是一份副本。这与另一件需要记住的关键事情完全一致：RAID 不是备份计划。
5) 测试，测试，测试！尽可能测试计划的每一个细节。如果您能在周末休息一段时间进行维护，请断开上行链路和/或建筑物电源，并测试您的团队的反应时间和效率。未经测试的灾难恢复计划只是一厢情愿的想法。