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

バックアップの方法の代替案として、Postgresが データベース内のデータを保存するために使用しているファイルを 直接コピーする方法があります。Section 3.2では、 これらのファイルがどこに位置しているかが明記されていますが、 この方法にご興味がある方は、もうすでに発見されていることでしょう。 下記のような、通常のファイルシステムのバックアップを行う方法と 同じで結構です。

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

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

  1. 有意義なバックアップを行うためには、データベースサーバは シャットダウンされている必要があります。バッファリングなどが 行われている可能性があるので、すべての接続を無効とするだけでは 不十分です。また、この理由から、ファイルシステムの "consistent snapshots"のご使用はあまりお勧めできません。 サーバを停止させることに関してはSection 3.6を 参照して下さい。

    言うまでもありませんが、データを復元する前にもサーバを停止させる必要があります。

  2. ファイルシステムのレイアウトの詳細をご存じの方は、ある各々の テーブルやデータベースのそれぞれのファイルやディレクトリのみを バックアップしたり、復元することを試みられた方がいらっしゃるかも しれません。しかし、それらのファイルの情報のみでは不十分なので、 この方法では正常にバックアップは行えません。pg_log という、すべてのトランザクションのコミットのステータス書かれた ファイルが必要となります。テーブルファイルはこの情報があって 始めて意味を成します。また、テーブルと、それに関係する pg_logファイルのみではデータベースクラスタに ある他のテーブルを無効となってしまうので、リストアはできません。

また、ファイルシステムのバックアップは必ずしもSQLのダンプより 小さいものとはなりません。反対に、多くの場合は大きくなってしまいます。 (pg_dumpでは、例えばインデックスなどは ダンプする必要がなく、復元させるためのコマンドのみが必要だからです。)