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