避免服务器灾难

担心您的服务器会崩溃？你应该。以下是一些针对服务器所有者的灾难规划技巧。

如果您拥有汽车或房屋，几乎可以肯定有保险。保险似乎是巨大的金钱浪费。您每年付款一次，并确保获得最优惠的价格以获得最佳的保险，然后希望您永远不需要使用该保险。保险似乎是一笔非常糟糕的交易，直到您遭受灾难并意识到如果没有保险，您可能会陷入财务危机。

不幸的是，灾难和不幸是计算机行业中不可或缺的事实。因此，正如您支付保险金并希望永远不必使用它一样，您还需要花一些时间来确保系统的安全性和可靠性-不是因为您希望灾难发生甚至是希望灾难发生，而是因为你必须。

如果您的网站是贵公司的在线手册，然后停顿了几个小时甚至几天，这会很尴尬和烦人，但不会造成财务上的痛苦。但是，如果您的网站是您的公司，那么当您的网站出现故障时，您就在赔钱。在这种情况下，至关重要的是确保服务器和软件不仅不会宕机，而且在发生这种情况时易于恢复。

我为什么要写这个主题？好吧，就让我说，在我开始写这篇文章之前，这个特殊的问题对我来说已经很严重了。经过多年帮助世界各地的客户确保系统可靠性的错误，我犯了一个错误，那就是我对自己的系统不那么了解。（俗话说“鞋匠的孩子赤脚走路”。）这意味着，在为Python开发人员推出我的新在线产品之后，看似微不足道的升级变成了一场灾难。事实证明，我所采取的预防措施还不够—在撰写本文时，我仍在将Web服务器组合在一起。我将生存，服务器和企业也将生存，但这是一个痛苦而重要的课程，我将尽一切努力避免将来再次发生。

因此，在本文中，我描述了我多年来使用的许多技术，这些技术可确保服务器安全可靠，并减少彻底崩溃的机会。您可以将这些技术视为服务器的保证，因此即使出现问题，您也可以相当快地恢复。

我应该注意，这里的大多数建议都假定您的体系结构中没有冗余-即单个Web服务器和（最多）单个数据库服务器。如果您有能力拥有一堆每种类型的服务器，则这类问题的发生频率将大大降低。但是，这并不意味着它们会完全消失。此外，尽管人们喜欢谈论需要大量资源才能运行的重型Web应用程序，但事实是，许多企业都在小型，一台和两台计算机的服务器上运行。而且，这些业务并不需要更多。他们从其他服务器获得的ROI（投资回报率）是不合理的。但是，良好的备份和恢复计划所带来的投资回报是巨大的，因此值得进行投资。

Web应用程序的各个部分

在讨论灾难准备和恢复之前，必须考虑Web应用程序的不同部分以及这些不同部分对您的计划意味着什么，这一点很重要。

多年以来，我的网站小而简单。即使其中包含一些简单的程序，这些程序通常也用于发送电子邮件或向访客动态显示不同的资产。整个站点由一些静态HTML，图像，JavaScript和CSS组成。无需数据库或其他刺激。

另一方面，许多人拥有成熟的Web应用程序，它们位于多台服务器上，具有一个或多个数据库和缓存，以及具有大量编辑的配置文件的HTTP服务器。

但是，即使考虑到这两个极端，您也可以看到一个Web应用程序仅由几部分组成：

• 应用程序软件本身。

• 该应用程序的静态资产。

• HTTP服务器的配置文件。

• 数据库配置文件。

• 数据库架构和内容。

假设您使用的是Python，Ruby或JavaScript之类的高级语言，则此列表中的所有内容都是文件，也可以变成一个文件。（所有数据库都可以将其内容“转储”到磁盘上，然后可以重新装入数据库服务器。）

考虑一个仅包含应用程序软件，静态资产和配置文件的站点。（换句话说，不涉及数据库。）在许多情况下，可以在Git中可靠地备份这样的站点。确实，我更喜欢将站点保留在Git中，并备份到商业托管服务（例如GitHub或Bitbucket）中，然后使用Capistrano之类的系统进行部署。

换句话说，您可以在自己的开发计算机上开发站点。只要您对所做的更改感到满意，就将更改提交到Git（在本地计算机上），然后git push对中央存储库执行a 。为了部署您的应用程序，然后使用Capistrano进行一个操作cap deploy，该操作从中央存储库读取数据，并将其放入服务器文件系统中的适当位置，您可以开始使用。

该系统以几种不同的方式使您安全。代码本身至少位于三个位置：开发机器，服务器和存储库。而且这些中央存储库往往相当可靠，即使仅仅是因为确保事物可靠符合托管公司的财务利益。

我应该补充一点，在这种情况下，您还应该在Git存储库中包括HTTP服务器的配置文件。这些文件不太可能经常更改，但是我可以从经验中告诉您，如果您正从危机中恢复过来，那么您要考虑的最后一件事是Apache配置文件的外观。将这些文件复制到您的Git存储库中就可以了。

备份资料库

您可能会争辩说“网站”和“ Web应用程序”之间的区别是数据库。长期以来，数据库为许多Web应用程序的后端提供了强大的动力，这有充分的理由-它们使您能够可靠，灵活地存储和检索数据。仅仅在一两年前，现代开源数据库所提供的功能是不可想象的，而且没有理由认为它们在将来会变得不那么可靠。

但是，仅仅因为您的数据库非常可靠，并不意味着它就不会有问题。这意味着您将需要保留数据库内容的快照（“转储”），以防数据库服务器破坏信息，并且需要回滚到以前的版本。

对于此类问题，我最喜欢的解决方案是定期（最好每小时）转储数据库。这是我使用过的一种shell脚本，以一种或另一种形式用于创建此类常规数据库转储：

#!/bin/shBACKUP_ROOT="/home/database-backups/"YEAR=`/bin/date +'%Y'`MONTH=`/bin/date +'%m'`DAY=`/bin/date +'%d'`DIRECTORY="$BACKUP_ROOT/$YEAR/$MONTH/$DAY"USERNAME=dbuserDATABASE=dbnameHOST=localhostPORT=3306/bin/mkdir -p $DIRECTORY/usr/bin/mysqldump -h $HOST --databases $DATABASE -u $USERNAME
 ↪| /bin/gzip --best --verbose >
 ↪$DIRECTORY/$DATABASE-dump.gz

上面的shell脚本通过定义一堆变量开始，从我要存储备份的目录到日期的各部分（存储在$ YEAR，$ MONTH和$ DAY中）。这样一来，我可以为每月的每一天创建一个单独的目录。当然，我可以走得更远，每个小时有一个单独的目录，但是我发现我每天很少需要多个备份。

一旦定义了这些变量，就可以使用该mkdir命令创建一个新目录。该-p选项 mkdir表明，如有必要，它将创建所需的所有目录，以使整个路径都存在。

最后，然后运行数据库的“转储”命令。在这种情况下，我使用的是MySQL，所以我使用的是 mysqldump 命令。此命令的输出是SQL的流，可用于重新创建数据库。因此，我从中获取输出 mysqldump并将其通过管道gzip传输到，从而压缩输出文件。最后，将生成的转储文件以压缩形式放置在每日备份目录中。

根据数据库的大小和手头上的磁盘空间量，您将不得不决定要多久运行一次转储以及多久清理一次旧的转储。我从经验中知道，每小时倾销会导致一些负载问题。在我使用的一个虚拟机上，整个管理团队对我每小时都进行转储和压缩感到不满，他们认为这是对系统资源的不必要使用。

如果您担心系统磁盘空间不足，则最好运行一个空间检查程序，当文件系统的可用空间不足时，该程序将向您发出警报。此外，您可以运行cron作业，该作业find用于擦除特定截止日期之前的所有转储文件。对于总是会自动删除备份的程序，我总是有些紧张，所以我通常不愿意这样做。相反，我运行的程序会警告我磁盘使用率是否超过85％（这通常足够低以确保我可以及时解决问题，即使我乘坐长途飞机也是如此）。然后，我可以手动删除有问题的文件。

备份数据库时，还应确保也备份该数据库的配置。作为转储文件一部分的数据库架构和数据当然很重要。但是，如果您发现必须从头开始重新创建服务器，则需要精确地了解如何配置数据库服务器，尤其要强调文件系统配置和内存分配。我倾向于在大多数工作中使用PostgreSQL，尽管postgresql.conf易于理解和配置，但我仍然喜欢将其与我的转储文件保持在一起。

另一项至关重要的事情是偶尔检查数据库转储，以确保它们按照您想要的方式工作。事实证明，我认为我所做的备份实际上并没有发生，这在很大程度上是因为我修改了shell脚本并且没有仔细检查过它正在创建有用的备份。偶尔拔出一个转储文件并将其还原到单独的数据库（并脱机！）以检查其完整性是一个好习惯，既可确保转储正常运行，又可确保您在紧急情况下还记得如何还原转储。

储存备份

可是等等。拥有这些备份可能很棒，但是如果服务器完全关闭该怎么办？对于代码，我提到要确保它位于多台计算机上，以确保其完整性。相比之下，您的数据库转储现在位于服务器上，因此，如果服务器发生故障，将无法访问数据库转储。

这意味着您希望将数据库转储存储在其他位置，最好是自动存储。你该怎么做？

有一些相对容易和便宜的解决方案来解决这个问题。如果您有两台服务器（理想情况下位于单独的物理位置），则可以用于rsync将文件从一台复制到另一台。不要rsync使用数据库的实际文件，因为这些文件在传输过程中可能会损坏，并且不能在服务器运行时进行复制。相比之下，您创建的转储文件远胜于其他地方。设置一个专门用于处理这些备份传输的用户的远程服务器应该不会太费力，并且将在确保数据安全方面大有帮助。

我应该注意，rsync以这种方式使用基本上要求您设置无密码的SSH，以便您无需亲自输入密码即可进行传输。

另一个可能的解决方案是Amazon的Simple Storage Server（S3），它以非常低的价格提供了惊人的磁盘空间。我知道许多公司都将S3用作简单（尽管很慢）的备份系统。您可以设置cron作业以运行将特定数据库转储文件目录的内容复制到特定服务器上的程序。这里的假设是您永远不会使用这些备份，这意味着一旦在服务器上工作，S3的慢速搜索和访问就不会成为问题。

同样，您可以考虑使用Dropbox。Dropbox以其桌面客户端而闻名，但是它具有一个“无头”基于文本的客户端，可以在不连接GUI的情况下在Linux服务器上使用。Dropbox的一个不错的优点是，您可以与任意数量的人共享一个文件夹，这意味着您可以让Dropbox自动将备份数据库分布到各处，包括分配给团队中的许多人。备份到达其Dropbox文件夹中，并且可以确定LAMP是有条件的。

最后，如果您运行的是WordPress网站，则可能需要考虑使用VaultPress（付费备份系统）。我必须承认，在由于数据库备份错误而关闭服务器的前几周，我一直在WordPress中为VaultPress看到广告。“问谁会买？”，我问自己，以为我很聪明可以自己做备份。当然，在发生灾难并且数据库被破坏之后，我意识到每年花费30美元来备份我的所有数据是很便宜的，而且我应该早先这样做。

结论

对于您的服务器，不要像乐观的程序员那样思考，而应该像保险代理人那样思考。也许灾难不会爆发，但是如果发生了，您是否能够恢复？确保即使服务器完全不可用，您也可以启动程序，并且任何关联的数据库都至关重要。

我的首选解决方案是将用于代码和配置文件的Git存储库组合在一起，这些存储在多个机器和服务中。但是，对于数据库而言，仅转储数据库是不够的。您需要将该转储保存到单独的计算机上，并且最好定期测试备份文件。这样，即使出现问题，您也可以立即恢复。