如何为生产网站中的数据丢失做好准备？答案

【问题标题】：How to prepare for data loss in a production website?如何为生产网站中的数据丢失做好准备？
【发布时间】：2011-08-22 15:41:26
【问题描述】：

我正在构建一个正在快速投入生产的应用程序，我担心由于黑客攻击、一些愚蠢的个人错误（如运行 rake db:schema:load 或 rake db:rollback）或其他情况，我们可能会遭受数据丢失一个数据库表，甚至整个系统。

虽然我认为上述情况不太可能会发生，但我没有做好准备以防万一。

我正在使用 Heroku 的 PG Backups（本月将替换为其他东西），并且我还运行自动每日备份到 S3：http://trevorturk.com/2010/04/14/automated-heroku-backups/，成功生成 .dump 文件。

在生产应用中处理数据丢失的正确方法是什么？

如果需要，我将如何恢复.dump 文件？如果系统的一小部分被击中，我可以进行选择性恢复吗？
如果无法进行选择性恢复：假设一个表在上次备份 4 小时后丢失数据。结果 => 修复丢失的表是否需要回滚 4 小时的用户活动？有什么好的解决办法吗？
如果发生这种情况，在给用户带来的不便中提供支持的最佳方式是什么？

【问题讨论】：

如果您还没有已经恢复备份（在非生产设备上），那么您就没有备份。
@CraigStuntz - 你的意思是说定期将备份恢复到某种“影子”网站很重要吗？或者你的意思是在本地恢复它们？如果用户只访问 mysite.com，这样做的目的是什么？
这样做的目的是备份工具可以很容易地生成在非平凡安装中实际上无法恢复的文件。只有当它们实际上可以用于生成工作服务器时，备份才是好的。
@CraigStuntz - S3 上的 .dump 文件不能算作能够生成工作服务器吗？
做备份的重点不是“做备份”。进行备份的目的是能够从备份中恢复。 IT 历史上充斥着无法使用的备份、副本和转储的故事。不要成为 Daily WTF 的下一个条目 (thedailywtf.com)

标签： ruby-on-rails ruby-on-rails-3 heroku backup data-loss

【解决方案1】：

关于备份，您无法确保每次都 100% 不会丢失任何数据。最好是在另一台服务器上测试它。您必须至少有两种类型的备份：

数据库备份，如 pg-dump。转储是唯一的 SQL 命令，因此您可以使用它来重新创建整个数据库、一个表或几行。您会丢失同时添加的数据。
代码备份，例如 git 存储库。

【讨论】：

我有一个 git 存储库和通过 Heroku 的常规 pg-dumps。看起来我正在通过最初的障碍？ :)

【解决方案2】：

除了Hartator的回答：

如果您的数据库提供复制功能，请使用复制功能，例如至少有一个从属的主/从复制
在从属数据库服务器上进行数据库备份并将它们存储在外部（例如 scp 或 rsync 将它们从您的服务器中取出）
为您的源代码使用良好的版本控制系统，例如吉特
使用可靠的部署机制，例如 Capistrano 并编写您的自定义任务，因此没有人需要手动进行数据库迁移
让您信任的人检查您的防火墙设置和系统的总体安全性

DB-Dump 包含用于重新创建所有表和所有数据的 SQL 命令...如果您只恢复一个表，您可以从转储文件的副本中提取该部分并（非常小心地）编辑它并然后用修改后的转储文件恢复（一个表）。

始终首先恢复到独立的机器并检查数据是否正确。例如您可以使用一台从服务器，如果脱机，然后在本地恢复并检查数据。如果您的系统中有两个从站，那么当您恢复到第二个从站时，其余系统仍然有一个主站和一个从站。

【讨论】：

你知道Heroku的主从关系是如何工作的吗？非常感谢您的回答。我很难确定哪些适用于我，哪些 Heroku 已经处理好了。

【解决方案3】：

完整的 DR（灾难恢复）解决方案需要以下内容：

多站点。如果火灾、洪水、奥萨马·本·拉登或其他什么袭击了 Heroku 使用的 Amazon（或者是 Salesforce？）数据中心，您需要确保您的数据在其他地方是安全的。
将数据持续复制到单独的站点（或多个站点）。这意味着在一个站点上写入您的数据库的每个事务都会在几秒钟内复制到另一个站点上的镜像数据库。大多数 RDBMS 都有机制让您进行这样的主从复制。
这同样适用于您放在数据库之外的文件系统中的任何内容，例如图像、XML 配置文件等。S3 在这里是一个很好的解决方案 - 它们会为您将所有内容复制到多个数据中心。
创建定期（每天左右）的数据库转储并将它们分开存储（例如在 S3 上）不会有什么坏处。这有助于您从传播到从数据库的数据损坏中恢复。
自动化数据恢复过程。您希望它只在您需要时发挥作用。
测试一切。理想情况下，您希望自动化测试过程并定期运行它以确保您的备份可以恢复。 Netflix Chaos Monkey 就是一个极端的例子。

我不确定您将如何在 Heroku 上实现所有这些。对于大多数公司来说，一个完整的解决方案的价格仍然遥不可及——我们在我们自己的数据中心（一个在美国，一个在欧盟）运行它，而且成本高达数百万。根据 80-20 规则工作 - 持续备份到单独的站点，加上经过良好测试的恢复计划（不断测试您从备份中恢复的能力）涵盖 80% 的需求。

对于支持用户，最好的解决方案就是在遇到问题时及时、如实沟通，确保您不会丢失任何数据。如果您的用户为您的服务付费（即您不受广告支持），那么您可能应该制定 SLA。

【讨论】：

非常感谢这个详细的回答；我特别喜欢 Netflix Chaos Monkey 参考！我正在经营一家小型初创公司，因此资源很少，并且尽管有限制，但我希望尽我们所能做好工作。我正在尝试了解如何使用 Heroku 建立一个非常有弹性的系统，该系统本身在 Amazon 上运行。到目前为止，我们已经处理了 1、3 和 4。
@sscirrus 我了解 - 不久前我自己经营过一家小型创业公司。我认为你的下一步应该是#5，然后#6 变得轻而易举。无论如何，创业公司失败的方式有很多，而数据丢失几乎不是最常见的，所以我会优先考虑构建能够产生足够价值以值得保护的东西:)

【解决方案4】：

要在 Heroku 上模拟一个相当简单的“全面灾难恢复”，请创建另一个 Heroku 项目并完全复制您的生产应用程序（使用不同的自定义域名除外）。

您可以将多个远程 git 目标添加到单个 git 存储库，以便您可以使用当前的生产代码库。您可以将数据库备份推送到复制的项目中，然后就可以开始了。

本练习与真正的灾难恢复相比，唯一缺少的步骤是将您的生产域分配给复制的 Heroku 项目。

如果您负担得起并行运行应用程序的两个副本，则可以自动执行此练习，并根据您的数据丢失容忍度让它定期（例如每小时、每天）自我复制。

【讨论】：