PostgreSQLは常に、クラスタのデータディレクトリ以下のpg_xlog/ディレクトリ内で先行書込みログ (WAL)を管理しています。 このログはデータベースのデータファイルに行われた全ての変更を示します。 このログは主にクラッシュ時の安全性を目的としています。 システムがクラッシュしたとしても、最後のチェックポイント以降に作成されたログ項目を"再生"することで、データベースを整合性を維持した状態にリストアすることができます。 しかし、この存在するログファイルを使用して、データベースのバックアップ用の第3の戦略が可能になりました。 ファイルシステムレベルのバックアップとWALファイルのバックアップを組み合わせるという戦略です。 復旧が必要ならば、バックアップをリストアし、その後にバックアップされたWALファイルを再生することで、現時点までのバックアップを生成できます。 管理者にとって、この方法はこれまで説明した方法よりかなり複雑になりますが、以下のような大きな利点が複数あります。
開始時点のバックアップは完全な整合状態である必要はありません。 そのバックアップ内の内部的な不整合はログの再生によって修正されます。 (これは、クラッシュからの復旧時に行われることと大きな違いはありません。) ですので、ファイルシステムのスナップショット機能を必要としません。 単にtarなどのアーカイブツールが必要です。
WALファイルの並びを数に制限無く連ねて再生できますので、単にWALファイルの保管を続けることで連続したバックアップを達成できます。 これは、完全なバックアップを頻繁に行うことが困難な、大規模なデータベースでは特に有用です。
WAL項目の再生を最後まで行わなければならないということはありません。 再生を任意の時点までで停止することができ、それにより、その時点までのデータベースの整合性を持ったスナップショットを得ることができます。 このような技術がポイントインタイムリカバリを補助するものであり、元となるベースバックアップの取得時点以降の任意の時点の状態にデータベースをリストアすることが可能になります。
連続的に一連のWALファイルを、同一のベースバックアップをロードしている別のマシンに配送することで、"ホットスタンバイ"システムを持つことができます。 つまり、任意の時点でその2番目のマシンを、ほぼ現時点のデータベースの複製をもった状態で有効にすることができます。
通常のファイルシステムバックアップ技術の場合と同様、この方法は、一部ではなく、データベースクラスタ全体のリストア処理のみをサポートできます。 また、保管用に大量の格納領域を必要とします。 ベースバックアップは大きくなる場合があり、また、高負荷なシステムでは保管しなければならないWALの流量をメガバイト単位で生成します。 しかし、これは、高信頼性が必要な、多くの状況で好まれるバックアップ手法です。
オンラインバックアップを使用して復旧を成功させるためには、少なくともバックアップの開始時点まで遡る、連続した一連の保管済みWALファイルが必要です。 ですので、運用するためには、最初のベースバックアップを取得する前にWALファイルを保管する手順を設定し試験しなければなりません。 従って、まずWALファイルの保管機構について説明します。
理論上、PostgreSQLシステムの稼動により、不定長のWAL記録の並びが生成されます。 システムは物理的にこの並びを、通常一つ16Mb(このサイズはPostgreSQLの構築時に変更可能です。)の、WALセグメントファイルに分割します。 このセグメントファイルには、概念的なWALの並び内の位置を反映した、数字の名前が付与されます。 WAL保管を行わない場合、システムは通常数個のセグメントファイルを生成し、また、不要となったセグメントファイルの名前をより大きなセグメント番号に変更することでそれを"再回収"します。 直前のチェックポイントより前の内容を持つセグメントファイルは使用されないと仮定され、再回収されます。
WALデータを保管する場合、完成したセグメントファイルのそれぞれの内容を取り出し、再利用のために回収される前にそのデータをどこかに保存することが必要です。 アプリケーションと利用できるハードウェアに依存しますが、複数の"データをどこかに保存する"方法を取ることができます。 例えば、NFSでマウントした他のマシンのディレクトリにセグメントファイルをコピーすること、あるいは、テープ装置に書き出す(元々のファイル名でリストアできることを確認してください。)こと、それらを一度にまとめて、CDに焼くこと、などです。 できる限り高い柔軟性をデータベース管理者に提供するために、PostgreSQLは、どのように保管がなされたかについて一切仮定を持たないようにしています。 その代わりにPostgreSQLは、管理者に完全なセグメントファイルをどこか必要な場所にコピーするシェルコマンドを指定させます。 このコマンドは単純なcpでも構いませんし、また、複雑なシェルスクリプトを呼び出しても構いません。 全て管理者に任されています。
使用するシェルコマンドはarchive_command設定パラメータで指定されます。 実際には、postgresql.confファイルで常に設定することになるでしょう。 この文字列内では%p は全て保管するファイルの絶対パスに置換され、%f は全てファイル名部分のみに置換されます。 コマンド内に%文字自体を埋め込む必要があれば%%と記述してください。 最も簡単でよく使用されるコマンドは以下のようなものになります。
archive_command = 'cp -i %p /mnt/server/archivedir/%f </dev/null'
これは、保管可能なWALセグメントを/mnt/server/archivedirディレクトリにコピーします。 (これは一例です。推奨するものではなく、また、全てのプラットフォームで動作しない可能性があります。)
この保管用コマンドはPostgreSQLサーバを稼動させるユーザと同じ所有権で実行されます。 保管される一連のWALファイルには、実質、データベース内の全てが含まれていますので、保管したデータを覗き見から確実に保護しなければならないでしょう。 例えば、グループや全員に読み込み権限を付与していないディレクトリにデータを保管してください。
保管用コマンドが成功した場合のみにゼロという終了ステータスを返すことが重要です。 PostgreSQLは、ゼロという結果に基づいて、WALセグメントファイルの保管が成功したことを決定しますので、そのファイルは削除されたり回収されたりするかもしれません。 しかし、非ゼロのステータスは、PostgreSQLに対してファイルが保管されなかったことを通知します。 この場合、成功するまで周期的に再試行されます。
通常保管用コマンドは既存の保管済みファイルの上書きを行わないように設計されます。 これは、管理者のミス(例えば2つの異なるサーバの出力を同一の保管用ディレクトリに送信してしまうなど)といった場合から保管状況の整合性を保護するための安全策として重要です。 実際に既存のファイルを上書きしないこと、かつ、その場合に非0のステータスを返すことを確認するために使用する保管用コマンドを試験することを勧めます。 一部のプラットフォームではcp -iがこれを正しく行うこと、他のプラットフォームでは行わないことがわかっています。 選択したコマンドだけではこうした状況を正しく扱えない場合は、保管済みファイルが既存かどうかを検査するコマンドを追加しなければなりません。 例えば、以下のようなコマンドは、ほとんどのUnix系のプラットフォームで正しく動作します。
archive_command = 'test ! -f .../%f && cp %p .../%f'
保管設定の設計時には、操作者の介入が必要な状況のため、または、保管場所の容量不足のために保管用コマンドが繰り返し失敗した時に何が起こるかを検討してください。 例えば、オートチェンジャ機能の無いテープに書き出している場合に発生する可能性があります。 テープがいっぱいになった場合、テープを交換するまで保管を行うことができなくなります。 こうした状況を相対的に早く解消できるように、適切に操作者に対しエラーや要求を確実に連絡できるようにしなければなりません。 この状況が解消するまで、WALセグメントファイルはpg_xlog/ディレクトリ内に格納され続けます。
サーバのWALデータの生成に要する平均速度に追いついている限り、保管用コマンドの処理速度は重要ではありません。 保管プロセスが数回失敗したとしても通常の操作は続けられます。 保管処理の失敗がかなり多くなると、災害時に損失するデータの量が増加することになります。 また、これはpg_xlog/ディレクトリ内に多くの保管処理待ちのセグメントファイルが格納され、ディスク容量が不足する状況になる可能性があることを意味します。 保管処理が確実に意図通りに動作しているかを監視することを推奨します。
現在の状態まで正しく復旧できることを目的とするのであれば、現在のまだ完了していないWALセグメントも確実にどこかにコピーできるように追加処理を行う必要があります。 WALセグメントが完了し保管できるようになるまでに長時間かかることになりますので、生成されるWAL流量が小さな(、もしくはWALへの書出し速度が低速な)サーバでは特に重要です。 これを扱う方法の1つは、定期的(毎分間隔かもしれません)に現在のWALセグメントファイルを識別してどこかに安全に保存するジョブをcronで設定することです。 保管済みWALセグメントとこの保存した現在のセグメントを組み合わせることで、確実に現時点から1分以内の状態まで復旧できるようになります。 現在、この振舞いはまだPostgreSQLに組み込まれていません。 これは、内容が異なる同じWALファイルを連続的に保管することを仕様とすることによって、archive_commandの定義が複雑になることを避けたいためです。 archive_commandは、WALセグメントが完了した時にのみ呼び出されます。 また、失敗のための再試行の場合は例外ですが、指定されたファイル名に対しては1度のみ呼び出されます。
保管用コマンドを作成する時、保管されるファイル名は64文字長まで、ASCII文字と数字とドットが含まれることを前提としてください。 元の完全パス(%p)を記憶する必要はありませんが、ファイル名(%f)を記憶する必要はあります。
WAL保管によってPostgreSQLデータベースでなされた変更は全てリストアすることができますが、設定ファイルはSQL操作ではなく手作業で変更されますので、設定ファイル(postgresql.conf、pg_hba.conf、および、pg_ident.conf)になされた変更までリストアしないことに注意してください。 通常のファイルシステムバックアップ手続きでバックアップされる場所に設定ファイルを保持する方がいいでしょう。 設定ファイルの設置場所を変更する方法については項16.4.1を参照してください。
ベースバックアップの作成手順は比較的簡単です。
WAL保管が有効であり、正常に動作することを確認してください。
データベースにスーパーユーザとして接続し、以下のコマンドを発行してください。
SELECT pg_start_backup('label');
ここでlabelは、バックアップ操作を一意に識別する時に使用したい任意の文字列です。 (推奨方法は、格納先のバックアップダンプファイルの完全パスを使用することです。) pg_start_backupは、バックアップ情報を持つbackup_labelという名前のバックアップラベルファイルを、クラスタディレクトリ内に作成します。
このコマンドを実行した時にクラスタ内のどのデータベースに接続したのかは注意する必要はありません。 この関数が返す結果は無視できますが、エラーが発生した場合は作業を進める前に対応してください。
tarやcpioなどの使い慣れた任意のファイルシステムバックアップツールを使用して、バックアップを実行してください。 この作業時に、データベースの通常の操作を停止することは不要ですし、望ましい方法でもありません。
再度、スーパーユーザとしてデータベースに接続し、以下のコマンドを発行してください。
SELECT pg_stop_backup();
これは正常に終了するはずです。
バックアップ中に使用されたWALセグメントファイルを通常のデータベース運用時にアーカイブされたら、完了です。
pg_start_backupから実際のバックアップの開始時刻までの経過時間やバックアップの終了時刻からpg_stop_backupまでの経過時間は特に気にする必要はありません。 数分の遅れは何も問題ありません。 しかし、これらの操作を順番に、重なることなく実施することについて十分に注意する必要があります。
バックアップダンプに、データベースクラスタディレクトリ(例えば/usr/local/pgsql/data)以下にある全てのファイルが含まれていることを確認してください。 このディレクトリ以下に存在しないテーブル空間を使用している場合、注意して、同様にそれらを含めてください。 (そして、バックアップダンプがリンクとしてシンボリックリンクを保存していることを確認してください。 さもないとリストアはテーブル空間をだいなしにしてしまいます。)
しかし、クラスタディレクトリのpg_xlog/サブディレクトリにあるファイルをバックアップダンプから省くことができます。 これは多少面倒ですが、リストア処理中の失敗の危険性を低減できますので、行う価値があります。 pg_xlog/がクラスタディレクトリ外のどこかを指し示すシンボリックリンクの場合は調整が簡単です。 これは性能上の理由でよく使用される設定です。
このバックアップを使用可能にするには、ファイルシステムバックアップ中およびそれ以降に生成された全てのWALセグメントファイルを保持しなければなりません。 これを助けるために、pg_stop_backup関数はバックアップ履歴ファイルを生成し、WAL保管領域に保存します。 このファイルの名前は、バックアップを使用可能にするために保管しなければならない最初のWALセグメントファイルに因んで付けられます。 例えば、最初のWALファイルが0000000100001234000055CDの場合、バックアップ履歴ファイルは0000000100001234000055CD.007C9330.backupといった名前になります。 (このファイル名の2番目の数値はWALファイル内の正確な位置を意味します。これは通常無視できます。) ファイルシステムバックアップとバックアップ中に使用されたWALセグメントファイルを(バックアップ履歴ファイル内で指定された通りに)安全に保管した後、これより前の番号を名前に持つ保管済みWALセグメントはファイルシステムバックアップから復旧させる時に不要ですので、全て削除することができます。 しかし、データが復旧可能であることを完全に確実になるように、いくつかのバックアップセットを保持することを検討すべきです。 pg_stop_backupの実行とファイルシステムバックアップの一貫性を維持するために必要なすべてのWALセグメントファイルの保管の間に遅延がありますので、完全なWALセグメントファイルが保管されることのみを心がけてください。
バックアップ履歴ファイルは単なる小さなテキストファイルです。 ここには、pg_start_backupに付与したラベル文字列とバックアップの開始時刻、終了時刻が含まれます。 関連するダンプファイルの保管場所を識別できるようにラベルを使用した場合は、この履歴ファイルを保管することで、リストアが必要になった時にどのダンプファイルをリストアすればいいかが判ります。
最後のベースバックアップまで遡ることができる全ての保管済みWALファイルを保持する必要がありますので、ベースバックアップの実行間隔は通常、保管済みWALファイルを展開するための格納領域がどれだけあるかによって決定されます。 また、復旧処理に費やすことができる時間がどの位許されるかについても考慮しなければなりません。 復旧が必要になった時に、システムはこれらのセグメントを全て再生する必要がありますが、最後のベースバックアップからの経過時間が長ければその分再生に時間がかかります。
また、pg_start_backup関数がデータベースクラスタディレクトリ内にbackup_labelという名前のファイルを作成することに注意してください。 これは、その後、pg_stop_backupによって削除されます。 当然ながら、このファイルはバックアップダンプファイルの一部として保管されます。 バックアップラベルファイルには、pg_start_backupに付与したラベル文字列とpg_start_backupが実行された時刻、最初のWALファイルの名前が含まれます。 従って、混乱した時にバックアップダンプファイルの中身を検索し、そのダンプファイルがどのバックアップセッションに由来したものかを確認することができます。
postmasterが停止している時にバックアップダンプファイルを作成することも可能です。 この場合、判りきったことですが、pg_start_backupやpg_stop_backupを使用することができません。 そのため、どのバックアップダンプが、どのWALファイルと関連し、どこまで戻せばいいかを独自の方法で残さなければなりません。 通常は、上述のオンラインバックアップ手順に従う方をお勧めします。
さて、最悪の事態が発生し、バックアップから復旧する必要がでてきたものとします。 以下にその手順を説明します。
もし稼動しているのであればpostmasterを停止してください。
もし容量があるのであれば、後で必要になる場合に備えてクラスタデータディレクトリ全体とテーブル空間を全て一時的な場所にコピーしてください。 この予防措置は、既存のデータベースを2つ分保持できるだけの空き領域を必要とします。 十分な領域がない場合でも、少なくともクラスタデータディレクトリ以下のpg_xlogディレクトリの内容だけはコピーしなければなりません。 ここには、システムが停止する前に保管されなかったログファイルが含まれているからです。
クラスタデータディレクトリ以下、および、使用中のテーブル空間の最上位ディレクトリ以下にある既存の全てのファイルと副ディレクトリを削除してください。
バックアップダンプからデータベースファイルをリストアしてください。 ファイルが正しい所有権(rootではなくデータベースシステムユーザです!)でリストアされていることを確認してください。 テーブル空間を使用している場合は、pg_tblspc/内のシンボリックリンクが正しくリストアされれいることを検証する必要があります。
pg_xlog/内にあるファイルを全て削除してください。 これらはバックアップダンプから生成されたものであり、おそらく現在のものより古く使用できないものです。 pg_xlog/をまったく保管していなければ、再作成してください。 また、同様にpg_xlog/archive_status/というサブディレクトリも確実に作成してください。
手順2で退避させた未保管のWALセグメントファイルがあるのであれば、pg_xlog/にコピーしてください。 (問題が発生し、始めからやり直さなければならない場合に未変更のファイルが残るように、移動させるのではなくコピーすることが最善です。)
復旧コマンドファイルrecovery.conf(Recovery Settingsを参照) をクラスタデータディレクトリに作成してください。 また、一時的にpg_hba.confを編集し、復旧完了を確認できるまで一般ユーザが接続できないようにする必要があるかもしれません。
postmasterを起動してください。 postmasterは復旧モードに入り、必要な保管済みWALファイル群の読み込みを行います。 復旧処理が完了したら、(偶然にクラッシュしてしまったとしても再度復旧モードに入らないように)postmasterはrecovery.confの名前をrecovery.doneに変更します。 その後通常のデータベース操作を開始します。
データベースの内容を検査し、希望する時点まで復旧できていることを確認してください。 復旧できなかった場合は手順1に戻ってください。 全て問題なければ、ユーザが使用できるようにpg_hba.confを正常状態に戻してください。
ここで重要となるのは、復旧コマンドファイルを設定することです。 このファイルで、どのように復旧させたいのかやどこまで復旧させたいかを記述します。 recovery.conf.sample(通常はインストレーションのshare/ディレクトリに格納されています)をプロトタイプとして使用することができます。 recovery.confで絶対に指定しなければならないことは、保管済みWALファイルセグメントからどのように戻すかをPostgreSQLに通知するrestore_commandです。 archive_command同様、これはシェルコマンド文字列です。 ここには、対象のログファイルの名前で置換される%fやログファイルのコピー先を示す絶対パスで置換される%pを含めることができます。 コマンド内に%文字自体を埋め込む必要があれば%%と記載してください。 最も簡単でよく使われるコマンドは以下のようなものです。
restore_command = 'cp /mnt/server/archivedir/%f %p'
これは事前に保管されたWALセグメントを/mnt/server/archivedirディレクトリからコピーします。 当然ながら、もっと複雑なものを使用することができます。 例えば、操作者に適切なテープをマウントさせることを要求するようなシェルスクリプトでさえ可能です。
このコマンドが失敗した時に非ゼロの終了ステータスを返すことが重要です。 このコマンドは、保管場所に存在しないログファイルを問い合わせるかもしれませんが、その場合でも非ゼロを返さなければなりません。 これはエラー状態ではありません。 また、%pのファイル名部分は%fと異なることに注意してください。 ですので、これらが相互に置き換え可能であるとは考えないでください。
保管場所で見つけられなかったWALセグメントはpg_xlog/から検索されます。 これにより、最近の未保管のセグメントを使用することができます。 しかし、保管場所から利用できるセグメントはpg_xlog/内のファイルよりも優先的に使用されます。 システムは保管済みファイルから取り出す時に既存のpg_xlog/の内容を上書きしません。
通常は利用可能な全てのWALセグメントを使用して復旧処理が行われます。 これは、データベースを現在まで(利用可能なWALセグメントで得られる限り現在に近い時点まで)リストアします。 しかし、すこし過去の時点まで(例えば経験不足のDBAが主トランザクションテーブルを削除してしまう直前まで)復旧させたい場合、単にrecovery.conf内で要求する停止時点を指定してください。 停止時点は、"recovery target"として既知の停止時点で指定することも、日付と時刻で指定することも、完了した特定のトランザクションIDで指定することもできます。 本書の執筆時点では使用するトランザクションIDの識別を補助するツールがありませんので、ほとんどの場合は日付と時刻による指定のみを使用することになるでしょう。
注意: 停止時点はバックアップの終了時刻(つまり、pg_stop_backupの時刻)よりも後の時点を指定しなければなりません。 あるベースバックアップを使用してそのバックアップを行っている最中の時点まで復旧させることはできません。 (こうした時点まで復旧させるには、その前のベースバックアップまで戻って、そこからロールフォワードしてください。)
以下の設定は、recovery.confでのみ設定可能であり、リカバリ期間にのみ適用されます。 これは、その後に行う実行するリカバリ毎に再設定しなければなりません。 リカバリが始まった後に変更することはできません。
WALファイル群の保管済みセグメントを取り出すために実行するシェルコマンドです。 このパラメータは必須です。 文字列中の%fは全て保管場所から取り出すファイル名で置き換えられ、%pは全てサーバ上のコピー先の絶対パスで置き換えられます。 コマンド中に%文字そのものを埋め込むには%%と記述してください。
このコマンドで重要な点は、成功した場合にのみ0終了ステータスを返すことです。 このコマンドは保管場所に存在しないファイル名を問い合わせることがあります。 問い合わせがある場合は非ゼロを返さなければなりません。 以下に例を示します。
restore_command = 'cp /mnt/server/archivedir/%f "%p"' restore_command = 'copy /mnt/server/archivedir/%f "%p"' # Windows
このパラメータはリカバリ処理をどこまで行うかを示す時刻を指定します。 多くても1つのrecovery_target_timeとrecovery_target_xidを指定することができます。 デフォルトでは、WALログの終わりまでリカバリします。 また、正確な停止時点はrecovery_target_inclusiveによって変わります。
このパラメータはリカバリ処理をどこまで進めるかを示すトランザクションIDを指定します。 トランザクションIDはトランザクションの開始時に順番に割り当てられますが、トランザクションの終了はこの順序通りではないということに注意してください。 リカバリされるトランザクションは、指定したIDより前にコミットされたトランザクションです。(オプションで指定したIDを含めることもできます。) 多くても1つのrecovery_target_xidとrecovery_target_timeを指定することができます。 デフォルトでは、WALログの終わりまでリカバリします。 また、正確な停止時点はrecovery_target_inclusiveによって変わります。
指定したリカバリ対象の直後で停止する(true)か、リカバリ対象の直前で停止する(false)かを指定します。 そのリカバリで指定されたrecovery_target_timeにもrecovery_target_xidにも適用されます。 これは、対象コミット時刻やIDに正確に一致したトランザクションをそのリカバリに含めるかどうかを示します。 デフォルトはtrueです。
どの時系列でリカバリを行うかを指定します。 デフォルトはベースバックアップを取得した時点と同じ時系列に従ってリカバリが行われます。 このパラメータは、ポイントインタイムリカバリの後に達した状態に戻さなければならないような複雑な再リカバリ時にのみ設定する必要があります。 詳細は項22.3.4を参照してください。
過去のある時点までデータベースを復旧できる機能は、サイエンスフィクション物語の時間旅行やパラレルワールドに類似した、多少の複雑性があります。 例えば、データベースの元の歴史で、火曜日の夕方5:15PMに重要なテーブルを削除したとします。 慌てずに、バックアップを取り出して、火曜日の夕方 5:14PMの時点にリストアし、データベースを起動させます。 データベース世界のこの歴史では、そのテーブルを削除していません。 しかし、後になって、結局これは大した問題ではなかったことが判ったと仮定すると、元の歴史におけるもう少し後まで戻したいと考えました。 データベースは既に起動していますので、一連のWALセグメントファイルの一部は上書きされているかもしれません。 この場合、元に戻したい時点よりも未来の時点まで進んでしまっていますので、戻すことはできません。 ですので、本当ならば、ポイントインタイムで復旧させた後に生成された一連のWAL記録と元のデータベースの歴史において生成されたWAL記録とを区別する必要があります。
こうした問題を扱うためにPostgreSQLには時系列という概念があります。 一連のWALの終了時点より以前の時点を指定して復旧させた時に毎回、その復旧後に生成されたWAL記録を識別するための新しい時系列が生成されます。 (しかし、WALの終了時点までの全てを復旧処理した場合は新しい時系列は開始されません。 既存の時系列を拡張するだけです。) 時系列ID番号はWALセグメントファイル名の一部です。 ですので、新しい時系列はこれまでの時系列で生成されたWALデータを上書きしません。 実際、多くの異なる時系列を保管することができます。 不要な機能と考えるかもしれませんが、命綱になることがしばしばあります。 どの時点まで復旧すればいいか確実でないといった状況を考えてみてください。 その時は、過去の歴史からの分岐点として最善の時点を見つけるために、試行錯誤して何度もポイントインタイムの復旧を行う必要があるでしょう。 時系列がないと、この手続きはすぐに管理不能な混乱を招いてしまいます。 時系列を使用して、後で中断した時系列分岐における状態を含む、過去の任意の状態に復旧させることができます。
新しい時系列が生成される度に、PostgreSQLは、どの時系列がいつどこから分岐したかを示す"時系列履歴"ファイルを作成します。 この履歴ファイルは、複数の時系列を含む保管場所から復旧する時にシステムが正しいWALセグメントファイルを選択できるようにするために必要です。 従って、履歴ファイルは、WALセグメントファイル同様にWAL保管領域に保管されます。 履歴ファイルは(巨大になるセグメントファイルとは異なり、)単なる小さなテキストファイルですので、安価かつ適切に無期限で保管できます。 必要ならば、履歴ファイルにコメントを追加し、この特定の時系列がどのように、なぜ生成されたかについて独自の注釈を付与することができます。 特にこうしたコメントは、実験の結果多種の時系列へのチケットがある場合に有用です。
復旧処理のデフォルトは、ベースバックアップが取得された時点の時系列と同一の時系列に沿った復旧です。 別の子時系列に沿って復旧させたい(つまり、復旧試行以降に生成されたある状態に戻りたい)場合はrecovery.confで対象の時系列IDを指定しなければなりません。 ベースバックアップより前に分岐した時系列に沿って復旧することはできません。
本書作成時点では、オンラインバックアップ技術には複数の制限があります。 将来のリリースでは修正されるはずです。
B-tree以外のインデックス(ハッシュ、R-tree、GiSTインデックス)に対する操作は現在WALログに残りません。 従って、再生してもこうしたインデックス方は更新されません。 推奨する回避策は、復旧処理が終わった後に手作業でそうしたインデックスそれぞれに対してREINDEXを行うことです。
ベースバックアップの実行中にCREATE DATABASEコマンドが実行され、さらに、そのベースバックアップがまだ終わらない内にCREATE DATABASEでコピー元としたテンプレートデータベースが変更された場合、復旧時にこの変更が作成されたデータベースにも伝播される可能性があります。 当然これは伝播されては困ります。 こうした危険を避けるために、ベースバックアップ中はテンプレートデータベースへの変更を行わないことが最善です。
CREATE TABLESPACEは、絶対パス文字列付きでWALに記録されます。 そのため、テーブル空間の生成は同じ絶対パスで再生されます。 これは、ログを異なるマシンで再生する場合は望まないことかもしれません。 同一マシンで再生する場合でも、データディレクトリを新しくしている場合は危険であるかもしれません。 再生すると元のテーブル空間の内容が上書きされてしまうためです。 こうした潜在する罠を避けるためにもっとも良い方法は、テーブル空間を生成または削除してから新しいベースバックアップを取得することです。
また、ディスクページのスナップショットが含まれているため現在のWAL書式はかなり巨大であることに注意しなければなりません。 これは、部分的に書き込まれているディスクページを修復しなければならない可能性がありますので、クラッシュからの復旧を目的とした場合は適切です。 しかしPITR操作のためには、多くのページの複製を格納する必要はありません。 不要なページの複製を除去し保管済みWALデータを圧縮することを今後の開発目標としています。 現時点では、管理者はできるだけ大きくチェックポイント間隔パラメータを増やして、WAL内に含まれるページのスナップショット数を減らすことができます。