ファイルシステムレベルのバックアップバックアップ戦略の代替案としてPostgreSQLがデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。18.2にこれらのファイルがどこにあるか解説されています。下記のような通常のファイルシステムのバックアップを行うどんな方法でも問題ありません。/usr/local/pgsql/dataしかしこの方法には2つの制約があり、そのためにあまり実用的ではなく、少なくともpg_dumpより劣ると言わざるを得ません。有効なバックアップを行うにはデータベースサーバを必ず停止しなければなりません。(tarやその類似ツールはある時点におけるファイルシステムの原子的なスナップショットを取らないことと同時に、サーバ内の内部バッファリングの理由によるからです)。サーバの停止に関しては18.5を参照してください。言うまでもありませんが、データをリストアする前にもサーバを停止させる必要があります。データベースのファイルシステムレイアウトの詳細を熟知している場合、ある個別のテーブルやデータベースをそれぞれのファイルやディレクトリからバックアップしたり復元したりすることを試みたいと思うかもしれません。それらのファイル内の情報はすべてのトランザクションのコミット状態を保持するコミットログファイルpg_xact/*なしでは使えないため、この方法では正常なバックアップは行えません。テーブルファイルはこの情報があって初めて意味をなします。テーブルとそれに付帯するpg_xactデータだけで復元することも、データベースクラスタにある他のテーブルを無効としてしまうのでできません。ファイルシステムバックアップは、データベースクラスタ全体の完全なバックアップとリストア処理にのみ動作します。その他のファイルシステムバックアップ方法として、ファイルシステムが「整合性を維持したスナップショット」機能をサポートしている場合(かつ、正しく実装されていると信用する場合)、データディレクトリのスナップショットを作成する方法があります。典型的な手順では、データベースを含むボリュームの「凍結スナップショット」を作成し、データディレクトリ全体(上述のように、一部だけではいけません)をスナップショットからバックアップデバイスにコピーし、そして、凍結スナップショットを解放します。これはデータベースサーバが稼動中であっても動作します。して作成されたバックアップは、データベースサーバが適切に停止されなかった状態のデータベースファイルを保存します。そのため、このバックアップデータでデータベースサーバを起動する時、直前のサーバインスタンスがクラッシュしたものとみなされ、WALログが取り直されます。これは問題ではありません。注意してください(そして、確実にバックアップにWALファイルを含めてください)。CHECKPOINTコマンドをスナップショット取得前に発行することで復旧時間を減らすこともできます。対象のデータベースが複数のファイルシステムにまたがって分散している場合、全てのボリュームに対して完全に同期した凍結スナップショットを得る方法が存在しない可能性があります。データファイルとWALログが異なったディスク上にあったり、テーブル空間が異なるファイルシステム上にある場合、スナップショットは同時でなければなりませんので、スナップショットのバックアップを使用できない可能性があります。した状況では、整合性を維持したスナップショット技術を信用する前に使用するファイルシステムの文書を熟読してください。同時実行のスナップショットができない場合、選択肢の1つとして、全ての機能の停止したスナップショットを確定させるのに充分な時間、データベースサーバをシャットダウンさせることが挙げられます。他の選択肢は、継続的なベースバックアップの保管(25.3.2)を行うことです。したバックアップには、バックアップ中のファイルシステムの変更を心配する必要がないためです。これにはバックアップ処理期間のみに継続的な保管を行う必要があり、継続的なアーカイブリカバリ(25.3.4)を使用してリストアを行います。ファイルシステムをバックアップするその他の選択肢としてrsyncの使用が挙げられます。--checksumを実行するのに充分な間だけデータベースサーバを停止します。(rsyncはファイルの更新時刻に関して1秒の粒度しかありませんので、--checksumが必要です。次のrsyncは、比較的転送するデータ量が少なく、サーバが稼働していないため最終結果に矛盾がない事から、最初のrsyncよりも迅速です。この方法で最小の稼働停止時間でファイルシステムのバックアップを行う事ができます。ファイルシステムバックアップは、概してSQLによるダンプより大きくなることに注意してください。(pg_dumpでは、例えばインデックスの内容をダンプする必要はありません。コマンドで再作成します。ファイルシステムのバックアップを取るほうがより高速でしょう。継続的アーカイブとポイントインタイムリカバリ(PITR)。