 |
データベースのデータを保護する観点で欠かすことができない，バックアップとリカバリ。データ消失を防ぐためにはバックアップ設計が必要不可欠であり，データベース管理者に限らずシステム管理者であれば当然理解しているだろう。
しかし，最初にバックアップの設計をしてはいけない。最初にしなければならないのは，業務要件を踏まえた上でのリカバリ設計だ。
リストアできないデータは実際にある
ここで強調したいことは，リカバリのためにバックアップが必要であるということである。リカバリに使えないバックアップは無駄以外の何物でもない。だから，ユーザーのシステムがどのように運用され，万一障害が発生したときにどのようにリカバリをすればサービスへの影響が少なく済むのかを検討し，リカバリの要件を先に決める。次に，そのために必要なバックアップ要件を考えるというのが正しいアプローチである（図）。
 |
| 図●リカバリ要件とバックアップ要件 [画像のクリックで拡大表示] |
ところが，リカバリより先にバックアップを設計してしまうケースは意外に少なくないのである。その例を二つ挙げよう。
バックアップ方式を間違えてしまう例
データベース全体のバックアップを取得するフルバックアップ（コールド・バックアップ，あるいはオフライン・バックアップともいう）を夜間バッチで取っているシステムは多いだろう。フルバックアップでリカバリできるのはバックアップを取得した時点までである。フルバックアップはデータベースを停止した状態で取得するため，これを使って障害発生ポイントの直前までリカバリすることはできない。
つまり，業務要件としてデータの欠損が許容できない場合には，このバックアップでは意味がない。この点をカバーするにはアーカイブ運用をしてオンライン・バックアップを取得するといったことが必要となる。これをフルバックアップに組み合わせれば，障害発生ポイントの直前までリカバリすることが可能となる。
復旧までにかかる時間も忘れてはならない。24時間365日止めない運用をしているシステムのデータベースでデータ・ファイルが破損したとしよう。サービス停止許容時間は1時間である。そこでオンライン・バックアップで取得したデータ・ファイルをリストアする。しかし，このデータ・ファイルのリストアに2時間かかってしまう。これでは意味がない。
リカバリに使えないバックアップを取得してしまう例
最近はあまり聞かなくなったが，一昔前の32ビットOSではファイル・システムが扱えるサイズの最大値は2Gバイトが相場だった。データベースの設計の際に，データ・ファイルが2Gバイトを超えないように設計するのが当たり前の世界だった。
その際，リカバリの設計を行っていないシステムだと，論理バックアップ（データベースのデータを外部ファイルとしてエクスポートする）を取得するバックアップ・セットがデータの増大と共に2Gバイトを超えてしまうことがある。この段階でファイルが壊れてしまう。バックアップ・セットが2Gバイトを超えてしまったことに気づかず，いざリカバリを実施しようとしたところで，ファイルが壊れていたことに気づくのである。
データ消失を防ぐという「目的」を達成するには，リカバリが必須である。その「手段」としてバックアップがあることを肝に銘じる必要がある。
|
