バックアップ戦略の代替案としてPostgreSQLがデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。 19.2にこれらのファイルがどこにあるか解説されています。 下記のような通常のファイルシステムのバックアップを行うどんな方法でも問題ありません。

tar -cf backup.tar /usr/local/pgsql/data

しかしこの方法には2つの制約があり、そのためにあまり実用的ではなく、少なくともpg_dumpより劣ると言わざるを得ません。

その他のファイルシステムバックアップ方法として、ファイルシステムが「整合性を維持したスナップショット」機能をサポートしている場合（かつ、正しく実装されていると信用する場合）、データディレクトリのスナップショットを作成する方法があります。 典型的な手順では、データベースを含むボリュームの「凍結スナップショット」を作成し、データディレクトリ全体（上述のように、一部だけではいけません）をスナップショットからバックアップデバイスにコピーし、そして、凍結スナップショットを解放します。 これはデータベースサーバが稼働中であっても動作します。 しかし、こうして作成されたバックアップは、データベースサーバが適切に停止されなかった状態のデータベースファイルを保存します。 そのため、このバックアップデータでデータベースサーバを起動する時、直前のサーバインスタンスがクラッシュしたものとみなされ、WALログが取り直されます。 これは問題ではありません。 単に注意してください（そして、確実にバックアップにWALファイルを含めてください）。 CHECKPOINTコマンドをスナップショット取得前に発行することで復旧時間を減らすこともできます。

対象のデータベースが複数のファイルシステムにまたがって分散している場合、全てのボリュームに対して完全に同期した凍結スナップショットを得る方法が存在しない可能性があります。 例えば、データファイルとWALログが異なったディスク上にあったり、テーブル空間が異なるファイルシステム上にある場合、スナップショットは同時でなければなりませんので、スナップショットのバックアップを使用できない可能性があります。 こうした状況では、整合性を維持したスナップショット技術を信用する前に使用するファイルシステムの文書を熟読してください。

同時実行のスナップショットができない場合、選択肢の１つとして、全ての機能の停止したスナップショットを確定させるのに充分な時間、データベースサーバをシャットダウンさせることが挙げられます。 他の選択肢は、継続的なベースバックアップの保管（26.3.2）を行うことです。 こうしたバックアップには、バックアップ中のファイルシステムの変更を心配する必要がないためです。 これにはバックアップ処理期間のみに継続的な保管を行う必要があり、継続的なアーカイブリカバリ（26.3.4）を使用してリストアを行います。

ファイルシステムをバックアップするその他の選択肢としてrsyncの使用が挙げられます。 これを行うには、先ずデータベースサーバが稼働中にrsyncを実行し、そしてrsync --checksumを実行するのに充分な間だけデータベースサーバを停止します。 (rsyncはファイルの更新時刻に関して1秒の粒度しかありませんので、--checksumが必要です。) 次のrsyncは、比較的転送するデータ量が少なく、サーバが稼働していないため最終結果に矛盾がない事から、最初のrsyncよりも迅速です。 この方法で最小の稼働停止時間でファイルシステムのバックアップを行う事ができます。

ファイルシステムバックアップは、概してSQLによるダンプより大きくなることに注意してください。 （pg_dumpでは、例えばインデックスの内容をダンプする必要はありません。単にコマンドで再作成します。） しかし、ファイルシステムのバックアップを取るほうがより高速でしょう。