前回まではバックアップ方式について見てきましたが、大事なのはそのバックアップを使用してどうリカバリするかです。バックアップを取得してるからといって安心してはいけません。その取得したバックアップで、いざというときに本当にデータを元通り復旧できるのでしょうか。必要なデータが漏れなく含まれていなければ当然元通りにはなりません。また、仮に必要なデータが揃っていても、リカバリに許容されている時間が30分しかないのに、1時間以上かかってしまうのであれば、せっかく取得したバックアップの意味がありません。

• リカバリに許容される時間は？
• 対象としなければらないデータは何か？
• どの時点までリカバリしなければならないのか？

これらリカバリ要件を決めてから、それをインプットにしてバックアップ方式を決めていく必要があるのです。

リストアとリカバリ

リカバリ方式について見ていく前にまずは用語の意味から考えていきます。データベースにおける「リカバリ」と「リストア」の意味はそれぞれ以下のようになります。

上述のとおり、取得したバックアップを使ってデータを復元させることをリストアと言うわけですが、リストアだけでは障害直前のデータに戻すことはできません。

例えば、月曜日の朝8時にフルバックアップの取得が完了し、火～日曜日までは同時刻に差分バックアップの取得を完了させていたとします。仮に、日曜日の15時に障害が発生し、データが消失した場合、バックアップファイルを使って復元できるのは日曜日の朝8時の時点までです。

8時から15時までの間も当然システムは利用されているので、データは更新されます。しかし、バックアップファイルにはその間に変更されたデータは含まれず、元に戻すことはできません。

リストアした後さらに、上述時間分の変更データを元に戻すための作業が必要です。その作業のことを「リカバリ」と言います。

リカバリの方法

しかし、バックアップしてもいないデータを元に戻すことは可能なのでしょうか。実は、DBMS内部にはデータベースに加えられた変更を逐次的に記録したログ(トランザクションログ)が残っています。フルバックアップならびに差分バックアップファイルを反映した状態からさらに、そのトランザクションログを適用してやることで、データを障害直前の状態に戻すことが可能なのです。

このようにトランザクションログを適用して、変更データを反映させることをロールフォワードと言います。

ここまでの作業を行なうことで、晴れて障害直前のデータに復旧できたことになります。

もう一度バックアップ要件を考える

リカバリ作業は上述のとおり、結構大変です。そして、その結構大変な作業を障害によりシステム停止している状態で行なわなければなりません。当然、オペレーションミスは絶対に許されません。そのため、可能な限り、手順を少なく済むような配慮する必要もあるでしょう。

また、バックアップファイルを保存するためのディスク領域についても考えなくてはいけません。ディスク領域が足りず、バックアップに失敗していたと、リカバリ作業中にはじめて気がついた、なんてことにならないよう、事前にどのくらいの領域が必要なのかを見積もっておく必要もあるでしょう。そのためには、バックアップファイルは何世代残しておくのかの検討も必要です。

それらを踏まえ、バックアップの方法、頻度、対象を決めていくことが重要です。