webappsの健全なバックアップ戦略

Question

webappを実行していますが、バックアップ計画が必要です。ここに私がこれまでに得たものがあります：

• 夜間に暗号化されたSQLデータベースのAmazon S3および外部ドライブへのバックアップ（可能であれば増分、PostgreSQLにあまり慣れていないが、それは別のスレッドです）
• Mercurialリポジトリ（Apache構成、デプロイスクリプトなどを含む）のS3への夜間バックアップ（Time Machine経由のローカルバックアップ付き）

他に何か追加する必要がありますか、またはこれでカバーされますか？データの重要性/重要性の尺度としては、Basecampに沿ったプロジェクト管理アプリです。

Answer 1

データベースの1週間ごとの完全バックアップと、1週間ごとの増分バックアップも可能ですか？

古い増分バックアップのいずれかが破損した場合、1週間未満のデータが失われたことを意味します。

また、バックアップが機能することを確認するためのバックアップテスト計画があることを確認します。これについては、何年もバックアップを行っていて、決してテストせずに、必要なときにそれらのどれも役に立たないことを発見した企業から、多くの恐ろしい話があります。 （私もこのような会社にいました。ありがたいことに、バックアップが必要になる前にバックアップが機能していなかったことを発見し、問題を修正しました。）

Answer 2

過去に私にとって有効だった最善の戦略の1つは、「バックアップ」プロセスはインストールプロセスと同じです。つまり、Linuxでサーバー構成、アプリケーションの作成、データベースのセットアップなどを完全にスクリプト化したため、インストールは次のようになります。

./ install.sh [サーバー] [アプリケーション名] およびバックアップ/リカバリ ./install [サーバー] [アプリケーション名] -database [データベースバックアップファイル]

バックアップに関しては、cronjobによってデータベースが完全にバックアップされました（MySQLデータベース）

これにより、新しいインスタンスがデプロイされるたびにリカバリがテストされ、ハードウェアの交換が必要な場合や特定のサーバーが顧客からの負荷が大きすぎる場合に、スクリプトがインスタンスの移動にも使用されました。 。

これは数年前に作業したSaasエンタープライズアプリケーションのセットアップであったため、サーバーを完全に制御できました。

Answer 3

増分バックアップから差分に変更できると思います。増分がある場合は、毎週完全バックアップを適用し、それ以降のすべての増分バックアップを適用する必要があります。増分バックアップの1つが週の初めに失敗すると、その後のすべてのバックアップも失敗します。

ただし、差分を使用する場合、各差分には最後のバックアップ以降のすべての変更が含まれます。そのため、週の初めにバックアップの1つが失敗した場合でも、最近のバックアップが正常に完了していれば、完全に回復することができます。

これをうまく説明できたらと思います！

：）