>> 連載トップページに戻る

 

もしもみなみんがDBをクラウドで動かしてみたら

第7回: バックアップ&リカバリ


著者紹介


南野 英梨子 (みなみの えりこ)

日本オラクルに新卒で入社。以来、Oracle Databaseの製品担当として、主にOracle Maximum Availability Architecture(MAA)に関わる機能や製品を担当。特に好きなのは、Oracle Active Data Guard や Oracle GoldenGate。Oracle Database の魅力やベストプラクティス、そしてそれを簡単に使えるOracle Cloudの魅力をお客様に伝えようと、日々邁進中。


第7回: バックアップ&リカバリ

(本内容は、2018/04時点のOracle Cloud Infrastructure Classic - Database Cloud Serviceの情報になります)


今回はDBCSの場合のバックアップ&リカバリについて、ご紹介いたします。

早速本題に入りたいのですが、その前に・・・
3月から、Oracle Database Cloud上でOracle Database 18cが利用可能になっています!

img-1

チェックしていただけましたでしょうか?まだという方は、ぜひOracle Database CloudでOracle Database 18cを触ってみてください。


■1. Oracle Database Cloud Serviceのバックアップとリカバリについて

サービスを利用していくにあたり、利用している環境のインスタンスやデータが壊れてしまった場合や、過去の時点にデータを戻したい場合など、何か起きた時のデータ復旧のためにバックアップやリカバリについての検討は重要です。ですが、設計や運用の考慮が後回しになりがちなものの1つが、バックアップ・リカバリだったりもします。

バックアップを取得していないケースとしては、「テスト環境等でバックアップを取得する要件はない」「(コールド・バックアップしかできない手法で検討)データベースを停止できない」「バックアップ・ウィンドウが確保できない」といったことがあるかと思います。
とはいえ、やはりデータが壊れてしまうと作業や業務継続ができなくなり、どんなシステムでも影響は少なからずあります。こういったことから、バックアップをとるという面では「オンラインでとれること」「バックアップを素早くとれること」「簡単にとれること」が大事になってきます。

バックアップの本来の目的は、バッカアップをとること自体ではなくシステムをきちんと復旧できることです。
一刻も早い復旧が求められているにも関わらず、すぐに戻せないケースは少なくありません。よくあるケースとしては、「リカバリを想定した運用や手順が用意されていない」「復旧作業時のオペミスが発生し、リカバリに失敗」「いざ戻そうと思っても使えないバックアップだった」といったものがあります。そういったことからも、リカバリ面では「簡単に復旧ができる」「きちんと戻せるバックアップ」が大事になります。

Oracle Databaseのバックアップ・リカバリ手法としては、これらのことを考慮されたOracle Recovery Manager(RMAN) を使ったバックアップ・リカバリが推奨です。DBCSをはじめとしたOracle Database Cloudは、RMANを利用して自動バックアップが利用可能で、リカバリもPoint in Time Recovery(PITR)で任意の時点まで復旧もできます。

取得先は、ローカル(インスタンスにアタッチされているブロック・ストレージ上)とリモート(Oracle Database Backup Serviceを利用したオブジェクト・ストレージ上)に設定可能です。この自動バックアップ設定を利用することで、ベストプラクティスに沿ったRMANの設定やスケジューリングが自動で構成され、オンラインバックアップやリカバリをGUIやREST APIなどで簡単に実行することができます。

RMANのメリットや詳細は、ぜひ下記連載・資料をご参照ください!


■2. DBCSのバックアップ方法

まずは、DBCSのサービス・インスタンスを作成する際の自動バックアップの構成方法をみてみましょう。

設定可能な構成としては、下記のいずれかになります。

  • 1. クラウド・ストレージとローカル・ストレージ両方
  • 2. クラウド・ストレージのみ
  • 3. なし

今回は、自動バックアップを設定したいので、1もしくは2のいずれかを選択しましょう。

img-2

ここで入力する内容は、クラウド・ストレージのアクセス情報=オブジェクト・ストレージ(Storage Service)のアクセス情報になります。クラウド・ストレージ・コンテナには、事前に作成したものを指定することも可能ですが、「クラウド・ストレージ・コンテナの作成」にチェックを入れると、指定した名前をもとに自動で新規作成してくれます。

自動バックアップを構成すると、データベースの関連ファイルはRMANによりフルバックアップ + 日次増分バックアップが取得されます。これらは、すべてオンラインで実行されるため、サービス・インスタンスやデータベースは停止されずに行われます。

img-3


■3. DBCSのバックアップの設定

自動バックアップでは、RMANによるデータベースのバックアップだけでなく、DBCSインスタンスの復旧時に必要となるデータベースやOSの設定に関連するファイルもtarで取得されます。対象のファイルは、/home/oracle/bkup配下にある設定ファイルで定義されており、データベース関連はdbcfg.spec、OS関連はoscfg.specで確認・変更可能です。 参考)

自動バックアップで取得されたバックアップは、ローカル・ストレージには7日分、リモートのクラウド・ストレージには30日分が保持されます。

img-4

保持される期間(Retention Policy)』は、RMANコマンドではなくbkup_apiを利用して変更が可能です。
RMAN設定を含む関連情報の更新が必要になりますので、マニュアルにしたガタイbkup_apiを使いましょう。

参考)
バックアップの保存期間のカスタマイズ

自動バックアップが実行される時間は、サービス・インスタンス作成時には23時~3時の間でランダムに設定されます。実際には、/etc/crontabにて時間が設定されているので、時間を指定したい場合にはrootユーザーで変更可能です。

参考)
自動バックアップ頻度のカスタマイズ

スケジューリングされた自動バックアップだけではなく、ユーザーの任意のタイミングでバックアップも可能です。

img-5

コマンドラインで行う場合には、rootユーザーでシングル・インスタンスの場合にはbkup_apiを利用します。

# /var/opt/oracle/bkup_api/bkup_api bkup_start

RACの場合には、opcユーザーでraccliを利用します。

$ raccli create backup

利用期間が長くなればなるほどバックアップファイルも増えていくため、管理のためにタグを利用する人も少ないと思います。デフォルトではタグはタイムスタンプが使われますが、コマンドラインで実行する場合には明示的に指定可能です。保存期間を過ぎてもキープされる月次バックアップに対して、"monthly"というタグを付ける場合のコマンドが下記になります。

# /var/opt/oracle/bkup_api/bkup_api bkup_start --keep –-tag=monthly

■4. DBCSのデータのリカバリ方法

リカバリは、最新までか任意の時点に戻すことが可能です。任意の時点は、時間指定もしくはSCN(System Change Number)を指定します。

img-6

これだけで、RMANによるリカバリが行われます。すごく簡単ですね!

コマンドラインで行う場合には、rootユーザーでシングル・インスタンスの場合にはdbaascliを利用します。

# dbaascli orec --args -latest

RACの場合には、opcユーザーでraccliを利用します。

$ raccli create recovery -latest

■5. まとめ

今回は、DBCSのバックアップ・リカバリについてご紹介しました。

リカバリをする必要があるケースは様々ですが、私自身、必要となる状況の時には多少なりとも気持ちに焦りが生じます。普段から、自身で設定した定期バックアップやバックアップファイルのチェックのスケジューリング、設定復旧手順の用意もしていますが、いざ復旧する際にはそのスクリプトでいいのか、何度も見直してしまいます。バックアップもリカバリも、検討・設計は念入りになるものです。それらがベストプラクティスに沿った内容で設定・実行され、復旧作業のオペミスによる二重障害を防ぐためにも簡単に復旧できるのは嬉しいですよね。

今回は、同じサービス・インスタンス内でのリカバリ方法についてのみ触れましたが、Object Storageにバックアップを取得していると、取得しているバックアップを様々な目的で活用することが可能です。次回以降で、他のユースケースについても触れていきたいと思います。