バックアップ戦略の代替案として PostgreSQL がデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。Section 3.2 にこれらのファイルがどこにあるか解説されていますが、この方法に興味があるかたはもうすでに発見していることでしょう。下記のような通常のファイルシステムのバックアップを行うどんな方法でも問題ありません。
tar -cf backup.tar /usr/local/pgsql/data
しかしこの方法には 2 つの制約があり、そのためにあまり実用的ではなくすくなくとも pg_dump より劣るといわざるを得ません。
有効なバックアップを行うにはデータベースサーバーを必ず 停止しなければなりません。バッファリングなどが行われている可能性があるのですべての接続を無効とするような中途半端な対策では作用しません。この理由からファイルシステムでサポートしているといっている「consistent snapshots」の使用はあまりお勧めできません。サーバーの停止に関しては Section 3.6 を参照してください。
言うまでもありませんがデータを復元する前にもサーバーを停止させる必要があります。
ファイルシステムレイアウトの詳細を知っている場合、ある個別のテーブルやデータベースをそれぞれのファイルやディレクトリからバックアップしたり復元したりすることを試みたいと思うことがあったかもしれません。しかしそれらのファイルは半分程度の情報しか保有しておらず、この方法では正常にバックアップは行えません。あとの半分の情報はすべてのトランザクションのコミット状態を保存しているコミットログファイル pg_clog/* に書かれています。テーブルファイルはこの情報があって始めて意味を成します。もちろんテーブルとそれに付帯する pg_clog データだけで復元することもデータベースクラスタにあるほかのテーブルを無効としてしまうのでできません。
同時にファイルシステムのバックアップは必ずしも SQL のダンプより小さいものとはなりません。反対に、多くの場合は大きくなってしまいます。(pg_dump はたとえばインデックスなどはダンプする必要がなく再構築のためのコマンドのみが必要だからです。