web应用程序的理智备份策略
我正在做一个web应用程序，需要一个备份计划。下面是我到目前为止有：web应用程序的理智备份策略
- 的SQL数据库，Amazon S3和我的外部驱动器的夜间加密的备份（增量如果可能的话，不是太熟悉的PostgreSQL还没有，但这是另一个线程）
- 夜间我的水银回购（包括阿帕奇CONFIGS，部署脚本等）到S3的备份（W通过Time Machine /本地备份）
我要补充别的，还是将盖呢？为了衡量这些数据的重要程度，它是Basecamp的项目管理应用程序。
数据库的每周完整备份以及每晚增量备份？
这意味着如果您的某个旧增量备份损坏，那么您的数据丢失时间不到一周。
此外，请确保您有备份测试计划以确保您的备份正常工作。有很多关于此事的恐怖故事，包括那些已经做了多年备份的公司，从来没有对它们进行测试，然后在需要它们时发现它们都不是很好。 （我也是这样的一家公司，幸运的是我发现备份在需要之前无法正常工作并解决了问题）。
过去为我工作的最佳策略之一是让“备份”过程与安装过程相同，即我们在linux中完全脚本化了服务器配置，应用程序创建，数据库设置等等所以安装看起来像：
运行./install.sh [服务器] [应用程序名称] 和备份/恢复 ./INSTALL [服务器] [应用程序名称] -database [数据库备份文件]
在备份方面，数据库完全备份（MySQL数据库），通过cronjob
这几乎可以确保在每次部署新实例时对恢复进行测试，并且在硬件需要更换时，或者当给定服务器从客户获得太多负载时，脚本也最终用于移动实例。
这是几年前我工作过的Saas企业应用程序的设置，所以我们完全控制了服务器。
我会，如果你可以从一个增量备份到一个差异。如果你有一个增量，那么你将不得不应用每周完整备份，然后每一次增量。如果您的某个增量在本周早些时候失败，则后续所有备份都将失败。
但是，如果您使用差分，则每个差分包含自上次备份以来的所有更改。所以即使其中一个备份在本周早些时候失败，如果最近备份成功，您仍然可以完全恢复。
我希望我解释得很好！
:)