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

なぜデータベースのバックアップを取得するのでしょうか？ もちろん、万一の障害が発生した際にバックアップを使用してリカバリーするためです。では、そのリカバリー計画は確実なものだと自信を持って言えますか？ このような質問をすると、多くの方が「正しいプロセスでバックアップを取得しているから大丈夫」と答えます。しかし、ちょっと待ってください。本当に大切なのは「バックアップを取得すること」ではありません。さて、それはどういうことでしょうか？ 詳しく解説していきます。[運用管理効率化][Oracle Database 12c]

[PR／＠IT]

なぜ「リカバリーできない」という事態が起こるのか。今回は、「カンニング」に例えて解説します

日本オラクル 柴田長

　こんにちは。日本オラクルの“しばちょう”こと、柴田長（しばたつかさ）です。今回は、いざというときに本当に役立つバックアップの考え方について解説します。

　「システム障害に備えてバックアップを取得しておく」。運用管理の世界では当然のこのプロセスも、業務継続の観点で見ると目的と手段が逆転してしまっていることがよくあります。実際にシステム障害が発生した際にはバックアップを使用してリカバリーを試行しますが、ベテランのデータベース管理者（以降、DBA）ならば「リカバリーに失敗してしまうリスク」が潜んでいることを経験的に知っています。ただ、新米DBAのようなリカバリー経験が少ないDBAはそうではないこともありますし、リカバリーの経験がないままベテランになってしまうこともあるでしょう。結果として、「バックアップ」の言葉だけが一人歩きし、「リカバリーすること」が目的であったのにもかかわらず、その目的を達成するための手段の1つである「バックアップを取得する」ことが目的であるかのように誤解されてしまうのです。

　本来、業務を継続するためのシステムのバックアップであるはずなのに、いざというときに正しくリカバリーできず、業務影響が拡大してしまった――。意外かもしれませんが、お客さまから多く寄せられる声です。こうした問題は前述の通り、バックアップすることが目的であると間違った認識をした場合によく発生する問題です。

　バックアップを取得する運用をしていたが、あるファイルだけバックアップを取得できていなかった。バックアップ設計のミスにより、お客さまのリカバリー要件をそもそも満たしていなかった。これらは、「確実なリカバリー」という目的を見失ったままバックアップを取得することで満足してしまっていることが要因です。特に見落としがちなのは、データ破損に気付かずにバックアップを取得している場合です。本当にリカバリーが必要なタイミングでバックアップにデータ破損が含まれていてリカバリーに使用できない事実を初めて知ることになります。これではバックアップの意味がありません。当たり前ですが、少しでも元に戻せない部分があるバックアップはバックアップとはいえません。リカバリーは「常に100点」でなくてはならないのです。

「結果を見てからでは遅い」のは、試験もバックアップも一緒

　こんな例で考えてみてはいかがでしょう。

　試験に合格するための対策を考えている学生がいます。彼はどうにかして落第を避けたいのですが、まったく勉強をしていません。考え抜いた末、彼は「カンニング」という手段に出ました（もちろん不正です）。試験の時に隣に座っていた優秀そうな学生の答案をのぞき見して丸写しすることで、なんとか自分の答案用紙を埋めてその場をしのいだ「つもり」でした。しかし、優秀に見えた隣の学生も実は全く勉強していなかったとしたら……？

　「合格」を実現するためにすべきだったのは、言うまでもなくカンニングではなく、試験の傾向と対策を理解し、きちんと勉強することです。しかしながら、本来の目的である「合格（リカバリー）」を見失い、あたかも「答案用紙を埋める（バックアップ）」ことを目的と誤認したがために、本来の目的の実現を何も保証しない不正行為を働いてしまいました。彼は間違った手段を選択したばかりに、いざというときに望みの結果にならない、という最悪の事態になってしまったのです。

　コピーした元データがメチャクチャだった――。採点結果が出た後に間違いだと気付いても、試験結果は覆せません。データベースのバックアップも同じです。リカバリー後にバックアップデータが壊れていたことに気付いても、元には戻せません。