我正在构建一个快速投入生产的应用程序，我担心由于黑客攻击，一些愚蠢的个人错误（如运行rake db:schema:load或rake db:rollback）或其他情况，我们可能会在一个数据库表甚至整个系统中遭受数据丢失。
虽然我认为上述情况不太可能发生，但我没有做好准备以防万一。
我正在使用 Heroku 的 PG 备份（本月将替换为其他备份），并且我还运行自动每日备份到 S3：http://trevorturk.com/2010/04/14/automated-heroku-backups/，成功生成.dump文件。
处理生产应用程序数据丢失的正确方法是什么？
- 如果需要，我将如何恢复
.dump文件？如果系统的一小部分被击中，我可以执行选择性还原吗？ - 如果无法进行选择性还原：假设一个表在上次备份 4 小时后丢失数据。结果 =>修复丢失的表是否需要回滚 4 小时的用户活动？有什么好的解决方案吗？
- 如果发生这样的事情，支持用户度过不便的最佳方式是什么？
完整的灾难恢复（灾难恢复）解决方案需要满足以下条件：
- 多站点。如果火灾、洪水、奥萨马·本·拉登或其他什么袭击了 Heroku 使用的亚马逊（或者是 Salesforce？）数据中心，您希望确保您的数据在其他地方是安全的。
- 将数据持续复制到单独的一个或多个站点。这意味着写入一个站点上的数据库的每个事务都会在几秒钟内复制到另一个站点上的镜像数据库。大多数RDBMS都有机制让你做这样的主从复制。
- S3 是一个很好的解决方案 - 它们为您复制所有内容到多个数据中心。
- 创建数据库的定期（每日左右）转储并将它们单独存储（例如在 S3 上）不会有什么坏处。这有助于您从传播到从属数据库的数据损坏中恢复。
- 自动化数据恢复过程。您希望它在需要时工作。
- 测试一切。理想情况下，您希望自动执行测试过程并定期运行它，以确保备份可以还原。Netflix Chaos Monkey就是一个极端的例子。
我不确定您将如何在 Heroku 上实现所有这些。对于大多数公司来说，一个完整的解决方案的价格仍然遥不可及 - 我们正在自己的数据中心（一个在美国，一个在欧盟）上运行它，花费数百万美元。按照 80-20 规则工作 - 持续备份到单独的站点，加上经过良好测试的恢复计划（持续测试从备份中恢复的能力）涵盖您所需内容的 80%。
至于支持用户，最好的解决方案就是在出现问题时及时、真实地沟通，并确保不会丢失任何数据。如果您的用户为您的服务付费（即您不受广告支持），那么您可能应该制定 SLA。
关于备份，您不能每次都 100% 地确定不会丢失任何数据。最好是在另一台服务器上测试它。您必须拥有两种类型的备份：
-
数据库备份，如 pg-dump。转储是唯一的 SQL 命令，因此您可以使用它重新创建整个数据库、仅一个表或仅重新创建几行。您在此期间会丢失添加的数据。
-
代码备份，例如 git 存储库。
除了Hartator的回答：
-
如果您的数据库提供复制，请使用复制，例如，至少使用一个从站进行主/从复制
-
在从属数据库服务器上进行数据库备份并将它们存储在外部（例如，SCP或rsync将它们存储在服务器之外）
-
为您的源代码使用良好的版本控制系统，例如 Git
-
使用可靠的部署机制（如 Capistrano）并编写自定义任务，因此没有人需要手动进行数据库迁移
-
让您信任的人检查您的防火墙设置和系统的安全性
数据库转储包含用于重新创建所有表和所有数据的 SQL 命令...如果只还原一个表，则可以从转储文件的副本中提取该部分并（非常小心地）对其进行编辑，然后使用修改后的转储文件（对于一个表）进行还原。
始终首先还原到独立的计算机并检查数据是否看起来正确。 例如，您可以使用一个从属服务器，如果脱机则使用，然后在本地还原并检查数据。 如果您的系统中有两个从站，那么当您恢复到第二个从站时，剩余的系统仍然有一个主站和一个从站。
上模拟相当简单的"全面灾难恢复"，请创建另一个 Heroku 项目并完全复制您的生产应用程序（除了使用不同的自定义域名）。
您可以将多个远程 git 目标添加到单个 git 存储库，以便可以使用当前的生产代码库。您可以将数据库备份推送到复制的项目，然后就可以开始了。
与真正的灾难恢复相比，本练习中唯一缺少的步骤是将生产域分配给复制的 Heroku 项目。
如果您有能力并行运行应用程序的两个副本，则可以自动执行此练习，并根据您的数据丢失容限定期（例如每小时、每天）对其进行自我复制。