An alternative backup strategy is to directly copy the files that <productname>PostgreSQL</productname> uses to store the data in the database; <xref linkend="creating-cluster"/> explains where these files are located. You can use whatever method you prefer for doing file system backups; for example: バックアップ戦略の代替案としてPostgreSQLがデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。 18.2にこれらのファイルがどこにあるか解説されています。 下記のような通常のファイルシステムのバックアップを行うどんな方法でも問題ありません。
tar -cf backup.tar /usr/local/pgsql/data
There are two restrictions, however, which make this method impractical, or at least inferior to the <application>pg_dump</application> method: しかしこの方法には2つの制約があり、そのためにあまり実用的ではなく、少なくともpg_dumpより劣ると言わざるを得ません。
The database server <emphasis>must</emphasis> be shut down in order to
get a usable backup. Half-way measures such as disallowing all
connections will <emphasis>not</emphasis> work
(in part because <command>tar</command> and similar tools do not take
an atomic snapshot of the state of the file system,
but also because of internal buffering within the server).
Information about stopping the server can be found in
<xref linkend="server-shutdown"/>. Needless to say, you
also need to shut down the server before restoring the data.
有効なバックアップを行うにはデータベースサーバを必ず停止しなければなりません。
全ての接続を無効とするような中途半端な対策では作用しません
（tarやその類似ツールはある時点におけるファイルシステムの原子的なスナップショットを取らないことと同時に、サーバ内の内部バッファリングの理由によるからです）。
サーバの停止に関しては18.5を参照してください。
言うまでもありませんが、データをリストアする前にもサーバを停止させる必要があります。
If you have dug into the details of the file system layout of the
database, you might be tempted to try to back up or restore only certain
individual tables or databases from their respective files or
directories. This will <emphasis>not</emphasis> work because the
information contained in these files is not usable without
the commit log files,
<filename>pg_xact/*</filename>, which contain the commit status of
all transactions. A table file is only usable with this
information. Of course it is also impossible to restore only a
table and the associated <filename>pg_xact</filename> data
because that would render all other tables in the database
cluster useless. So file system backups only work for complete
backup and restoration of an entire database cluster.
データベースのファイルシステムレイアウトの詳細を熟知している場合、ある個別のテーブルやデータベースをそれぞれのファイルやディレクトリからバックアップしたり復元したりすることを試みたいと思うかもしれません。
しかし、それらのファイル内の情報はすべてのトランザクションのコミット状態を保持するコミットログファイルpg_xact/*なしでは使えないため、この方法では正常なバックアップは行えません。
テーブルファイルはこの情報があって初めて意味をなします。
もちろんテーブルとそれに付帯するpg_xactデータだけで復元することも、データベースクラスタにある他のテーブルを無効としてしまうのでできません。
ですので、ファイルシステムバックアップは、データベースクラスタ全体の完全なバックアップとリストア処理にのみ動作します。
An alternative file-system backup approach is to make a
<quote>consistent snapshot</quote> of the data directory, if the
file system supports that functionality (and you are willing to
trust that it is implemented correctly). The typical procedure is
to make a <quote>frozen snapshot</quote> of the volume containing the
database, then copy the whole data directory (not just parts, see
above) from the snapshot to a backup device, then release the frozen
snapshot. This will work even while the database server is running.
However, a backup created in this way saves
the database files in a state as if the database server was not
properly shut down; therefore, when you start the database server
on the backed-up data, it will think the previous server instance
crashed and will replay the WAL log. This is not a problem; just
be aware of it (and be sure to include the WAL files in your backup).
You can perform a <command>CHECKPOINT</command> before taking the
snapshot to reduce recovery time.
その他のファイルシステムバックアップ方法として、ファイルシステムが「整合性を維持したスナップショット」機能をサポートしている場合（かつ、正しく実装されていると信用する場合）、データディレクトリのスナップショットを作成する方法があります。
典型的な手順では、データベースを含むボリュームの「凍結スナップショット」を作成し、データディレクトリ全体（上述のように、一部だけではいけません）をスナップショットからバックアップデバイスにコピーし、そして、凍結スナップショットを解放します。
これはデータベースサーバが稼働中であっても動作します。
しかし、こうして作成されたバックアップは、データベースサーバが適切に停止されなかった状態のデータベースファイルを保存します。
そのため、このバックアップデータでデータベースサーバを起動する時、直前のサーバインスタンスがクラッシュしたものとみなされ、WALログが取り直されます。
これは問題ではありません。
単に注意してください（そして、確実にバックアップにWALファイルを含めてください）。
CHECKPOINTコマンドをスナップショット取得前に発行することで復旧時間を減らすこともできます。
If your database is spread across multiple file systems, there might not be any way to obtain exactly-simultaneous frozen snapshots of all the volumes. For example, if your data files and WAL log are on different disks, or if tablespaces are on different file systems, it might not be possible to use snapshot backup because the snapshots <emphasis>must</emphasis> be simultaneous. Read your file system documentation very carefully before trusting the consistent-snapshot technique in such situations. 対象のデータベースが複数のファイルシステムにまたがって分散している場合、全てのボリュームに対して完全に同期した凍結スナップショットを得る方法が存在しない可能性があります。 例えば、データファイルとWALログが異なったディスク上にあったり、テーブル空間が異なるファイルシステム上にある場合、スナップショットは同時でなければなりませんので、スナップショットのバックアップを使用できない可能性があります。 こうした状況では、整合性を維持したスナップショット技術を信用する前に使用するファイルシステムの文書を熟読してください。
If simultaneous snapshots are not possible, one option is to shut down the database server long enough to establish all the frozen snapshots. Another option is to perform a continuous archiving base backup (<xref linkend="backup-base-backup"/>) because such backups are immune to file system changes during the backup. This requires enabling continuous archiving just during the backup process; restore is done using continuous archive recovery (<xref linkend="backup-pitr-recovery"/>). 同時実行のスナップショットができない場合、選択肢の１つとして、全ての機能の停止したスナップショットを確定させるのに充分な時間、データベースサーバをシャットダウンさせることが挙げられます。 他の選択肢は、継続的なベースバックアップの保管（25.3.2）を行うことです。 こうしたバックアップには、バックアップ中のファイルシステムの変更を心配する必要がないためです。 これにはバックアップ処理期間のみに継続的な保管を行う必要があり、継続的なアーカイブリカバリ（25.3.5）を使用してリストアを行います。
Another option is to use <application>rsync</application> to perform a file
system backup. This is done by first running <application>rsync</application>
while the database server is running, then shutting down the database
server long enough to do an <command>rsync --checksum</command>.
(<option>--checksum</option> is necessary because <command>rsync</command> only
has file modification-time granularity of one second.) The
second <application>rsync</application> will be quicker than the first,
because it has relatively little data to transfer, and the end result
will be consistent because the server was down. This method
allows a file system backup to be performed with minimal downtime.
ファイルシステムをバックアップするその他の選択肢としてrsyncの使用が挙げられます。
これを行うには、先ずデータベースサーバが稼働中にrsyncを実行し、そしてrsync --checksumを実行するのに充分な間だけデータベースサーバを停止します。
（rsyncはファイルの更新時刻に関して1秒の粒度しかありませんので、--checksumが必要です。）
次のrsyncは、比較的転送するデータ量が少なく、サーバが稼働していないため最終結果に矛盾がない事から、最初のrsyncよりも迅速です。
この方法で最小の稼働停止時間でファイルシステムのバックアップを行う事ができます。
Note that a file system backup will typically be larger than an SQL dump. (<application>pg_dump</application> does not need to dump the contents of indexes for example, just the commands to recreate them.) However, taking a file system backup might be faster. ファイルシステムバックアップは、概してSQLによるダンプより大きくなることに注意してください。 （pg_dumpでは、例えばインデックスの内容をダンプする必要はありません。単にコマンドで再作成します。） しかし、ファイルシステムのバックアップを取るほうがより高速でしょう。