今天我们正在讨论如果Hostgator发生某种灾难性的故障该怎么办。可能是服务器爆炸，Hostgator遇到了严重的网络问题，FBI进行了一次著名的“夺走我们看到的每台服务器”突击行动等。然后，我们将它带入了一个新的层次，想知道如果Hostgator发生了长时间的停机，而我们又无法访问本地备份，该怎么办。这可能是由于火灾，洪水等引起的。我知道服务器长时间处于关闭状态并且无法同时访问本地文件的可能性很小，但这仅是两个不好的事情发生，这就是我们要解决的问题会站起来。 （如果您曾经a过气，发现备用轮胎已漏气或丢失，您就会知道同时发生两件事很容易。）
不用说我们想成为为“最坏的情况”类型的事件做准备，因为这几乎肯定会使我们破产。因此，我的两个问题是：
Hostgator应对长期停机作准备？理想的情况是让我们的客户的网站以及电子邮件迅速启动并重新运行。
健壮的备份计划将包括哪些内容，使重要数据永不丢失？理想的解决方案将实现自动化。
您可以假设成本不是问题所在，但解决方案越实惠，就越好。
#1 楼
我建议您：自动将主服务器的全部内容和配置镜像到另一个数据中心中完全独立的网络上的辅助备份服务器。使用RSync，FXP，cPanel伏都教或您希望自动同步的任何方法。
如果Hostgator服务器无响应，则使用DNS故障转移切换将流量自动路由到备份服务器。
这意味着这样，即使在最坏的情况下，您总是有一个“热”备份等待着去，而不是一个“冷”备份需要手动干预，并且四处乱跑和恐慌。这也意味着您的客户将永远不会知道自己的站点在您崩溃之前就崩溃了，这可能使每个人都很痛苦。
您可以使用诸如DNS Made Easy之类的提供商来设置故障转移DNS。对于您托管的每个域，您最多可以设置五个备份IP地址，每个备份服务器一个。完成此操作后...
DNS Made Easy会每两到四分钟检查一次主服务器，如果未检测到响应，它将把流量路由到次要IP地址。
DNS Made Easy继续检查主服务器。当出现问题时，它将把流量重新路由到第一台服务器，或者（如果您愿意）将其保留在备份上，同时诊断出问题所在并修复主服务器。
当然，此解决方案会增加您的运营成本，您必须以某种方式将此成本转嫁给客户，但是-如果您所在行业的停机时间会使您破产，那么那一次为大型冗余服务器付费可能是值得的
除此之外：
重复，重复，重复
您拥有的独立备份越多越好。我将远程备份存储在本地硬盘上，该本地硬盘已镜像到外部硬盘，Dropbox，git存储库和远程FTP帐户。别冒险了尽可能重复。如果必须从手动备份中还原，最好选择五个而不是选择一个。偏执狂被低估了。
练习手动还原备份
如果您从未尝试从其中一个备份中恢复，怎么知道它们可以正常工作？值得进行紧急演练，看看如果您的自动化程序失败，将会发生什么。
更新：我最近发现的一些其他服务值得一提站点备份，灾难恢复和维护正常运行时间：
Cloudflare，Cloudflare提供安全性和缓存功能，可在服务器故障时保持站点正常运行。 （他们镜像您的站点，并从其全局分布式缓存而不是直接从您的服务器提供站点。）
Codeguard，它提供网站代码的自动备份和回滚（仅FTP）。
站点自动备份，可通过cPanel备份提供自动备份和网站代码，电子邮件数据和MySQL信息的回滚。请注意，这是由Hostgator运行的，因此，如果您也与他们一起托管网站，则不一定合适，但可能会对其他人有所帮助。
尤其是Cloudflare看起来对于避免停机和避免停机很有用。通常可以提高站点响应速度。
评论
我不知道像DNS这样容易存在的东西。这是在主服务器出现故障的情况下快速重新路由站点的好方法。
–John Conde♦
2011年7月14日在17:17
它们也非常适合一般DNS托管。我从我最喜欢的注册商那里购买域名，但是使用DNS Easy来托管DNS记录。它们在世界各地拥有多个名称服务器，因此站点解析速度快，首次加载速度更快，并且当注册服务商的名称服务器停顿时也不会崩溃。它也不是那么昂贵。
–尼克
2011年7月14日18:00
@Nick：这里不建议使用DNS故障转移（我认为您在DNS Made Easy中使用过的服务）：serverfault.com/questions/60553/…您如何看待？
– Marco Demaio
2011年7月20日在21:45
@Marco他们正确地指出这并不是万无一失的，但是对于我管理的几个小型Web应用程序来说，它非常适合我。
–尼克
11年7月21日在15:29
顺便说一下，Stack Exchange也使用DNS故障转移。主要数据中心位于New Yourk，次要位于俄勒冈州。 meta.stackexchange.com/a/231138/238706 meta.stackexchange.com/q/207653/238706
– Palec
2014年8月16日14:56
#2 楼
灾难恢复可能是一项艰巨的任务，尤其是在处理多个服务器，站点和数据库时。您选择的解决方案要考虑的两个关键项目是恢复时间目标（RTO）和恢复点目标（RPO）。RTO本质上是对直到站点恢复需要多长时间的期望备份。如果您的RTO为一分钟或两分钟（或更短），那么您应该考虑一种与尼克建议的解决方案一致的解决方案，其中涉及将文件和数据实时复制到辅助数据中心以及DNS的自动故障转移。可以使用付费服务或两个数据中心的硬件（例如F5 Networks的BIG-IP Global Traffic Manager）来完成。这可能会花费很大，但在很大程度上取决于回答“停机成本是多少？”这一问题。 RTO需要几个小时甚至几天，然后您可以考虑可能需要更多人工干预的灾难恢复过程，例如使服务器联机，切换DNS等。乏味，但如果RTO允许的话，肯定可以节省成本。
RPO基本上是完成备份的频率以及在发生灾难时您愿意丢失多少数据。如果频繁更改内容和/或数据，则您的RPO可能为可能是几分钟或几小时，可能是实时复制或高频备份。如果内容的更改不那么频繁，或者您的客户不一定关心几天的数据丢失，那么备份的发生频率就会降低。
正如我提到的，我同意尼克所说的大部分内容。您可能希望考虑的另一种选择是利用来自较大的基于云的提供商（例如Rackspace或Amazon）中的基于云的服务。尤其是这两个提供商都拥有庞大的基础架构，能够处理几乎所有的灾难。使用云站点或云服务器（Rackspace使用的术语）之类的东西，您可以同时进行扩展，而不必担心其物理硬件方面的优势。
Rackspace还提供了自定义选项，您可以在其中混合基础架构，并将云服务器，物理服务器和云文件作为解决方案的一部分。如果您不想采用一种适用于所有方法的混合方法，则可能需要根据客户的需求考虑采用混合方法。也可以在此处找到Rackspace网站。 （出于记录，我不隶属于Rackspace，但过去曾使用过他们的服务。）
希望这有所帮助。如果您正在评估云解决方案。有关基础设施以及服务和网络托管的Gartner魔力象限报告可以使您深入了解其他解决方案提供商。
评论
我什至从未考虑过将云托管用作备份“服务器”。这是准备快速进行备份的非常经济的方式。
–John Conde♦
2011年7月14日在17:20
#3 楼
在另一家托管公司的另一家工厂完全复制服务器似乎是最明显的解决方案。文件可以与rsync和unison之类的工具保持同步。
SQL备份也可以进行rsync和然后通过脚本将其上传到从数据库。
#4 楼
确保您正在使用源代码存储库（SVN或GIT）运行所有代码的版本控制。您使用的是SVN还是GIT？您可以在第三方存储库（例如Project Locker）中获得一个帐户（免费或付费），并且如果在工作时对所有代码进行版本控制，您已将所有备份到位于第三位置的存储库。从而进一步减少了一次丢失所有工作的机会（几乎为零）。
您可以通过命令行或诸如Versions（Mac）或TortoiseSVN之类的客户端执行SVN提交/签出（对于Windows）。
评论
源代码存储库的唯一问题是不会备份数据库或任何用户上传的文件等
– Daveo
2011年7月13日在23:21
真正。但是您可以创建数据库的转储文件并将其添加到存储库中。您甚至可以编写脚本以使该过程自动化。无论是否使用数据库，都至少要再备份一个代码和资产，并且无论如何，版本控制的主要好处是。
–乔尔·格洛维尔（Joel Glovier）
2011年7月14日在12:55
不幸的是，我们不使用版本控制。实际上，在我开始这里之前，所有工作都是在现场完成的！我能够在本地建立一个开发环境，因此至少实践被正式废除了。
–John Conde♦
2011年7月14日17:18
评论
似乎这里的答案已经涵盖了很多基础。我可以保证，到目前为止，Amazon云作为备份解决方案非常经济。不知道未来会怎样，但是如果没有别的，那是学习云如何运作的好方法。如果您还没有运行过，这是AWS的估算成本计算器：Calculator.s3.amazonaws.com/calc5.html
@John Conde：您在HostGator上有什么经验，有什么重大的停机时间吗？如果是，您还记得多长时间的主要停机时间？
@Marco Demaio，我们与Hostgator完全没有停机。他们一直非常可靠，他们的支持也很棒。