バックアップのライフサイクルを考える

RTO/RPO要件にバックアップのライフサイクル管理は重要

　今回バックアップのライフサイクルについてお伝えする理由は、これまでに下記のような現場を見たことがあるからです。

1. 利用したいバックアップが存在しない（意図せず削除されていた）
2. 使いたいアーカイブREDOログのバックアップがテープに移動されていたためリストア・リカバリに時間を要した
3. どれが利用したいバックアップセットなのかが分からない

　結局、RTOやRPOを満たすための正しいバックアップ取得やリストアのための仕組みを持っていたとしても、ライフサイクルを適切に管理していなければ上記のように要件を満たすことはできないのです。バックアップのライフサイクル管理は、バックアップ管理用のソフトウェアを使っても実現できますが、RMANを使えば組み込みで便利な機能が提供されています。上記のような課題を解消できるRMANの機能を順番にご紹介していきます。

RMANのバックアップ保存方針によって世代管理を実現可能

　前述の課題の1つ目に関してはRMANのバックアップ保存方針と本連載の第1回でお伝えしたCROSSCHECK、VALIDATEコマンドを用いて解決することができます。ここではRMANのバックアップ保存方針について説明します。バックアップ保存方針には大きく2種類あります。1つが冗長性に基づく保存方針で、もう1つがリカバリ期間に基づく保存方針です。

　冗長性に基づく保存方針を設定する場合は、RMANのCONFIGURE RETENTION POLICYコマンドのREDUNDANCYパラメータ（デフォルト1）で保持する必要のある全体またはレベル0のバックアップの数を指定します。全体またはレベル0のバックアップ数が設定値を超えると、余分なバックアップを不要とみなします。

　例えば、図1のようにREDUNDANCYを2に設定している場合を考えます。日次のフルバックアップ運用を前提として、月曜日から木曜日にフルバックアップを取得したとすると、水曜日のバックアップを取得した時点で月曜日のフルバックアップが不要となります。

　一方で、図2のように週次（日曜日）フル＋日次増分バックアップ運用を前提として、REDUNDANCYを1としている場合だと、日曜日の全体バックアップを取得したあと、前回の日曜日のフルバックアップとそれ以降の月曜日から土曜日までの増分バックアップが不要となります。つまり日曜日の全体バックアップ取得直後は、数日前の時点にはリカバリできない状態になります。

　一方でリカバリ期間に基づく保存方針を設定する場合はCONFIGUREコマンドのRECOVERY WINDOWパラメータで現時点からリカバリ可能ポイントまでの間の日数を指定します。例えば

　RMAN＞ CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS;

　と指定すれば、図3のように現在から7日前までの任意の時点までデータベースをリカバリすることができるようにバックアップを保持します。

　なお、いずれの保存方針に基づく場合でも不要とみなされたバックアップは即時に消されるわけではなく、DELETE OBSOLETEコマンドを実行したタイミングで削除されます。