16

私は、本番環境に急速に移行するアプリを構築しています。ハッキング、ばかげた個人的なエラー (または の実行rake db:schema:loadなどrake db:rollback)、またはその他の状況により、1 つのデータベース テーブルまたはシステム全体でデータが失われる可能性があることを懸念しています。

上記のようなことが起こる可能性は低いとは思いますが、もしそうなった場合に備えていないのは怠慢です。

私は Heroku の PG バックアップ (今月は別のものに置き換えられる予定です) を使用しており、S3 への毎日の自動バックアップも実行しています: http://trevorturk.com/2010/04/14/automated-heroku-backups/、.dumpファイルの生成に成功しました。

実稼働アプリでのデータ損失に対処する正しい方法は何ですか?

  1. .dump必要に応じてファイルを復元するにはどうすればよいですか? システムのごく一部に障害が発生した場合、選択的な復元を行うことはできますか?
  2. 選択的な復元が不可能な場合: 最後のバックアップから 4 時間後に 1 つのテーブルのデータが失われたとします。結果 => 失われたテーブルを修正するには、4 時間のユーザー アクティビティをロールバックする必要がありますか? これに対する良い解決策はありますか？
  3. このような事態が発生した場合、不便を乗り切るためにユーザーをサポートする最善の方法は何ですか?
4

4 に答える 4

0

Herokuで非常に単純な「完全な災害復旧」をシミュレートするには、別のHerokuプロジェクトを作成し、本番アプリケーションを完全に複製します（別のカスタムドメイン名を使用する場合を除く）。

複数のリモートgitターゲットを単一のgitリポジトリに追加して、現在の本番コードベースを使用できるようにすることができます。データベースのバックアップをレプリケートされたプロジェクトにプッシュできます。そうすれば、準備は完了です。

この演習で欠落している唯一のステップは、実際のディザスタリカバリと比較して、複製されたHerokuプロジェクトに本番ドメインを割り当てることです。

アプリケーションの2つのコピーを並行して実行する余裕がある場合は、この演習を自動化し、データ損失の許容範囲に基づいて定期的に（たとえば、1時間ごと、1日ごとに）複製することができます。

于 2011-05-13T07:13:49.447 に答える
0

Hartatorの答えに加えて：

  • DB が提供する場合はレプリケーションを使用します。たとえば、少なくとも 1 つのスレーブを使用したマスター/スレーブ レプリケーションです。

  • スレーブDBサーバーでデータベースのバックアップを行い、それらを外部に保存します（サーバーからscpまたはrsyncするなど）

  • Git など、ソース コードに適切なバージョン管理システムを使用する

  • Capistrano などの堅牢なデプロイ メカニズムを使用し、カスタム タスクを記述します。これにより、手動で DB 移行を行う必要がなくなります。

  • 信頼できる人に、ファイアウォールの設定とシステムのセキュリティ全般を確認してもらいます

DB ダンプには、すべてのテーブルとすべてのデータを再作成するための SQL コマンドが含まれています... 1 つのテーブルのみを復元する場合は、ダンプ ファイルのコピーからその部分を抽出し、(非常に慎重に) 編集してから復元できます。変更されたダンプ ファイル (1 つのテーブル用)。

常に最初に独立したマシンに復元し、データが正しく見えるかどうかを確認してください。たとえば、スレーブ サーバーを 1 つ使用し、オフラインの場合は、ローカルに復元してデータを確認することができます。システムに 2 つのスレーブがある場合は、2 番目のスレーブに復元する間、残りのシステムにはまだ 1 つのマスターと 1 つのスレーブがあります。

于 2011-05-10T18:14:54.577 に答える