2

Web アプリケーションを実行していて、バックアップ プランが必要です。ここに私がこれまでに持っているものがあります:

  • Amazon S3 と私の外部ドライブへの SQL データベースの暗号化された毎晩のバックアップ (可能であれば増分、まだ PostgreSQL にあまり慣れていませんが、それは別のスレッドです)
  • Mercurial リポジトリ (Apache 構成、デプロイ スクリプトなどを含む) の S3 への毎晩のバックアップ (Time Machine によるローカル バックアップ付き)

他に何か追加する必要がありますか、それともこれでカバーできますか? データがどれほど重要か/重要かを測るには、Basecamp に似たプロジェクト管理アプリです。

4

3 に答える 3

3

データベースの毎週の完全バックアップと、夜間の増分バックアップも同様ですか?

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

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

于 2008-09-29T15:34:45.637 に答える
2

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

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

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

これにより、新しいインスタンスがデプロイされるたびにリカバリがテストされることがほぼ確実になり、ハードウェアの交換が必要な場合、または特定のサーバーが顧客から過度の負荷を受けている場合に、インスタンスを移動するためにもスクリプトが使用されることになりました.

これは、私が数年前に取り組んだ Saas エンタープライズ アプリケーションのセットアップであり、サーバーを完全に制御できました。

于 2008-09-29T15:52:23.707 に答える
0

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

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

私はこれをうまく説明していると思います！

:)

于 2009-03-01T19:23:07.707 に答える