バックアップ・リカバリの考え方についてまとめてみた #oracle

はじめに

本番環境で稼働しているWebアプリケーションについて、システムバックアップやデータバックアップを取得していると思いますが、障害が発生したり、ランサムウェアの被害があったなどでリカバリが必要となった際に、実はバックアップがきちんととれていなかった、バックアップは取得していたが、バックアップの取得方法が悪く、リストアしても復旧できなかったという話を聞く事があります。

せっかくコストをかけて構築・運用していたバックアップが、いざという時に使えなかったのでは、あまりに残念過ぎるため、Oracle Databaseのデータとファイルシステム上に保管されているファイルデータが存在するサーバーのバックアップ・リカバリの考え方について、まとめてみようと思います。

バックアップ方法を検討するために考慮すべき点(要件の確認)

どのような方法でバックアップを取得すればよいのかを決めるには、以下のような点について考慮、検討する必要があります。

どのような障害からの復旧を想定するか
- アプリケーションデータ(Oracleデータ、ファイルデータ)の障害
- OS、ミドルウェアの障害
- ランサムウェアやウィルスによる被害
- ハードウェア(サーバー、ストレージ)障害
- 大規模災害
バックアップ要件、リカバリ要件
- バックアップ可能な時間帯(どの位の時間でバックアップが取得できる必要があるか)
  - バックアップ取得時にシステム停止が可能か
  - バックアップ対象のデータサイズはどの位か
  - バックアップ対象のファイル数、ディレクトリ数(階層)はどの位か
  - システム間のデータ連携など、システム運用上の制約
- RPO(目標復旧時点)
  - バックアップ取得時点
  - 障害発生直前
- RTO(目標復旧時間)
  - 数時間(これより短時間での復旧が必要な場合、バックアップ以外に可用性を高める仕組みを検討)
  - 1日など
  - バックアップ対象のデータサイズはどの位か
  - バックアップ対象のファイル数、ディレクトリ数(階層)はどの位か
- 保管世代数
  - 1世代
  - 3世代
  - 7世代など
- バックアップサイクル
  - システムバックアップは手動または月次
  - データバックアップは日時　など

システムバックアップとデータバックアップ

バックアップには大きく分けて、システムバックアップとデータバックアップとがあります。
基本的にはどちらも必要となるものではありますが、障害時の利用用途が少し異なるため、まずそれぞれのバックアップの用途について説明します。

システムバックアップ

システムバックアップは、OS障害、ハードウェア障害、ランサムウェアなどによる障害において、復旧時間を短くするために取得します(取得していないと、全て再セットアップおよび検証が必要になる)。

WindowsUpdateやカーネルのアップデートなど、大きなシステム変更の前にシステムバックアップを取得しておき、変更により万が一システムの動作がおかしくなった場合に、切り戻しできるようにする目的でも利用されます。

そのため、システムバックアップの取得は、定期的に取得するというよりは、大きな変更の前後などに手動で取得する事が多いのではないかと思います(もちろん、定期的に取得する運用の環境もあり)。

また、データバックアップに比べ、システムバックアップの方がデータサイズが大きくなる事もあり、保管世代数も3世代程度が多いのではないかと思います(沢山残してもよいが、コスト削減の為定期的に削除する事が多い)。

システムバックアップ取得は、必ずOracleなどのアプリケーション関連のミドルウェアなどを全て停止してから行います。

停止せずにシステムバックアップを取得すると、リストアしてもアプリケーションが正常に動作しない場合があります。

オンプレミス環境では、バックアップソフトを利用したり、Windows Server バックアップなどのOSの機能、ストレージのスナップショット機能などを利用してシステムバックアップを取得します。

AWS環境ではAMIの取得、OCIではカスタムイメージの作成がシステムバックアップに相当します。

システムバックアップに限らず、データバックアップでも同様ですが、取得したバックアップデータは、同一筐体内には保管せず、別筐体のディスクやテープ装置、クラウド環境のオブジェクトストレージ(S3など)などに保管するようにします。

システムバックアップからリストアする場合は、RPO(目標復旧時点)はシステムバックアップ取得時点になります。

システムバックアップからの復旧が必要な障害が発生した場合、復旧までに数日かかる場合もありますが、RTO(目標復旧時間)が数分など短い場合は、バックアップの仕組みだけでなく、HA構成にするなど、可用性の高い別の仕組みと組み合わせる必要があります。

データバックアップ

データバックアップは、アプリケーションデータのバックアップです。
一般的なWebシステムでは、RDBなどに保管されているデータ、ファイルシステム上のファイルデータなどが対象です。

バックアップ取得時にシステム停止が可能かや、RPO(目標復旧時点)、RTO(目標復旧時点)により、必要となるバックアップの方法が異なります。

データバックアップは、アプリケーションのバージョンアップや大きな設定変更の前後に取得する事もありますが、基本日次で取得します(要件によっては、数時間毎に取得する場合も)。

保管世代数も様々で、アプリケーション運用の都合により、3世代程度の場合もあれば、1か月分のデータを保管するような場合もあります。

データバックアップにおいては、バックアップ取得時にアプリケーション(システム)を停止する事ができるか(オンラインバックアップが必要か)、バックアップ対象データのサイズなど(バックアップ処理が可能な時間帯で終わるか)により取り得る手段や必要となるコストが大きく変わります。

オンプレミス環境の場合、後からバックアップ方式を変更したり、ハードウェアの増強、追加などを行う事は実質難しいため、環境構築前の要件確認と設計・検証が重要になります。

AWS環境では、EBSスナップショットを取得する事でオンラインでのバックアップを取得する事ができますが、RDBが動作しているようなEC2インスタンスでは、EBSスナップショットだけでは正しくバックアップが取得できない(データの整合性がとれず、リストアしてもRDBが起動しない場合がある)ため、静止点をとってバックアップするような仕組みと組み合わせるなどの対応が必要になります。

バックアップ、リカバリ要件に対して必要な手段

Oracleデータ、ファイルデータの障害からの復旧以外、基本的にシステムバックアップもデータバックアップもどちらも必要になります。

なお、システムバックアップもデータバックアップも、バックアップ対象データがある筐体とは別のバックアップメディア(別サーバー、ストレージ、テープ、クラウドのオブジェクトストレージなど)に保管するのが大前提です。

RTOの要件が厳しい場合、復旧にかかる時間短縮のために、最新のバックアップは、外部のバックアップメディアだけでなく、ローカルディスクにも出力する場合もあります。

更に、ランサムウェア等の被害からの復旧を考慮する場合は、サーバーからファイル共有可能な場所にバックアップデータを保管しないようにする必要があります。

コストの兼ね合いなどから、どちらかだけ取得するようにしたいと言われる場合がありますが、その場合は最低限データバックアップを日次で取得するようにします。

ただし、ハードウェア障害などが発生した場合は、ハードウェア設定、OSインストール・設定、ミドルウェア、アプリケーションのインストールなどを1から全てやり直した後、データだけ最新のバックアップの状態に戻す事になります。

蛇足ですが、バックアップには保険的な要素がありますが、重要なデータを扱うシステムであればある程、万が一に備え、妥当な保険(バックアップ)をしっかりかけておく必要があります。

どのような障害からの復旧を想定するか

想定する障害から復旧させるために、システムバックアップ、データバックアップの必要有無(基本的にはどちらも必要)と、復旧方法の概要を記載します。

想定する障害	システムバックアップ	データバックアップ	復旧方法
Oracleデータ、ファイルデータの障害	-	必須
OSの障害	必須	必須	・OS、ミドルウェアはシステムバックアップから、アプリケーションデータはデータバックアップから復旧
ランサムウェアやウィルスによる被害	必須	必須	・OS、ミドルウェアはシステムバックアップから、アプリケーションデータはデータバックアップから復旧 ※バックアップデータはファイル共有可能な場所に置かないようにする前提
ハードウェア障害	必須	必須	・故障した部品などの交換などにより、ハードウェア障害から復旧させる・OS、ミドルウェアはシステムバックアップから、アプリケーションデータはデータバックアップから復旧
大規模災害	必須	必須	・リアルタイムレプリケーション、バックアップデータの災対サイトへの転送などにより、本番環境と災対サイトとでデータの同期がとれる仕組みがある前提・大規模災害発生時は、同期済みデータの状態で、災対サイトのシステムを起動し、DNSの設定更新などによりシステムを災対サイトに切替

バックアップ取得にかかる時間、リストアにかかる時間(RTO)に影響する条件と選択肢

バックアップ対象のデータサイズが大きい場合、ファイルシステム上のファイル数が多い、ディレクトリ階層が深い場合、バックアップ方法によっては、バックアップ取得やリストアにかかる時間が長くなってしまう場合があります。

バックアップ、リストアにかかる時間に影響するバックアップ・リストア手段には、大きく以下の2パターンがあります。

バックアップソフト、Windows Server バックアップなどのOS機能を利用
ストレージのスナップショット機能を利用

どういった条件の場合に、どちらの手段を選択したらよいのか、目安を以下に記載します。

1. バックアップソフト、Windows Server バックアップなどのOS機能の利用を検討

バックアップ対象データサイズが小さい(100GB以下程度)
1ディレクトリに保管されているファイル数が少ない(～1000程度)
ディレクトリ階層が浅い(最大5～7階層程度)

バックアップ対象データが、上記条件を満たす場合は、バックアップソフトやOS機能など、ファイルシステムにアクセスするような手段でのバックアップを検討します。

2. ストレージのスナップショット機能の利用を検討

バックアップ対象データサイズが大さい(100GB以上)
1ディレクトリに保管されているファイル数が多い(1000以上)
ディレクトリ階層が深い(最大5～7階層以上)

バックアップ対象データが、上記条件を満たす場合は、バックアップソフトやOS機能など、ファイルシステムにアクセスするような手段では、バックアップやリストアに時間がかかる事が懸念されるため、ストレージを用意し、ストレージのスナップショット機能などの利用を検討するようにします。

特に、データサイズが数百GB以上あるような場合は、ストレージの機能を利用したバックアップが、ほぼ必須になるのではないかと思います。

なお、Oracleデータの簡易的なデータバックアップ用途として、expdpを利用してOracleのdumpファイルを出力する場合がありますが、データサイズが100GB以上になると、expdpに大幅に時間がかかるようになるため、Recovery Manager(以下、RMAN)を使うか、静止点をとり、データベースファイルなどをストレージのスナップショット機能で取得するようにします。

AWS環境の場合
AWS環境の場合、どちらの条件においても取り得る手段は、AMIの取得かEBSボリュームのスナップショット取得になるかと思います(システム停止が可能かどうかで選択)。

ただし、データサイズが大きくなると、AMIやスナップショットの取得にも時間がかかる場合があるので、その場合は取得間隔を短く(差分を少なく)するなどの工夫が必要になる場合があります。

バックアップデータサイズが大きい場合や、ディレクトリ数が多い、ディレクトリ階層が深い、1ディレクトリ内のファイル数が多いなどの特徴がある場合は、ファイルシステムへのアクセスが遅くなるため、バックアップソフトやOSの機能を利用した場合、バックアップにかかる時間、リストアにかかる時間が大きくなり、実用に耐えられない可能性があります。

差分だけバックアップを取得するような機能があるソフトもありますが、差分をチェックするためにファイルシステムにアクセスするのに時間がかかるため、ディレクトリ階層が深かったり、ファイルやフォルダ数が多い場合には、十分なパフォーマンスが得られない可能性があります。

システムバックアップに限らず、データバックアップにおいても同様ですが、このような特徴があるシステムの場合は、多少高価になりますが、専用のストレージを用意し、ハードウェアのスナップショット機能などを利用してバックアップを取得するようにします。

データバックアップ取得時にシステム停止が可能かによる選択肢

システムバックアップの場合、システム(アプリケーション関連サービス)停止が必須ですが、データバックアップの場合、システム停止が可能かにより必要となる手段が変わります。

■バックアップ時のシステム停止が可能な場合
【Oracleデータ】
システム停止が可能な場合、Oracleデータの取得方法として、以下のような選択肢が考えられます。
(ただし、2のdump出力は補助的な手段であるため、1と組み合わせて運用するのが望ましい)

アプリケーションおよびOracleのサービス・プロセスを停止後、バックアップソフトやOS機能、ストレージのスナップショット機能により、バックアップメディアにデータベースファイルをコピー(オフラインバックアップ)
アプリケーションのサービスを停止後、expdpでOracleのdumpファイルを出力し、バックアップソフトなどにより、バックアップメディアにコピー
AWS環境であれば、インスタンスを停止してAMIの取得、もしくは、アプリケーションおよびOracleのサービス・プロセスを停止後、EBSスナップショットの取得

【ファイルデータ】
システム停止が可能な場合、ファイルデータの取得方法として、以下のような選択肢が考えられます。

アプリケーションのサービス・プロセスを停止後、バックアップソフトやOS機能、ストレージのスナップショット機能により、バックアップメディアにファイルデータをコピー
AWS環境であれば、インスタンスを停止してAMIの取得、もしくは、アプリケーションのサービス・プロセスを停止後、EBSスナップショットの取得

■バックアップ時のシステム停止ができない場合
【Oracleデータ】
システム停止ができない場合、Oracleデータは静止点をとって取得する必要があります。
また、アーカイブログモードでの運用が必須になります。

Oracleデータをオンラインで取得する方法には、大きく分けてRMANを利用する方法、BEGIN BACKUP～END BACKUPコマンドで静止点を取ってバックアップする方法とがあります。

RMANにより、バックアップセットをバックアップメディアに直接出力、もしくはバックアップセットをローカルディスクに出力した後、バックアップソフトやOS機能、ストレージのスナップショット機能などによりバックアップメディアにコピー(不要となるアーカイブログの削除は、RMANコマンドでのバックアップと合わせて実行)
BEGIN BACKUP～END BACKUPコマンドで静止点を取り、データベースファイルおよびアーカイブログをバックアップソフトやOS機能、ストレージのスナップショット機能などによりバックアップメディアにコピー(バックアップ取得後、不要となったアーカイブログをRMANコマンドにより削除)

この2つの方法は、Scriptを記述してcronなどで実行する事もできますが、バックアップソフトによっては、オプション機能を利用する事で、RMANなどのコマンドをバックアップソフトから実行する事もできます。

※ただし、上記に対応していないバックアップソフトもあるので、バックアップソフトのエディションやオプションの内容について、十分な確認が必要です。

バックアップ取得後、アーカイブログやオンラインREDOログファイルが破損すると、障害発生直前まで復旧する事ができなくなりますが、日次のオンラインバックアップの他、アーカイブログを短い間隔でバックアップメディアにコピーしておく事で、障害発生時に、障害直前まで復旧できる可能性を高める事ができます。

AWS環境の場合、EC2インスタンスでは、1または2で取得したバックアップを別EBSボリュームに退避し、バックアップを保管しているEBSボリュームのスナップショットを取得するなど、少し工夫が必要になります。場合によっては、RDS for Oracleの利用なども検討した方がよいかもしれません。

OCIの場合は、DB Systemsを利用する事で、Oracleデータのオンラインバックアップを簡単に取得する事が可能です。

AWSのRDS for Oracleには、Multi-AZという機能があります。
本番AZにあるOracleのデータを別AZにレプリケーションしてくれる機能ですが、ストレージのブロックの変更をレプリケーションする機能であるため、本番AZのデータが破損すると、破損したブロックが別AZにも伝播してしまいます。
そのため、バックアップ用途ではなく、RDSのホスト基盤などのメンテナンス時におけるシステムダウン時間の低減(可用性アップ)を目的に利用を検討するのがよいのではないかと思います。

【ファイルデータ】
システム停止ができない場合、基本的にはバックアップソフトなどを利用してバックアップメディアにバックアップするしかありませんが、OS機能やバックアップソフトでバックアップする場合、バックアップのタイミングでファイルがOpenしていたりすると、バックアップしてもファイルが破損してしまう場合があります(バックアップソフトによっては、Openファイル対応をしているソフトもあるので、必要に応じて選択肢に入れるとよいと思います)。

バックアップソフトやOS機能、ストレージのスナップショット機能などにより、バックアップメディアにファイルをコピー
ストレージなどのレプリケーション機能により、別ストレージにリアルタイムレプリケーションし、別ストレージからバックアップメディアにバックアップ
AWS環境の場合、EBSボリュームのスナップショットを取得。EFSの利用など。

RPOにより取り得るバックアップ方法の選択肢

システムバックアップからのシステム復旧におけるRPOは、直近のシステムバックアップ取得時点になりますが、データバックアップにおいては、障害発生直前まで復旧させる事を目標とする場合があります。

その際に取り得る手段は、■バックアップ時のシステム停止ができない場合に記載した手段と同じになります(以下に再掲します)。

【Oracleデータ】
※アーカイブログモードでの運用が必須。

RMANにより、バックアップセットをバックアップメディアに直接出力、もしくはバックアップセットをローカルディスクに出力した後、バックアップソフトやOS機能、ストレージのスナップショット機能などによりバックアップメディアにコピー(不要となるアーカイブログの削除は、RMANコマンドでのバックアップと合わせて実行)
BEGIN BACKUP～END BACKUPコマンドで静止点を取り、データベースファイルおよびアーカイブログをバックアップソフトやOS機能、ストレージのスナップショット機能などによりバックアップメディアにコピー(バックアップ取得後、不要となったアーカイブログをRMANコマンドにより削除)

更に必要に応じて、日次のオンラインバックアップの他、アーカイブログを短い間隔でバックアップメディアにコピーしておく。

【ファイルデータ】

バックアップソフトやOS機能、ストレージのスナップショット機能などにより、バックアップメディアにファイルをコピー
ストレージなどのレプリケーション機能により、別ストレージにリアルタイムレプリケーション
AWS環境の場合、EBSボリュームのスナップショットを取得。EFSの利用など。

※ただし、オンラインでのバックアップ取得になるため、ファイルが破損する場合あり。

バックアップ手段毎のリストア方法

システムバックアップからのリストア

バックアップソフトやOS機能、ストレージのスナップショット機能などを利用し、バックアップメディアからファイルを元のディレクトリ以下に戻してリストアします。

ただし、OSのインストールメディアが必要であったり、NICやパーティション設定が必要になるなど、何を利用してシステムバックアップを取得したかにより、リストア前に必要な作業が異なります。

一例として、Windows Server バックアップを利用して取得したシステムバックアップからのベアメタル回復手段について、参考までにリンクを記載します。

ファイルデータのリストア

アプリケーションのサービスを停止した状態で、バックアップソフトやOS機能、ストレージのスナップショット機能などを利用し、バックアップメディアからファイルを元のディレクトリ以下に戻してリストアします。

Oracleデータのリストア・リカバリ

バックアップ手段により、リストア・リカバリ方法が異なります。

バックアップ方法	リストア・リカバリの流れ(概要)	復旧時点
expdpによるdump出力	・復旧させるアプリケーション用のOracleスキーマ(ユーザー)を再作成・dumpをimpdpで再作成したスキーマにImport	dump出力時点
データベースファイルをオフラインバックアップ	・Oracleインスタンスを停止・(壊れたファイルを含む)データベースファイルを削除または別ディレクトリに退避・バックアップメディアから直近のデータベースファイルを元の場所にリストア・Oracleインスタンスを起動	オフラインバックアップ取得時点
BEGIN BACKUP ～ END BACKUPコマンドで静止点をとりオンラインバックアップ	・Oracleインスタンスを停止・オンラインREDOログファイル以外のデータベースファイルを削除または別ディレクトリに退避・バックアップメディアから直近のデータベースファイルとアーカイブログファイルを元の場所にリストア(ただしオンラインREDOログファイルは除く) ・Oracleインスタンスを起動(起動モードは障害の種類による) ・アーカイブログファイルおよびオンラインREDOログファイルの変更情報を適用しロールフォワード・OracleインスタンスをOpen(必要に応じて一時表領域を再作成)	障害の状況にもよるが、障害発生直前まで戻せる可能性あり
RMANによるフルバックアップ	・Oracleインスタンスを停止・Oracleインスタンスを起動(起動モードは障害の種類による) ・障害の種類によりRMANコマンド(recover databaseなど)を実行してリストアおよびリカバリ(アーカイブログの適用) ・OracleインスタンスをOpen(必要に応じて一時表領域を再作成)	障害の状況にもよるが、障害発生直前まで戻せる可能性あり

おわりに

Oracle Databaseとファイルシステム上に保管されているファイルデータが存在するサーバーのバックアップ・リカバリの考え方について、まとめてみました。

Oracle Databaseのバックアップおよびリカバリの詳細については、別記事に記載したいと思います。