本当にどの時点にもリカバリできるの?最適なバックアップ手法は“写真 or ビデオ”で考えよう!

本当にどの時点にもリカバリできるの?最適なバックアップ手法は“写真 or ビデオ”で考えよう!

データベース基盤と管理の「それって本当?」――スペシャリストが真実を暴く　その４

そのシステム、今のバックアップ要件で本当に「思い通りに」戻せますか？　実は、一般的なバックアップ設計では、思い通りには戻すことができない場合があります。今回は、ふいに発生したアクシデントに対応する方法を、運動会の「ビデオ撮影」と「写真」を題材にじっくり考えてみましょう。

　こんにちは。日本オラクルの佐々木です。　Oracle Databaseのバックアップ＆リカバリといえば、皆さんご存じの「Recovery Manager（RMAN）」がありますね。一般的なストレージのバックアップ機能などと比べて、「データベースのバックアップ」ならではの機能を持ち、「いざという時にリカバリできない」といったリスクなく

運用できる特徴があります。ただし、システム要件によっては、さらに別の選択肢を検討した方がよい場合もあります。　ここでは、より高いシステム保護要件が必要な場合にも対応するバックアップ＆リカバリソリューションがどういったものなのかを紹介していきます。

ご存じですか？ バックアップと 「あの失敗」には同じ落とし穴があるんです　皆さん、バックアップ＆リカバリの重要性についてはもうご存じですよね？ Oracle Databaseであれば、「RMAN」を利用することで、データブロック破損などのリスクなく、データベースの挙動を理解した安全なバックアップとリカバリを実現できます。　RMANでも十分にオラクルのテクノロジーを活用したリカバリは実現できるのですが、高度なリカバリを検討する場合には、もう1つ、検討したい要素があります。　それは「戻したい任意時点のデータに戻せるか？」という点です。RMANを使ったバックアップ＆リカバリでも十分なケースが多くありますが、「バックアップは定期的にしか取ることができないので、障害の種類によっては戻りたい時点まで戻れない」という特性があります。この点が、皆さんが保護したいシステムのバックアップ＆リカバリ要件にマッチしているかどうかは十分に考慮しておく必要があります。　こう説明しても、すぐにはピンと来ないかもしれません。例えば、お子さんの運動会などを思い浮かべてみてはどうでしょうか？　運動会の徒競走で猛然とスタートダッシュを切ったわが子。そのまま独走かと思いきや数メートル駆けたところで足がもつれて転倒。もうダメかと思ったら、敢然と立ち上がって猛烈に追い上げ 1 位でゴール。練習で「どうなるか分からない」と言っていたわが子、本番でまさかこんなドラマを演じるとは──。

アクシデントにどう対応するか　バックアップとリカバリの関係を考える上では、徒競走で起こる「アクシデントにどう対応するか」は考えるヒントになります。　親にとっての最重要ミッションは子どもの走る姿をカメラやビデオカメラで記録し、本人や運動会に参加できなかった祖父母などに見せてやること。事前に結果は分かりません。もちろん走っている最中に何が起こるかも分かりません。そのような不確実性が高い世界で、突然発生する出来事を全て記録するなら、カメラ（写真）がいいのでしょうか、それともビデオカメラ（動画）がいいのでしょうか？　カメラであれば、走っている場面のどこかのシーンは撮影できます。転んだシーンやゴールシーンなどの「決定的瞬間」を撮影できるかもしれ

ません。ただ、転ぶことは想定していないでしょうし、一位でゴールテープを切ることも想定していないかもしれません。そのために、ちょうどいいタイミングの写真がなかった、ということもありえます。これがもしビデオカメラだったら、スタートからゴールまで全てのシーンを記録しているので、好きなシーンをあとから振り返って見ることができますね（図 1）。　実は、この話で出てくるカメラは「RMANとNetwork Area Storage（NAS）を使った一般的なバックアップ運用」と似ているんです。そう、RMANはカメラのように「事前に決めた瞬間に戻す」ことができる優秀なバックアップ＆リカバリツールなのですが、ビデオカメラのように「後から好きなところに戻す」ものではありません。　オラクルにはビデオカメラに相当する、いつの地点にでも戻せる「Zero Data Loss Recovery Appliance」（以降 Recovery Appliance）というバックアップ＆リカバリツールがあります。「事前に決めた瞬間に戻す」と「後から好きなところに戻す」――似ているようで違うこの 2つの違いを具体的に説明していきましょう。

「事前に決めた瞬間に戻す」で十分ですか？　バックアップは、「決まった時間に戻す」ことを前提に設計されていることがほとんどでしょう。しかし、例えば次のような点が課題となる可能性があります。

（1）データ損失のリスク　通常のバックアップでは「最後のバックアップ以降の全データを失うリスク」が考えられます。　日次で通常のバックアップ運用を実施している場合について考えます。本番データベースのデータファイル、REDOを失うような障害が発生すると、直近のバックアップを使ってリストア・リカバリすることになりますが、リカバリに使えるREDOログがないため、バックアップ取得時点以降の変更データを失うことになります。取得しているはずのアーカイブ REDOのバックアップが取れていなかった、消してしまっていたというのもこのケースに当たります。　先ほどの例えで言えば、転倒したときの写真を撮ったために、1位でゴールテープを切る瞬間の写真を取り損ねてしまったという状況です。お父さん、果たしてこの状況で家に帰られるのか心配ですね。

（2）頻繁なバックアップ取得による本番系の負荷問題　では、バックアップを頻繁に取得するとどうなるでしょう？　いくら短くして

日本オラクル 佐々木 亨

図 1　ビデオカメラで記録しておけば、後からでも好きなところの映像を見ることができる

1着でゴールスタート 転倒

どの時点のデータでも後から見られる

決定的瞬間を後から見返せない可能性

カメラ（写真）の場合

ビデオカメラの場合

も、バックアップの取得間隔分のデータを失う可能性は残ります。カメラの例でいえば、いくら連続でシャッターを切っても、良い瞬間の写真が撮れるとは限りませんね。　また、頻繁にバックアップを取得することで、本番環境に対するCPU、I/O、ネットワークの負荷が増大します。このように、休みなく動くことが求められる最近のシステムをどう効率的にバックアップするかは大きな課題です。

（3）データベースを正常に復旧できないリスク　また、ストレージ装置の機能などでバックアップを行っている場合は、リカバリで正しく期待した通りにデータが戻る保証はありません。Oracle Database インスタンスを介してバックアップを取るRMANのような製品ではない場合は、最悪の場合、バックアップデータの破損により、障害から復旧できない可能性があります。　先ほどの例えでいえば、ストレージ機能を使ったバックアップは、現像するまで意図した写真が撮れたか分からないフィルムカメラと同じです。フィルムを現像に出してみたら、ブレていたり、ピントが合ってなかったという経験はありませんか。

　こうした課題はどう解消できるでしょうか。

好きな地点にいつでもどこでも データロスなしで戻せる

　さて、一般的なバックアップでは「絶対に守りたいデータ」を保護する際にいくつかの障壁があることがお分かりいただけたでしょうか？　ここからは、データ損失のリスクを中心に、Recovery Applianceがそれぞれどう解決してくれるのかを見ていきます。

（1）更新があるたびにバックアップ、RPOはゼロ　Recovery Applianceの最大の特徴は「ゼロデータロス」であることです。ビデオカメラで一部始終を撮影している状態と一緒で、「抜け漏れなく全てを記録している」ということです。ゼロデータロスをどのように実現しているかを示したのが、図 2です。 　従来型統合バックアップである「NAS」と「Recovery Appliance」とで、日次バックアップを取得している場合をそれぞれ考えてみましょう。先ほどの例を使えば、NASが写真、Recovery Applianceが動画です。　まず、従来型バックアップでは、毎日午前 3時にバックアップを取得

しているとしましょう。そこで、ある日の午後 8時（図中では「現在時刻）と表記）に本番のデータベースで障害が発生してデータを失ったとします。　この障害が本番データベース上のREDOログも消失するような障害の場合、バックアップとして復旧できるのは直前の午前 3時ですから、その日のデータはほぼ全て失われてしまいます。定期的にアーカイブREDOログをNASに退避する運用をしていたとしても、障害発生時に退避できていない情報は失われます。一方、Recovery Applianceの場合、バックアップ装置側にREDOログがリアルタイム転送されているので、障害が起こった午後 8時の直前の状態まで復旧することが可能です。こうした、想定外の事態でも確実なデータ保護ができるのが、Recovery Applianceの強みです。　ここで思い出してほしいのが、運動会でのカメラとビデオカメラの違いです。アクシデントがいつ発生するかはまったく予測がつきません。カメラを使って写真を撮影し続けていても、転んだ瞬間を見計らってうまく撮影できるわけではありませんし、転んだ瞬間を撮影したためにその後のゴールシーンを取り逃すこともあります。一方、ビデオカメラなら、特に何もしなくても、タイムマシンのように転んだシーンにまで正確に戻ることができますし、ゴールシーンも撮り逃すことはありません。従来型バックアップでの運用はカメラ、Recovery Applianceでの運用はビデオカメラというわけです。

（2）バックアップウィンドウの長期化を解消　2つ目の課題に挙げたバックアップをどう効率的に取得するかについては、Recovery Appliance ではフルバックアップの取得が最初の 1回以降は一切不要であるため、劇的に改善します。　転送による負荷、回線増強の手間を考えると、大きなコストメリットが得られることがお分かりいただけるでしょう。

（3）定期的なバックアップ健全性チェックで「確実に」戻せる　また、3つ目課題に挙げていた正常にデータベースを復旧できないリスクについては、Recovery Applianceではバックアップの健全性チェックが定期的に自動で行われます。バックアップファイルが万が一破損している場合はリストア・リカバリする前に気付くことができますし、チェックの際はRecovery Appliance自身のリソースを使うため、データベースサーバのCPUリソース、サーバーとストレージを結ぶネットワークの I/Oは消費されないといったメリットもあります。

従来型統合バックアップNASを利用する場合 Recovery Applianceの場合

本番DB

日次バックアップ

Day203：00

Day103：00 現在時刻

本番DB障害（オンラインREDOもすべて損失）

本番DB障害（オンラインREDOもすべて損失）

REDOログはない取得済み 取得予定

NAS上のバックアップ

本番DB

日次バックアップ

Day203：00

Day103：00 現在時刻

本番DB障害（オンラインREDOもすべて損失）

本番DB障害（オンラインREDOもすべて損失）

REDOログ取得済み 取得予定

RecoveryAppliance上のバックアップ

REDO転送

図 2　REDOログがリアルタイムに転送されているので最新状態までリカバリできる

多様なデータベース環境の バックアップ ＆ リカバリを標準化する

　Recovery Applianceを使うことの利点はもう1つあります。個別システムごとにバラバラに実施する必要があった管理を「1つのプラットフォーム」として統合管理できるようになります。　例えば、Solarisで稼働するOracle Database 11gをストレージ装置Ａにストレージの機能を使ってバックアップするのと、Linuxで稼働するOracle Database 12cをストレージ装置Ｂにストレージの機能を使ってバックアップするのでは、システムのバックアップ要件、バックアップ手順がそれぞれ異なり、個別に管理していたことが多かったと思います。　Recovery Applianceを利用すると、こうしたハードウェア、OS、データベースのバージョンなどの違いを超えて、単一の Recovery

Applianceに統合し、管理することができます。バックアップ統合とリカバリ統合が可能になるのです（図 3）。

絶対に守りたいデータは想定外の アクシデントからもきちんと保護する

　Recovery Applianceでは、RMANの利便性をさらに向上させていることがお分かりいただけたでしょうか？　予期せぬアクシデントにどう対処するか？――事業運営の根幹を担うような最重要データベースシステムにおいて、「想定外」の事態にも対応できるようなバックアップ＆リカバリの体制を整備する際には、ぜひとも検討いただきたい製品なのです。　家族の重要なイベントでも、一生に一度の決定的瞬間を逃すことがないよう、予期せぬハプニングを想定した準備を心がけたいですね。

本当にどの時点にもリカバリできるの?最適なバックアップ手法は“写真 or ビデオ”で考えよう!

本当にどの時点にもリカバリできるの?最適なバックアップ手法は“写真 or ビデオ”で考えよう!

データベース基盤と管理の「それって本当?」――スペシャリストが真実を暴く　その４

そのシステム、今のバックアップ要件で本当に「思い通りに」戻せますか？　実は、一般的なバックアップ設計では、思い通りには戻すことができない場合があります。今回は、ふいに発生したアクシデントに対応する方法を、運動会の「ビデオ撮影」と「写真」を題材にじっくり考えてみましょう。

❶ 「想定外」の事態においてもゼロデータロスを目指す要件ならば Recovery Appliance を選択

❷ Recovery Appliance を使えば保持しているバックアップを使って「確実に」リストア・リカバリができる

❸ バックアップ・リカバリの業務プロセスが複数ある場合は、 Recovery Applianceで製品の差分を吸収し運用コストを削減できる

今回の学び

図 3　単一システムで、あらゆるバージョン・プラットフォームを統一した方式で管理

個別システムごとのバラバラな管理 Recovery Applianceでの統一管理

Oracle Database 11gSolaris

Oracle Database 11gAIX

EMC

Oracle Database 10gHP-UX

HP

IBM

Oracle Database 11gWindows

R

RX

X

S

Oracle Database 12cLinux

X

NetApp

Oracle Database 10gOracle Database 11gOracle Database 12c

EE/SELinux

WindowsSolaris

AIXHP-UX