バックアップさえしていれば本当に完璧なリカバリーができるの？──“カンニング”ではダメ！ 100点のリカバリーを実現する方法を考えよう！：データベース基盤と管理の「それって本当？」――スペシャリストが真実を暴く（3）（2/3 ページ）

[PR／＠IT]

戻せないバックアップはこうして発生する

　そもそも、なぜ「リカバリーできない」という事態が起こるのでしょうか。

　データベース（Oracle Database）では、データブロックと呼ばれる単位（例えば、8KB）でユーザーのデータ（レコード）が管理されています。データベースがこのブロックをディスクへ書き込む際に「正しく書き込まれた」とストレージ装置からデータベース側に応答が戻ってきたとしても、実はその書き込んだブロックがディスク上で論理的に壊れてしまっている、というケースが非常にまれではありますが発生します。原因としては、経年劣化や部品故障によるストレージの物理的な故障もありますが、それだけではありません。

　データベースからディスクの間にはいくつかのソフトウェアやファームウェアが存在し、データブロックを書き込む際にはそれらを全て通過する必要があります。例えば、データベース、ボリュームマネジャー、OS、ドライバー、ストレージのディスクコントローラーやキャッシュなどが考えられるでしょう。このいずれかの層でデータブロックが正常に処理されなかった場合、データブロックの破損が発生してしまいます（図1）。

図1　データが書き込まれる際にはいくつもの層を通過する

　装置やソフトウェアのベンダーが異なれば原因追求はさらに難しくなります。ストレージやデータベースはエンタープライズ向けに提供される信頼性の高い製品ですから、ブロック破損が頻繁に発生するわけではありません。ただ、企業が取り扱うデータ量が爆発的に増えて、より大量のディスクI/O要求を処理するなかで、破損の危険にさらされる頻度は増えてきているように思います。

　ディスクへの書き込み時に発生したブロック破損はデータベースとして使用できない状態に論理的に壊れているだけなので、データベースのブロックの構造を理解しているデータベースが読み出さない限り破損していることに気付けません。つまり、ブロック構造を理解できないストレージ装置では検出不可能であり、正常なデータとして扱われてしまいます。

　さて、このようなブロック破損が発生している状態でストレージ装置のコピー機能を使用したディスクtoディスク（D2D）のバックアップを取得した場合、どうなるでしょうか。D2Dバックアップは正ボリュームのビットの並びを副ボリュームへそのままコピーする非常に便利な機能ではありますが、恐ろしいことに、ブロック破損もそのままコピーされたバックアップが“正しく”取得されてしまうわけです。そのようなバックアップを使用して万一の障害時に本当にリカバリーできる自信はありますか？ また、仮に日次バックアップで2世代を保持していたとしても、1週間前にブロックが破損していれば、修復に必要なバックアップは存在しません。バックアップすることだけに気を取られてしまうと、本来の目的である「確実なリカバリー」ができる仕組みを作ることを見失った意味のないバックアップ運用が実装されてしまうことがあります。

　では、「確実なリカバリー」を念頭にしたバックアップとは何でしょうか。それを解説する前に、まず、ストレージ装置のコピー機能を使用したディスクtoディスク（D2D）のバックアップを図2で見てみましょう。

図2　ストレージ装置のコピー機能を使ったディスクトゥディスク（D2D）のバックアップの仕組み

　D2Dのバックアップは、ボリュームを正副に分けて同期する仕組みです。バックアップ開始時にビットマップを比較して差分データを同期します。表面的には一瞬で同期が完了するように見えますが、バックグラウンドでデータのコピーが行われているので正副の両ボリュームでディスクI/Oが発生していることを知っておいてください。

　さらに、もしもこの同期中に正ボリュームに障害が発生すると、全ての差分データが副ボリュームに同期し終わっていないために、副ボリューム内のデータは中途半端な状態となります。この中途半端なデータが格納されている副ボリュームは、一部のユーザーデータが欠落していることを意味しますし、データベースが正常に動作する保証はありません。正ボリュームも副ボリュームも壊れてしまうという最悪な状況となります。