ファイルシステムレベルのバックアップ

PostgreSQL 8.0.0 文書
前のページ | 巻戻し | 第 22章バックアップとリストア | 早送り | 次のページ

# 22.2. ファイルシステムレベルのバックアップ

バックアップ戦略の代替案として PostgreSQL がデータベース内のデータを保存するために使用しているファイルを直接コピーする方法があります。 項16.2 にこれらのファイルがどこにあるか解説されていますが、この方法に興味がある方はもう既に発見していることでしょう。 下記のような通常のファイルシステムのバックアップを行うどんな方法でも問題ありません。

    tar -cf backup.tar /usr/local/pgsql/data

しかしこの方法には 2 つの制約があり、そのためにあまり実用的ではなく、少なくとも pg_dump より劣るといわざるを得ません。

1. 有効なバックアップを行うにはデータベースサーバを必ず 停止しなければなりません。 全ての接続を無効とするような中途半端な対策では作用しません。 (主な理由は、`tar`やその類似ツールはある時点におけるファイルシステムの原始的なスナップショットを取らないことです。) サーバの停止に関しては 項16.6 を参照してください。 いうまでもありませんが、データをリストアする前にもサーバを停止させる必要があります。

2. データベースのファイルシステムレイアウトの詳細を熟知している場合、ある個別のテーブルやデータベースをそれぞれのファイルやディレクトリからバックアップしたり復元したりすることを試みたいと思うことがあったかもしれません。 しかしそれらのファイルは半分程度の情報しか保有しておらず、この方法では正常なバックアップは行えません。 後の半分の情報は全てのトランザクションのコミット状態を保存しているコミットログファイル `pg_clog/*` に書かれています。 テーブルファイルはこの情報があって始めて意味を成します。 もちろんテーブルとそれに付帯する `pg_clog` データだけで復元することも、データベースクラスタにあるほかのテーブルを無効としてしまうのでできません。 ですので、ファイルシステムバックアップは、データベースクラスタ全体の完全なリストア処理にのみ動作します。

その他のファイルシステムバックアップ方法として、ファイルシステムが"整合性を維持したスナップショット"機能をサポートしている場合(かつ、正しく実装されていると信用する場合)、データディレクトリのスナップショットを作成する方法があります。 典型的な手順では、データベースを含むボリュームの"凍結スナップショット"を作成し、データディレクトリ全体（上述のように、一部だけではいけません。）をスナップショットからバックアップデバイスにコピーし、そして、凍結スナップショットを解放します。 これはデータベースサーバが稼動中であっても動作します。 しかし、こうして作成されたバックアップは、データベースサーバが適切に停止していない状態のデータベースファイルを保存します。 そのため、このバックアップデータでデータベースサーバを起動する時、サーバがクラッシュしたものと見なされ、WALログが再現されます。 これは問題ではありません。単に注意してください(そして、確実にバックアップにWALファイルを含めてください)。

対象のデータベースが複数のボリュームに跨って分散している場合（例えば、データファイルとWALログを別のディスクに格納している場合）、全てのボリュームに対して完全に同期した凍結スナップショットを得る方法が存在しない可能性があります。 こうした状況では、整合性を維持したスナップショット技術を信用する前に使用するファイルシステムの文書を熟読してください。 最も安全な方法は、全ての凍結スナップショットを確立するのに十分な期間、データベースサーバをシャットダウンさせることです。

ファイルシステムバックアップは、SQLによるダンプより小さくなるとは限らないいことに注意してください。 反対に、これは巨大になりがちです。 (pg_dump では、例えばインデックスの内容をダンプする必要はありません。単にコマンドで再作成します。)

前のページ | ホーム | 次のページ
バックアップとリストア | 上に戻る | オンラインバックアップとポイントインタイムリカバリ(PITR)