はじめに

データベースには、重要なデータが多く保存されています。企業の財務状況から、私たち個人のプライバシーに関わるものまで、近年ではほとんどありとあらゆるデータがデータベース化されています。もし、そのデータが何かの間違いで消失してしまったら、データベースを管理していた企業やシステム構築を請け負った企業の受けるダメージは計りしれません。

しかし現実には、データ消失のニュースは定期的と思えるぐらい繰り返し報じられます。最近では、クラウドサービスのEvernoteでデータが消え、顧客6,323人に影響を与えた可能性があると報じられた話は記憶に新しいですし、昨年にはMicrosoft傘下の携帯電話向けサービスDangerでもユーザデータが消失する事件が起きました。

こうした障害が発生する原因は、大きく分けて2つあります。1つ目は論理障害と呼ばれるもので、そもそもシステムのロジックに欠陥があって、データを壊してしまうとか、人のオペレーションミスによるデータ損失です。2つ目は、物理障害です。文字通り、サーバやストレージなどハードウェアが物理的に壊れることによってデータが破壊されるケースです。

現在の多くのシステムでは、こうした事故が起きてもデータを失わないよう、冗長化などの手段が講じられていますが、それでもデータ損失の確率をゼロにすることは原理的に不可能です。そのため、そうした不運な場合に備えて、データを復旧できるようバックアップとリカバリの手段を持つことが、堅牢なシステム運営のために必要になります。DBMSもこのためのしくみを持っており、リカバリマネージャというモジュールがこの機能を担います[1]⁠。

本稿では、データベースを中心としたバックアップ／リカバリのしくみについて解説します。特定のDBMSに限定せず、システム全般に適用できる一般的なロジックについて解説していきます。

対象読者

• バックアップ／リカバリのプランを作ることになった人
• 「～バックアップ」という言葉が多過ぎて整理できていない人
• データ損失を経験して痛い目を見たことのある人／または将来そうなりそうな予感のする人

対象環境

• すべてのリレーショナルデータベース

バックアップ

まずは、バックアップの基本的な分類から話を始めます。最初に理解していただきたいのは、バックアップの種類にどのようなものがあるか、という点です。

よくシステム関係の書籍や製品のマニュアルを読むと、「⁠～バックアップ」という用語がたくさん出てきて、最初はそれらの意味や相互の区別を理解するだけでも大変です。しかも、製品ごとに独自の名称が使われていたりして（2ページの表1参照⁠）⁠、理解を妨げられることもよくあります。

しかし、実際のところ覚えるべきものは少なく、基本的な分類は3つしかありません。それ以外の種類については、あとでゆっくり理解すればかまいません。

その3つの種類とは、フルバックアップ（または完全バックアップ⁠）⁠、差分バックアップ、増分バックアップです。この名称は「どんなデータをバックアップするか」という観点から付けられています。

フルバックアップ（完全バックアップ）

一番簡単な、そしてすべてのバックアップの基礎となるのがフルバックアップです。これは文字通り、ある時点でそのシステムで保持されているすべてのデータをバックアップするものです。そのため、このバックアップのファイルさえあれば、その時点のデータをすべて復旧することが可能になります。

これはもしもの話ですが、運用中のバックアップにおいて常にフルバックアップを取ることが可能なら、バックアップの運用は極めて単純なものになります。というのも、上記のように、これさえあればデータ復旧は簡単に終わってしまうからです。

図1のように、月～土曜まで毎日フルバックアップを取得していたとして、日曜に障害が発生したとします。この場合、最新のデータを戻すのに必要なバックアップファイルはFだけです。A～Eの古いバックアップファイルはなくてかまいません。逆に言うと、Fのファイルが壊れてしまった場合には、最新の状態に戻すことはできないため、次善策としてEのファイルを使うことになります（Eも壊れていたらD…とさかのぼります⁠）⁠。

しかし実際のシステムでは、こういう「贅沢な」バックアップ運用を行っていることはまずありません。というのも、フルバックアップには次のような高いコストがかかるからです。

コスト①：バックアップにかかる時間が長い

システム内のすべてのデータをバックアップするため、バックアップに長時間かかります。読み取り専用ファイルなど、変更が発生しないデータを除外することで多少の軽減は可能としても、肝心の業務系データは日々変更されるのが普通のため、バックアップ対象に含めざるを得ません。

コスト.：リソースへの負荷が大きい

バックアップ対象のデータ規模が大きいということは、バックアップ中、データが保存されているディスクに対して大量の読み込み処理を発生させることを意味します。そのため、ディスク、サーバのCPU、さらに、もしネットワーク経由でバックアップする場合にはネットワーク回線まで、バックアップ処理だけで大きくリソースを消費します。そのため、バックアップ中にほかの処理を並行して行うことは現実的な運用ではありません。フルバックアップは、バックアップの中で最もリソースを大きく消費するのです。

コスト.：サービス停止が必要

フルバックアップを取得する場合、一般的にはDBMSなどのソフトウェアをシャットダウンし、サービスを停止させてから行います。これは、データの整合性を保った状態でバックアップを取得しなければならないためです。しかし、頻繁にサービス停止の可能なシステムというのは、それほど多くありません。

このように、フルバックアップはバックアップとリカバリの手順が簡単というメリットがありますが、実行コストが大きいので、これ単独で運用を行うことは現実的に不可能です。本連載の第1回でも述べましたが、「⁠システムの世界にフリーランチ（ただめし）は存在しない」のでしたね。そこで通常は、フルバックアップを基本として、差分バックアップや増分バックアップと組み合わせた運用を行います。

差分バックアップ

差分バックアップ（differential backup）とは、名前のとおり前回のフルバックアップからの変更分だけをバックアップする方法です。

図2を参照してください。たとえば、月曜日にフルバックアップを取得したとすると、火～土までは月曜から変更が発生した分だけのバックアップを取得することになります。具体的には、トランザクションログ（前回参照）をバックアップすることで実現します。トランザクションログには、データベース内のデータに対するあらゆる変更操作の履歴が残っているのでしたね。そのため、これを保管しておくと、データベースに対する変更操作をもう一度再現することが可能になるわけです。

さてそうすると、月曜日から運用を始めて日曜日に障害が起きた場合、最新データを復旧するのに必要なファイルは、「⁠A＋F」となります。Aのフルバックアップのファイルは絶対に必要です。変更履歴のログだけあっても、変更を適用するべき大元のファイルがなくては話になりません。一方、B～Eのファイルは不要です。これらのファイルに含まれているデータはFにすべて含まれているからです。その点で、差分バックアップは冗長なデータをバックアップすることになります。

このように、差分バックアップを利用すると、復旧時の手順が1つ増えますが、その代わり、日々のバックアップに必要なデータは小さくなるため、バックアップに必要な時間が短くなります。その分、リソースへの影響も小さくなります。

増分バックアップ

3つ目のバックアップ方式は、増分バックアップ（incremental backup）です。これは、差分バックアップからさらに無駄を省いてスマートにしたものです。先ほど、差分バックアップのファイルでは、復旧に不要なファイルがたくさんありました。それは、これらのファイルに含まれる情報に同じものが含まれるためです。この冗長性をなくしてやれば、バックアップ対象となるデータはさらに少なくなり、バックアップ時間も短くなります（図3⁠）⁠。

このバックアップ方法の利点は、日々のバックアップ処理が高速に終わることです。3つのバックアップ方式のうち、トータルの処理時間が最も短い方法でもあります。

対して、欠点は2つです。1つは、復旧処理の手順が最も複雑で時間もかかることです。復旧にはA～Fまでのすべてのファイルが必要になります。もう1つは、ファイル破損により復旧できない可能性が最も高いことです。というのも、増分バックアップの場合、A～Fまでのファイルのうち、どれか1つでも壊れていたら、もうそれで復旧が不可能になるからです。

そのため増分バックアップを使用する場合は、バックアップファイルを冗長化しておく、つまりバックアップのバックアップを取ることが必須です。これにはユーザが明示的にバックアップを取ったり、ミラーリングされた媒体で保存するなどの方法があります。

バックアップの分類をまとめる

これまでに出てきた3つのバックアップ方式について、まとめておきましょう（表1⁠）⁠。

時折、書籍やドキュメントにおいて、差分バックアップと増分バックアップの区別があいまいなものを見かけます。あまり両者を区別しないままどちらも「差分バックアップ」という名称で呼ばれていることもありますが、厳密には差分バックアップは、前回バックアップからのデータを累積的に保持する、という点が増分バックアップとの違いです。たとえばDB2は一般的に差分バックアップと呼ばれているものを増分バックアップ（＝インクリメンタルバックアップ）と呼んでいて間違えやすいため、注意してください。

第4のバックアップ方式

ここで、これまでに見てきた3つのバックアップ方式を応用した4つ目のバックアップ方式についても触れておきたいと思います。これは、取得するデータは既存の3つと違わないので厳密には新しい分類というわけではないのですが、統合フルバックアップ（synthetic full backup）と呼ばれる方法です。フルバックアップと差分バックアップ（または増分バックアップ）のファイルを結合して、新たなフルバックアップを作るのです（図4⁠）⁠。

これによって、リカバリ時には新たに作られたフルバックアップ（もどき）のファイル「A⁠’⁠」だけがあればよいため、増分バックアップや差分バックアップの欠点の1つであった、リカバリ時の手順の面倒さが解消されるというわけです。統合処理自体は、バックアップ終了後に独立のサーバとストレージを使って行えばよいので、バックアップ自体の所要時間にも影響を与えません。市販のバックアップ用のソフトウェアにはこの統合機能を持っているものがあるため、利用できる場合には検討してみてもよいでしょう[2]⁠。