postgresql-「ライブ」/ホットファイルバックアップのアプローチ？
無知な質問を許してください、しかしpostgresにはWALログがあり、ファイルシステムスナップショットの使用についての話があり、スナップショットを使用したWALは十分なバックアップ/リカバリである場合とそうでない場合があります...私は伝統的にDBAではありません/ admin（私は開発者です）が、これらのニーズをよりよくサポートすることを目指しているところに到達しています。
質問：Postgresを10GBまたは100GBサイズのシステムでセットアップしてnot特別なバックアップソフトウェアを使用できますが、代わりに従来のファイルシステムバックアップソフトウェア（ファイルシステムスナップショット？）を使用し、この方法を使用して合理的な回復方法を使用できます？ （サイズが重要な場合は、知りたい）
ユースケース1：Postgresを使用するときに特別なバックアップアプローチを回避し、通常のファイルシステムを使用するため。ダウンタイムなし、または5秒未満。
ユースケース2：AlfrescoなどのハイブリッドECMで使用する場合、ファイルシステムのコンテンツ（イメージ）とメタデータ（データベース）を常に同時にバックアップおよび復元する必要があります。ダウンタイムなし、または5秒未満。
良い/悪いアイデアや気をつけるべきことなど、私が尋ねていないかもしれない分野について詳しく説明してください:-)
（これはLinux環境でのローカルインストール用であり、戦略に特定のファイルシステムが必要な場合は問題ありません）。
TIA！
-D
質問：Postgresを10GBまたは100GBサイズのシステムでセットアップして、特別なバックアップソフトウェアを使用せず、代わりに従来のファイルシステムバックアップソフトウェア（ファイルシステムスナップショット？）を使用し、この方法を使用して適切な回復方法を使用できますか？
はい、ファイルシステムのスナップショットがアトミックである場合 。これは非常に重要です。 アトミックスナップショット が必要です。データディレクトリを直接コピーすることはできません。通常の方法は、SAN、論理ボリュームマネージャー、スナップショット対応ファイルシステムなどを使用してスナップショットを作成し、それを別のパスにマウントしてからバックアップすることです。したがって、バックアップ前後のスクリプトを使用しています。
ここで「アトミック」は、コンピュータサイエンスの意味で使用され、分割できない、すべてがその瞬間の前後にある単一の瞬間を意味します。スナップショットの場合、それはある瞬間、その特定の瞬間のストレージの状態を意味します。
Microsoftのボリュームシャドウコピーサービス（Windows用）はファイルレベルでのみアトミックであるため、一貫性を保つためにそれに依存するバックアップシステムを使用することはできないと私は理解しています。
ファイルシステムのスナップショットを実際に使用していない場合は、ファイルシステム上のデータをライブでコピーしているだけです。それでも実行できますが、追加の手順を実行する必要があります。 ドキュメントによる PostgreSQLにバックアップが行われていることを伝えることができ、実行中にバックアップを安全にする上書きなしモードになります。ただし、このようなバックアップを復元するには、次のファイルが必要ですバックアップ後のスクリプトがpg_stop_backup()を呼び出した後。これらのファイルがあることを確認する最も簡単な方法は、 WALアーカイブ が有効になっていることを確認することです。それ以外の場合は、バックアップに追加するために、バックアップシステムにいくつかの追加のスクリプトフックが必要になります。
ユースケース1：Postgresを使用するときに特別なバックアップアプローチを回避し、通常のファイルシステムを使用するため。ダウンタイムなし、または5秒未満。
これには、 pg_dump または pg_basebackup 。どちらもダウンタイムを必要とせず、シンプルです。
適切なバックアップシステムは、これを簡単にするバックアップ前後のフックをサポートしています。
ユースケース1：Postgresを使用するときに特別なバックアップアプローチを回避し、通常のファイルシステムを使用するため。ダウンタイムなし、または5秒未満。
そのためには、アトミックスナップショットが必要になり、イメージがPostgreSQLと同じスナップショットにあることを確認する必要があります。
そうしないと、ファイルシステムとDBが完全に一致しないという不整合のリスクがあります。