EC2-PostgreSQLデータを正しくバックアップする方法

これがセットアップです。3つの追加ボリュームを持つ1つの小さなAmazon Linux（EBS-backed）EC2インスタンス。これは、Webサーバーとデータベースサーバーの両方です。コード用の1つのボリューム、PostgreSQL（8.4）データディレクトリ用の1つのボリューム、およびPostgreSQLからのWALファイルを格納するための1つのボリューム。

（1）WALファイルを含むボリュームには、pg_start_backup（）を実行した後にコピーされるデータディレクトリのベースバックアップもあります。次に、PostgreSQLからの継続的なアーカイブ出力（WALファイル）を保存します。このボリュームのスナップショットを作成するには、同期を発行してファイルシステムをフリーズする（XFSの場合はxfs_freezeを使用するか、EXT4の場合はdmsetupを使用する）意味がありますか？または、ライブスナップショットを撮ることができますか？WALファイルは、毎分1つの速度で出荷されます。単一のWALファイルがコピーされている間にスナップショットが開始され、データが破損する可能性はありますか？

（2）ライブPostgreSQLデータディレクトリを含むボリュームも、適切な方法で（毎日）バックアップされます。このボリュームのスナップショットを作成する前に、pg_dumpを実行すると、結果のSQLファイルがデータディレクトリに保持されます。実際のデータベースデータの整合性を確保するための予防策を講じることに意味はありますか？ライブスナップショットを作成すると、（a）構成ファイル（postgresql.conf、pg_hba.conf、pg_ident.conf）が適切にバックアップされ、（b）SQLダンプファイルがバックアップされると想定して間違いありませんか。SQLダンプファイルと構成ファイルの2つをバックアップすることが、このボリュームのスナップショットの主なポイントになります。DBはそれほど大きくないので、データファイルがこのスナップショットを膨らませることは気にしません。その場合、ライブスナップショットを作成できます-正しいですか？

（2a）ルートボリュームにデータディレクトリを保持し、SQLダンプファイルと構成ファイルを別のボリュームにコピーするバックアップスクリプトを用意し、コピーが完了したらそのボリュームのスナップショットを作成するほうがよいでしょうか？

（3）コードが含まれているボリュームについて、ファイルシステムを同期してフリーズするポイントはありますか？または、ライブスナップショットのみを取得できますか？このデータはかなり「静的」である必要があります。

（4）これは確かなバックアップスキームですか？ルートボリュームは定期的にバックアップされません。これは、セットアップして構成した後のマシンイメージを保持するだけだからです。

ありがとう

細かいマニュアルを参照してください。私のアドバイスが何らかの形でそれと矛盾する場合、それは正しいです。

1. 次のファイルをコピーする前に、コピーツールfsync（）が書き込みを行う各WALファイルとそこにあるディレクトリを除いて、同期は悪い考えではありません。不完全な最後のWALファイルはそれほど重要ではありません。最悪の場合、それを削除するだけです。Pgは通常、不完全なWALで窒息します-チェックサムが行われていないため、次のことができます本当に不運なことに、まさかの偶然によって偶然に実際のWALレコードのように見えるガベージデータを適用してみてください。あなたの位置では、スナップショットの前にボリュームを同期して、RAM内の未書き込みのダーティバッファーがディスク上のファイルシステムイメージにヒットすることを確認します。フリーズは、面倒で致命的ではない部分的に記述されたWALを回避するのに役立ちます。重要なのは、回復の時点までの損傷を受けていないタイムラインを持つことです。個人的には、WALを一時ファイル名に書き込み、完全にコピーした後でのみ、それらを最終的な名前に変更します。これを行えば、フリーズする必要はありません。

2. 正解ですね。ライブスナップショットは、ライトスルーキャッシュを備えたライブシステムでプラグプルテストを行うのと同じです。ライブスナップショットから復元すると、データベースはプラグプル後と同じように正常に回復します。スナップショットからの復元のテストを自動化することをお勧めします。（注：Aは、テストを復元するスナップショットではないことが可能ディスク、RAIDコントローラなど書き込みキャッシュを考慮していないので、プラグプル試験のための完全な代替）。設定ファイルとダンプだけでなく、データベース自体は、スナップショットの後で問題ないはずです。スナップショットの前にボリュームを同期して、すべてのダンプデータなどが実際にディスクにヒットしていることを確認してください。
   
   2a。ディスク容量を節約できる可能性があります。それ以外はほとんど違いはありません。ライブデータベースのすべてのチャーンがなくても、スナップショットをより長く保持できます。

3. コードボリュームのスナップショットを作成するのはなぜですか？プレーンファイルレベルのコピーで十分です。確かに、ライブスナップショットは必要です。

4. これは確実なバックアップスキームではありません。1つの重要な領域で失敗します。実行されている復元テストと検証はありません。あなたは、常に必要があり、あなたのバックアップをテストし、あなたが実際にそれらを復元できることを確認するために定期的に。

   個人的には、WAL配送を使用するか、データベースダンプを別のホストに送信することをお勧めします。できれば、Amazon EC2にないホストか、少なくとも別のリージョンにあるホストをお勧めします。このホストは、自動復元テストを実行し、結果のレポートを送信する必要があります。また、手動で確認する必要もあります。

   スナップショット（ダンプを含む）はS3にあり、安全ですが、緊急に必要になったときにアクセスできるという意味ではありません。Amazonの耐久性に関する主張は心強いですが、S3サービスの停止時間がひどい場合でも、データは安全で完全にアクセスできません。