适用于webapps的理智备份策略

时间:2008-09-29 15:31:51

标签: backup web-applications

我正在做一个webapp并需要一个备份计划。这是我到目前为止所得到的:

  • 每晚将SQL数据库的备份加密到Amazon S3和我的外部驱动器(尽可能增量,但还不太熟悉PostgreSQL,但这是另一个线程)
  • 每晚备份我的Mercurial仓库(包括Apache配置,部署脚本等)到S3(通过Time Machine进行本地备份)

我应该添加其他内容,还是会覆盖它?为了衡量数据的重要性,它是一个沿着Basecamp的项目管理应用程序。

3 个答案:

答案 0 :(得分:3)

您的数据库的每周完整备份以及夜间增量备份也可能?

这意味着如果您的旧增量备份之一被破坏,那么您丢失的数据不到一周。

另外,请确保您有备份测试计划以确保备份正常运行。有很多关于此事的恐怖故事,从那些多年来一直在做备份的公司,从未对它们进行测试,然后发现它们一旦需要它们就没有任何好处。 (我也经常在这样的公司工作。幸好我发现备份在需要之前无法正常工作并修复了问题。)

答案 1 :(得分:1)

过去对我有用的最佳策略之一是让“备份”过程与安装过程完全相同,即我们在linux中完全编写了服务器配置,应用程序创建,数据库设置等等。所以安装看起来像:

./ install.sh [服务器] [应用程序名称] 和备份/恢复 ./install [server] [application name] -database [database backup file]

在备份方面,数据库已完全备份(MySQL数据库),由cronjob

备份

这几乎确保了每次部署新实例时都会对恢复进行测试,并且最终还会使用脚本在需要更换硬件时移动实例,或者当给定服务器从客户那里获得过多负载时

这是我几年前工作的Saas企业应用程序的设置,因此我们可以完全控制服务器。

答案 2 :(得分:0)

如果您可以从增量备份更改为差异,我会这样做。如果您有增量,则必须应用每周完整备份,然后应用每个增量备份。如果您的一个增量值在一周中提前失败,那么所有后续备份也将失败。

但是,如果使用差异,则每个差异包含自上次备份以来的所有更改。所以即使其中一个备份在本周早些时候失败了,如果你有一个成功的最近备份,你仍然可以完全恢复。

我希望我能解释清楚这一点!

:)