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