貴重なデータをすべて保存しているため、 PostgreSQL データベースは定期的にバックアップされなければなりません。バックアップの手順は基本的に簡単とはいっても底流にある技術といくつかの仮定となる条件を理解することは重要です。
PostgreSQL のデータをバックアップするときには基本的に以下の異なった 2 つの手法があります。
SQL によるダンプ
ファイルシステムレベルのバックアップ
SQL によるダンプ方法の背景にある考え方は SQL コマンドでテキストファイルを生成しそのファイルをサーバーが再度読み込みを行ったときにダンプした時点と同じ状態が再構築されるということです。このため、PostgreSQL にはユーティリティプログラム pg_dump を提供しています。このコマンドの基本となる使い方は以下のとおりです。
pg_dump dbname > outfile
見てわかるとおり、pg_dump は結果を標準出力に書き出します。これがどのように活用できるかをこれから説明してゆきます。
pg_dumpは、（すぐれた機能をとくに発揮する）Postgres の通常のクライアントアプリケーションです。ということはデータベースに接続可能なあらゆるリモートホストからこのバックアップ手順を実行することができます。しかし、pg_dump は特別な権限がないと動作しないわけではないことを覚えておいてください。具体的にいうと、バックアップを行うすべてのテーブルに対して読み込み権限が必要となります。 ですから実際にはデータベースのスーパーユーザーである必要があります。
pg_dump を行うデータベースサーバーを特定するにはコマンドラインのオプション、-h host あるいは -p port を使用します。デフォルトのホストはローカルホスト、または環境変数 PGHOST で指定されるものです。同様に、デフォルトのポートは環境変数 PGPORT で指定されているか、うまく行かない場合にはコンパイル時の設定がデフォルトとなります。（そこはうまくできていて、サーバーは通常コンパイル時の設定をデフォルトとします）。
他の PostgreSQL のクライアントアプリケーションと同様に、pg_dump はデフォルトで、オペレーティングシステムの現在のユーザ名と同じデータベースユーザ名で接続します。これを無効にするには -U オプションを付けるか環境変数 PGUSER を設定します。pg_dump の接続は（Chapter 6 で説明されている）通常のクライアント認証方法によることを思い出してください。
pg_dumpで作成されたダンプは、内部的に整合性があります。 つまり、pg_dumpが行われている際の更新はダンプには反映されないということです。 pg_dump が作動しているときはデータベースにたいする他の作業は妨げられません。(VACUUM FULL などの、排他的なロックが必要な作業は例外です）。
Important: （たとえば外部キーのように）データベーススキーマが OID に依存している場合 pg_dump に OID も一緒にダンプするよう指定しなければなりません。これを行うには -o コマンドラインオプションを使用します。デフォルトで "ラージオブジェクト"もダンプされません。ラージオブジェクトを使用する場合リファレンスガイドの pg_dump を参照してください。
pg_dumpで作成されたテキストファイルは psql プログラムで読み込まれることを意図しています。以下に、ダンプをリストアする一般的な方法を示します。
psql dbname < infile
ここで infile は pg_dump コマンドで outfile としたものです。 データベース dbname はこのコマンドでは作成されません。(たとえば createdb -T template0 dbname のようにして) psql を実行する前に自分で template0 から作成してください。 psql には pg_dump と似たような、データベースサーバーの場所とユーザー名を指定する機能があります。詳細については、リファレンスガイドの該当のページを参照してください。
元となるデータベース内のオブジェクトの所有権が別のユーザーにあった場合ダンプは代わりに psql に対しそれぞれの所有権を持っているユーザーになったとして順次接続させ、適切なオブジェクトを作成させます。この方法により、元の所有権が保たれます。このことはすべてのユーザーがあらかじめ存在し、さらにそれぞれのユーザーとして該当する各データベースに接続できる権限を持っていなければいけません。ですから一時的にクライアント認証設定を緩める必要があるでしょう。
pg_dump と psql でパイプから読み書きができるので、あるサーバから別のサーバへデータベースを直接ダンプできます。その例です。
pg_dump -h host1 dbname | psql -h host2 dbname
Important: pg_dump で作成されるダンプは template0 と相関関係にあります。 つまり template1 に追加されたあらゆる言語、手順なども pg_dump によりダンプされます。 その結果としてリストアする際に、カスタマイズされた template1 を使用している場合は、上記の例のように、template0 から空のデータベースを作成する必要があります。
上で説明した手法はデータベースクラスタすべてをバックアップする際に扱いにくく不適切です。 この理由で pg_dumpall プログラムが提供されています。 pg_dumpall は指定されたクラスタの各データベースのバックアップを行い、ユーザーやグループなどの全体にわたるデータの状態が確実に保たれるようにします。pg_dumpall の呼出し手順は単に
pg_dumpall > outfile
ダンプの結果は上記の説明のとおり psql でリストアできます。しかしこの場合、ユーザーとグループの情報をリストアしなければならないのでデータベーススーパーユーザーのアクセス権限を確実に必要とします。
謝辞: 原文は 1999-06-19 に Hannu Krosing (<hannu@trust.ee>) が書きました。
PostgreSQL はシステム上で最大可能なファイルサイズよりも大きなテーブルを扱えるのでファイルにダンプする際に、システムで許容されているファイルサイズを越えてしまうという問題に遭遇する可能性があります。pg_dump は標準出力に書き出しますので、この問題を解決するために Unix のツールを使用して回避できます。
圧縮ダンプの使用. gzip のような好みの圧縮プログラムを使います。
pg_dump dbname | gzip > filename.gz
もとに戻すにはつぎのようにします。
createdb dbname gunzip -c filename.gz | psql dbname
あるいはこのようにもできます。
cat filename.gz | gunzip | psql dbname
split の使用. このコマンドで結果を環境下にあるシステムで受け付けられる大きさに分割します。たとえば 1M バイトのチャンクを作るにはつぎのようにします。
pg_dump dbname | split -b 1m - filename
もとに戻すにはつぎのようにします。
createdb dbname cat filename* | psql dbname
カスタムダンプの使用. もし PostgreSQL が zlib 圧縮ライブラリインストール済みのシステム上でビルドされたのならカスタムダンプ形式を使用して結果ファイルに出力するときにデータを圧縮します。大きいデータベースでは gzip を使用したときと似通ったダンプサイズとなりますが、テーブルの復元を部分的に行えるという点で優れているといえます。以下のコマンドでカスタムダンプ形式でデータベースのダンプを行います。
pg_dump -Fc dbname > filename
詳細はリファレンスガイドの pg_dump と pg_restore を参照してください。
pg_dump（pg_dumpall も連座して）にはシステムカタログからデータベースを復元する際、復元するのが困難な情報が中にはあるために生じるいくつかの制約があります。
特に、pg_dump がオブジェクトを書き出す順序は洗練されていません。たとえば列のデフォルト値として関数が使用されている場合などでこれが問題となります。この問題を解決するには、手作業でダンプ順序を変更する方法以外ありません。スキーマで巡回依存を作成していた場合は、これ以上の作業が必要となります。
逆互換性の理由からデフォルトで pg_dump はラージオブジェクトのダンプを行いません。 ラージオブジェクトのダンプを行うには、出力形式をカスタムもしくは TAR 形式にする必要があり、また pg_dump に -b オプションを付ける必要があります。詳細はリファレンスガイドを参照してください。PostgreSQL ソースツリーの contrib/pg_dumplo ディレクトリにもラージオブジェクトをダンプするプログラムがあります。
リファレンスガイドの pg_dump を習熟してください。