ruby-on-rails - 如何准备生产网站中的数据丢失？

Question

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

虽然我认为上述情况不太可能发生，但如果它真的发生，我会因为没有做好准备而失职。

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

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

我将如何恢复 .dump文件以备不时之需？如果系统的一小部分被击中，我可以进行选择性还原吗？

如果无法进行选择性还原:假设一张表在上次备份后 4 小时丢失数据。结果 => 修复丢失的表是否需要回滚 4 小时的用户事件？有什么好的解决办法吗？

如果发生这种情况，为用户提供支持的最佳方式是什么？

Answer 1

完整的 DR(灾难恢复)解决方案需要以下内容:

多站点。如果火灾、洪水、奥萨马·本·拉登或其他什么东西袭击了 Heroku 使用的亚马逊(或者是 Salesforce？)数据中心，您希望确保您的数据在其他地方是安全的。

持续将数据复制到单独的站点(或多个站点)。这意味着写入一个站点上的数据库的每个事务都会在几秒钟内复制到另一个站点上的镜像数据库。大多数 RDBMS 都有机制让你像这样进行主从复制。

放在数据库之外的文件系统上的任何内容也是如此，例如图像、XML 配置文件等。 S3 在这里是一个很好的解决方案 - 它们为您将所有内容复制到多个数据中心。

我不会伤害创建数据库的定期(每天左右)转储并将它们分开存储(例如在 S3 上)。这有助于您从传播到从属 DB 的数据损坏中恢复。

自动化数据恢复过程。您希望它在需要时才起作用。

测试一切。理想情况下，您希望自动化测试过程并定期运行它以确保您的备份可以恢复。 Netflix Chaos Monkey是一个极端的例子。

我不确定你会如何在 Heroku 上实现所有这些。对于大多数公司来说，一套完整的解决方案的价格仍然遥不可及——我们在我们自己的数据中心(一个在美国，一个在欧盟)上运行它，并且它花费了数百万美元。根据 80-20 规则工作 - 持续备份到单独的站点，加上经过充分测试的恢复计划(不断测试您从备份中恢复的能力)涵盖了您需要的 80%。

对于支持用户来说，最好的解决办法就是在遇到问题时及时、真实地沟通，确保不丢失任何数据。如果您的用户为您的服务付费(即您没有广告支持)，那么您可能应该制定 SLA。