私たちは多くのLinux VMをvmware /共有ストレージ環境で実行しており、それぞれが独自のpostgreSQLインスタンス（9.0と9.3の混合）を実行しています。現在、VM全体が単一のルートパーティション/ボリューム上にあり、基盤となるVMFSボリュームのストレージベースのスナップショットをバックアップ/復元プロセス（および私たちのDRサイトへのレプリケーション）に使用することで大きな成功を収めています（約8年）。
ストレージのアーキテクチャーにより、postgres WALファイルをキャッシュされていない、大部分が書き込みボリュームに分離して、ストレージ側でのキャッシュチャーンを少なくすることが有利です。ストレージ（Nimble Storage）を使用すると、両方のボリュームを単一の保護/スナップショットグループに割り当てることができますが、スナップショットが保護グループ内のすべてのボリュームでまったく同時に発生することをベンダーから引き出すことができませんでした-可能性は高いですが、ミリ秒単位で離れている可能性は常にあります。
そのために、pg_benchを使用して可能な限り高速にデータをDBに書き込みながら、いくつかの実験を行いました。実験後、スナップショットのボリュームを復元し、VM + postgresを起動しました
- データボリュームとログボリュームの両方をほぼ同時にスナップショット作成-結果：DBが回復
- 最初にスナップショットデータボリューム、〜1分後にログボリューム-結果：DBが回復しました
- 最初にスナップショットログボリューム、約1分後にデータボリューム-結果：DBが回復しました
- WALチェックポイントがデータファイルに新しいデータを書き込んだ後、最初にスナップショットログボリューム、約3分後にデータボリューム：結果：DBが回復しました
したがって、両方のスナップショットがボリュームレベルで一貫しており、比較的近い距離にある限り、WAL /ログボリュームのスナップショットの時間に基づいて、DBの一貫したコピーが得られます。
私の質問：これは安全ですか？テストで欠落している主なケースは何ですか？また、何が問題になる可能性がありますか？
Postgresのドキュメントはこれが安全ではないことを示していますが、テストはかなり堅牢であることを示しているようです：http : //www.postgresql.org/docs/9.1/static/backup-file.html
データベースが複数のファイルシステムに分散している場合、すべてのボリュームの正確に同時に凍結されたスナップショットを取得する方法がない場合があります。たとえば、データファイルとWALログが異なるディスク上にある場合、またはテーブルスペースが異なるファイルシステム上にある場合、スナップショットは同時でなければならないため、スナップショットバックアップを使用できない場合があります。このような状況でコンシステントスナップショット手法を信頼する前に、ファイルシステムのドキュメントをよく読んでください。
注：はい、PostgreSQLをホットバックアップモードにしたり、ストレージのVMware統合を使用してVM自体を静止したりするなど、一貫性を確保する他のオプションについては知っていますが、スピードと利便性のためにストレージのみのソリューションを探しています。クライアントへの影響はゼロです。