计划灾难

我在一家小型营销公司工作，该公司也从事网页设计和开发。我们将所有网站设计和开发客户托管在Hostgator的专用服务器上。我们有一台配置了RAID 1硬盘的专用服务器。我们还执行每周备份，该备份通过cPanel自动执行，并由本地的自动FTP软件下载。

今天我们正在讨论如果Hostgator发生某种灾难性的失败该怎么办。可能是服务器爆炸，Hostgator遇到了严重的网络问题，FBI进行了一次著名的“夺走我们看到的每台服务器”突击行动等。然后，我们将其带入了一个新的层次，想知道如果Hostgator发生了长时间的停机并且我们无法访问本地备份，该怎么办。这可能是由于火灾，洪灾等引起的。我知道服务器长时间处于关闭状态并且无法同时访问本地文件的可能性很小，但仅需两个坏事要发生，这就是我们要坚持的立场。（如果您曾经a过气，发现备用轮胎已漏气或丢失，您就会知道同时发生两件坏事是多么容易）。

不用说，我们希望为“最坏情况”类型的事件做好准备，因为这几乎肯定会使我们破产。所以我的两个问题是：

1. 我们应该怎么做才能为Hostgator的长时间停机做好准备？理想的情况是让我们的客户的网站，以及希望的电子邮件快速启动并重新运行。

2. 健壮的备份计划将包括哪些内容，使重要数据永不丢失？理想的解决方案将是自动化的。

您可以假设成本不是答案中的问题，但是解决方案的价格越便宜越好。

我建议你：

1. 将主服务器的全部内容和配置自动镜像到另一个数据中心中完全独立的网络上的辅助备份服务器。使用RSync，FXP，cPanel伏都教或您希望自动同步的任何方法。

2. 如果Hostgator服务器无响应，则使用DNS故障转移切换将流量自动路由到备份服务器。

这意味着，如果发生最坏的情况，您将一直有一个“热”备份等待着去，而不是一个“冷”备份需要手动干预，并且四处乱跑和恐慌。这也意味着您的客户将永远不会知道自己的网站在您关闭之前就关闭了，这可能使每个人都很痛苦。

您可以使用诸如DNS Made Easy之类的提供程序来设置故障转移DNS 。对于您托管的每个域，您最多可以设置五个备份IP地址，每个备份服务器一个。一旦完成...

1. DNS Made Easy会每隔两到四分钟检查一次主服务器，如果未检测到响应，则会将流量路由到次要IP地址。

2. DNS Made Easy继续检查主服务器。当出现问题时，它将把流量重新路由到第一台服务器，或者（如果您愿意）将其保留在备份上，同时您可以诊断出问题并修复主服务器。

当然，此解决方案会增加您的运营成本，您必须以某种方式将此成本转嫁给客户，但是-如果您所在的行业因宕机而使您无法工作，那么花很多钱购买冗余服务器可能是值得的一次它挽救了公司。

除此之外：

重复，重复，重复

您拥有的独立备份越多越好。我将远程备份存储在本地硬盘上，该本地硬盘已镜像到外部硬盘，Dropbox，git存储库和远程FTP帐户。别冒险了 尽可能重复。如果必须从手动备份中还原，最好选择五个而不是选择一个。偏执狂被低估了。

练习手动还原备份

如果您从未尝试过从其中一个备份中恢复，那么您如何知道它们的作用呢？值得进行紧急演习，以了解如果自动化程序失败，将会发生什么情况。

• Cloudflare，提供安全性和缓存功能，可在服务器故障时保持站点正常运行。（他们镜像您的站点，并从其全局分布式缓存而不是直接从您的服务器提供它。）
• Codeguard，可提供网站代码的自动备份和回滚（仅FTP）。
• Site Auto Backup，通过cPanel备份提供自动备份和网站代码，电子邮件数据和MySQL信息的回滚。请注意，这是由Hostgator运行的，因此，如果您也与他们一起托管网站，则不一定合适，但可能会对其他人有所帮助。

特别是Cloudflare看起来对于避免停机和总体上提高站点响应能力很有用。

灾难恢复可能是一项艰巨的任务，尤其是在处理多个服务器，站点和数据库时。选择的解决方案要考虑的两个关键项目是恢复时间目标（RTO）和恢复点目标（RPO）。

RTO本质上是对站点备份之前需要多长时间的期望。如果您的RTO为一分钟或两分钟（或更短），那么您应该考虑一种与尼克建议的解决方案一致的解决方案，其中涉及将文件和数据实时复制到辅助数据中心以及DNS的自动故障转移。使用付费服务或两个数据中心的硬件（例如BIG-IP Global Traffic Manager）来完成来自F5 Networks。这可能会付出高昂的代价，但在很大程度上取决于回答以下问题：“停机的成本是多少？” 如果您的RTO是几个小时甚至几天，那么您可以考虑灾难恢复过程，该过程可能涉及更多的手动操作，例如使服务器联机，切换DNS等。乏味，但如果RTO允许这样做，则肯定具有成本效益。

RPO基本上是完成备份的频率以及在灾难情况下您愿意丢失多少数据。如果内容和/或数据的更改频繁发生，则您的RPO可能只有几分钟或几小时，并且可能正在处理实时复制或高频备份。如果内容的更改不那么频繁，或者您的客户不一定关心几天的数据丢失，那么备份的发生频率就会降低。

正如我提到的，我同意尼克所说的大部分内容。您可能希望考虑的另一种选择是利用来自较大的基于云的提供商之一（例如Rackspace或Amazon）的基于云的服务。尤其是这两家提供商都拥有庞大的基础架构，能够处理几乎所有的灾难。使用云站点或云服务器（Rackspace使用的术语）之类的东西，您可以同时进行扩展，而不必担心其物理硬件方面的优势。

Rackspace还提供了自定义选项，您可以在其中混合基础架构，并将云服务器，物理服务器和云文件作为解决方案的一部分。如果您不想采用一种适合所有情况的方法，则可以根据您的客户需求考虑使用混合方法。

如果有帮助，Rackspace站点上也有一个专门用于灾难恢复的页面，也可以在此处找到。（另外，根据记录，我不隶属于Rackspace，但过去曾使用过他们的服务）。

希望这有所帮助。

编辑：认为如果您正在评估云解决方案，这可能会有所帮助。有关基础设施以及服务和网络托管的Gartner魔力象限报告可以使您对其他解决方案提供商有所了解。

在另一家托管公司的另一家工厂完全复制服务器似乎是最明显的解决方案。

可以使用rsync和unison等工具使文件保持同步。SQL备份也可以同步，然后通过脚本上传到从数据库。

确保您正在使用源代码存储库（SVN或GIT）运行所有代码的版本控制。您使用的是SVN还是GIT？

您可以在第三方存储库（例如Project Locker）上获得一个帐户（免费或付费），如果您在工作时对所有代码进行版本控制，则基本上所有内容都将备份到位于第三位置的存储库中。 。从而进一步减少您一次失去所有工作的机会（几乎为零）。

您可以通过命令行或诸如Versions（对于Mac）或TortoiseSVN（对于Windows）之类的客户端来执行SVN提交/签出。