データベース災害対策は「データ」「時間」「コスト」が鍵
東日本大震災で富士通はFMVを製造している富士通アイソテック（福島県伊達市）が被災した。多数のパソコンや部品が激しい揺れで床に落下するほか、天井のエアコン落下やダクト破損など設備も大きなダメージを受けた。当初は復旧まで数ヶ月を要すると見込まれていたが、実際は2～3週間ですんだ。それまでのBCP対策が功を奏した実例だ。
データベース災害対策で鍵となる項目は「データ」、「時間」、「コスト」。特に大事なのがデータ。致命的な例として東日本大震災での戸籍データの消失をあげた。このときは、役所ごと津波で被災しただけではなく、バックアップまでも水没して戸籍データを消失してしまった。中山氏は「データは喪失してしまうと取り戻すことができない」とデータ保護の重要性を強調した。
それから時間とコスト。これらは兼ね合いでもある。復旧までに必要な時間はどのくらいか。どの時点までデータを戻せるか、戻す必要があるか。またコストはどこでも有限なので、災害対策のためにどれだけコストをかけられるかも計画や実装をする上では重要な観点となる。可能な限り盤石な体制にしておきたいものの、「1000年に1度あるかどうか」など発生の可能性が低いリスクに対して、無尽蔵に予算をあてるわけにはいかないのが現実だ。
データ、時間、コスト。これらを実際のシステム要件と優先度に合わせて設計していくことになる。中山氏はパターン別のデータベース設計例を示した。
例えば商品取引システム。取引会社マスタや商品マスタを参照して取引データが蓄積され、そこから売上が集計されるというパターン。この場合にはマスタや直近の取引をまず先に復旧する必要がある。それまでのバックアップがあるデータ、集計など再作成できるものは後回しにしてもいい。
すぐに復旧しなくてはいけないデータは「遠地のデータベースに複製を作成」しておくようにする。具体的にはデータベース機能を用いてログを遠地の副系データベースの転送して反映することで常に複製を作成しておくのだという。（ミラーリング）。後から復旧してもいいデータは「遠地にバックアップとして退避」する。なおログとは「差分データ管理簿」と中山氏は説明する。製品により呼称は異なるものの、更新履歴を記録したもので定期的なデータバックアップ以降のデータを復旧するのに欠かせないものだ。
富士通のSymfowareなら、データ復旧の優先度ごとにグループを割り当て、ログの複製やバックアップなど運用方法を分けることができる。例えばグループAは復旧の優先度が高いため遠地の副系データベースにログを転送・反映し、グループBはログを遠地にバックアップ、グループCは別データから再作成可能なので遠地バックアップはしないといった具合に分類する。
サーバーの冗長化も定番かつ有効な手段だ。運用系（本番系）サーバーのハードウェアが故障したら待機系サーバーに切り替えるクラスタ方式（共用ディスクのデータベースを待機サーバに引き継ぐ）と、データベースをミラーリングして異常時にはサーバーとデータベースをまるごと切り替えるミラー方式がある。ミラー方式ではデータを確実に保護でき、かつ高速に切り替えることができる。
