Oracle Databaseのバックアップにおける種類と実施方法。押さえておきたい運用のポイントとは

企業のシステムや業務アプリケーションを安定的に運用するうえで、データベースのバックアップは欠かせない要素です。特に、Oracle Databaseは多くの組織で利用されており、障害やトラブル発生時の復旧に備えたバックアップ戦略の設計が重要となります。

この記事では、Oracle Databaseにおけるバックアップの種類、具体的な実施方法やリカバリ手順、さらに運用上のポイントについて解説します。

なお、データベースを安定的に運用していくためのポイントはこちらの資料をご確認ください。

また、Oracle Databaseにはエディションごとに異なるライセンス体系があります。詳細はこちらの記事をご確認ください。

Oracle Databaseでのバックアップの種類

Oracle Databaseのバックアップは「論理バックアップ」と「物理バックアップ」の2つに分けられます。

論理バックアップ

論理バックアップは、データベースからテーブル・スキーマといった単位でデータを抽出し、保存する方法です。主に、Data Pump（expdp/impdp）や従来のexp/impコマンドを利用します。

取得したファイルは、データ消失時に再度読み込むことで対象のオブジェクトを復旧可能です。また、異なるバージョンのOracleや異なる環境へのデータ移行にも適しています。

ただし、メディア障害や物理的な破損に対しては対応できず、バックアップ取得時点までの状態しか復旧できない点に注意が必要です。

▼論理バックアップの特徴

• テーブル単位やスキーマ単位でのバックアップが可能

• 異なるOracleバージョン間でのデータ移行に便利

• 物理障害やメディアリカバリには非対応

• バックアップ取得時点までしか復旧できない

物理バックアップ

物理バックアップは、データベースを構成する物理ファイル（データファイル、制御ファイル、REDOログファイルなど）を別媒体にコピーして保存する方法です。対象となる物理ファイルはデータファイル・制御ファイル・REDOログファイルなどです。

障害発生時には、バックアップファイルをリストア（復元）し、さらにREDOログを適用することで、障害直前の状態まで復旧できます。

取得方法としては、OSレベルのコピーコマンドのほか、Recovery Manager（RMAN）やEnterprise ManagerなどのGUIツール、さらにはサードパーティ製ツールの利用が挙げられます。自動化やスケジューリングが容易になり、運用効率も向上するでしょう。

物理バックアップはシステム障害やハードウェア障害に強く、データベース全体を完全に復旧できることから、多くのシステムで標準的に採用されています。ただし、バックアップファイル自体の容量や管理方法が運用負荷に直結するため、取得タイミングや設計方針を慎重に検討する必要があります。

▼物理バックアップの特徴

• データベース全体を対象とした完全な復旧が可能

• REDOログを活用することで直前の状態まで戻せる

• RMANやEnterprise Managerなどによる自動化が容易

• バックアップデータの容量・管理が運用上の課題

Oracle Databaseにおけるバックアップの実施方法

Oracle Databaseのバックアップを実施する際は、システムの稼働状況や業務要件に応じて最適な方法の選択が重要です。

ここでは、Oracle Databaseにおける代表的なバックアップの実施方法について解説します。

オフラインバックアップ・オンラインバックアップ

オフラインバックアップは、データベースを停止した状態で物理ファイルをコピーする方法です。

▼オフラインバックアップの特徴

• すべての関連ファイルをリストアすればそのままデータベースをオープン可能

• 復旧手順が比較的シンプル

• 取得時に必ずデータベースを停止する必要があり

• 業務を中断できる時間帯の確保が前提

一方、オンライン（ホット）バックアップは、データベースを稼働させたままバックアップを取得できます。

▼オンラインバックアップの特徴

• 業務を停止させずにバックアップが可能

• リストア後にはリカバリ処理が必要

• ARCHIVE LOG MODE での運用が前提

さらに、オンラインバックアップは Recovery Manager（RMAN） を利用することで、取得やリカバリ作業を自動化・効率化でき、運用負荷を軽減できます。

全体バックアップ・部分バックアップ

全体バックアップは、データベースを構成するデータファイルや制御ファイルをまとめて取得する方式です。障害時には完全なリカバリが可能で、システム全体を一括して復旧できる強みがあります。

一方、部分バックアップは、以下のように一部の対象だけをバックアップする手法です。

• 表領域単位

• データファイル単位

• 制御ファイルのみ

変更頻度の高い領域に絞ることで効率的に運用できますが、利用できるのは ARCHIVE LOG MODE で運用されている環境に限られます。

目的に応じた使い分けとしては、次のように整理できます。

フルバックアップ・増分バックアップ

フルバックアップとは、データファイル内のすべてのブロックを対象に取得する方式です。

• バックアップサイズは大きい

• ただし復旧時にはフルバックアップのみで済むため手順は単純

一方、増分バックアップは「前回のバックアップ以降に更新されたブロックだけ」をコピーする方式であり、以下のメリットがあります。

• バックアップ容量を抑えられる

• 処理時間の短縮やストレージの効率化に優れる

ただしリカバリ時には、フルバックアップに加え必要な増分バックアップを順に適用する必要があり、管理や復旧手順は複雑になります。

このため、システム要件や運用方針に応じて両者を適切に組み合わせて利用することが求められます。

Oracle Databaseのリカバリ方法

バックアップを取得していても、障害発生時に適切なリカバリ方法を理解していなければ、迅速な復旧は困難です。

Oracle Databaseのリカバリ方法は主に3つ挙げられます。

バックアップ時点への復旧

バックアップ時点への復旧とは、取得済みのバックアップファイルを利用し、データベースをバックアップ作成時点の状態に戻す方法です。

データファイルや制御ファイルといったすべての関連ファイルをリストアすることで、障害発生前の安定した環境を再現します。

なお、あくまで「リストアのみ」による復旧であり、バックアップ以降に発生したトランザクションやデータは反映されません。そのため、復旧後にはバックアップ取得時点までしか戻せない点に注意が必要です。

また、オフラインで取得された一貫性のあるバックアップが前提となり、NOARCHIVE LOGモード環境ではバックアップ時点への復旧が唯一のリカバリ手段となります。

最新のデータベースへの復旧

最新のデータベースへの復旧は、バックアップファイルを基盤とし、その後生成されたアーカイブログや最新のREDOログを順に適用することで、障害発生直前の状態まで戻す方法です。

バックアップ取得後に行われた更新内容も反映され、データ損失を最小限に抑えられます。

また、必要に応じて障害のあったファイルだけをリストアし、変更履歴を適用することで効率的に復旧することも可能です。

複数のログを適切な順序で適用する必要がありますが、Recovery Manager（RMAN）を利用すれば複雑な処理を自動化でき、迅速かつ確実なリカバリが実現できます。

過去の特定時点への復旧

過去の特定時点への復旧（ポイント・イン・タイム・リカバリ）は、取得したバックアップに対してアーカイブログやREDOログを途中まで適用することで、任意の時点の状態にデータベースを戻す方法です。

ユーザーの誤操作や不正な更新を取り消したい場合、あるいはREDOログやアーカイブログの一部が失われ、最新の状態まで復旧できない場合に利用されます。

復旧の際には、すべてのデータファイルをリストアしたうえで、指定時点までの変更履歴のみを反映させる必要があります。そのため、障害が発生した一部のファイルだけを対象にした復旧はできません。

なお、ポイント・イン・タイム・リカバリの活用で、業務継続性を保ちながら誤操作の影響を最小限に抑えることが可能です。

Oracle Databaseのバックアップ管理を行う際のポイント

Oracle Databaseのバックアップ管理を適切に行うことで、障害発生時の迅速な復旧や業務継続性の確保が可能です。

Oracle Databaseのバックアップ運用における重要なポイントを3つ紹介します。

RPO・RTOに基づいたバックアップ方法の選択

RPO（Recovery Point Objective：目標復旧時点）とRTO（Recovery Time Objective：目標復旧時間）は、バックアップやリカバリの設計方針を決めるうえの指標として欠かせません。

RPOは「障害が発生した際にどの時点までデータを戻せるか」を示し、許容できるデータ損失量を数値化しています。対して、RTOは「どれだけの時間でシステムや業務を復旧できるか」を表し、業務停止をどの程度許容できるかを測る指標です。

それぞれを明確にすることで、バックアップの方式（フル／増分・オンライン／オフラインなど）や取得頻度、保存先の選定といった実装方針を具体化できます。

例えば、短いRPOを求める場合はバックアップ頻度を高める必要があり、RTOを短縮したい場合はリストアやリカバリの自動化を導入することが有効です。

また、RPO・RTOは一度決めて終わりではなく、システム規模や業務要件の変化に合わせて定期的に見直しを行うことも重要です。

リアルタイム性の高いレプリケーションの実施

バックアップだけでは対応しきれない障害や災害に備えるためには、リアルタイムに近い形でデータを複製するレプリケーション技術の導入が効果的です。

システムで生成・更新された情報を即座に別のサーバーやストレージへ反映させることで、万一の障害発生時にも直前の状態に近いデータを復旧でき、RPO（目標復旧時点）の短縮につながります。

Oracle Databaseでは、Data Guardを利用したスタンバイ環境の構築や、GoldenGateによるトランザクション単位のリアルタイム複製が代表的な手段です。組み合わせることでシステム停止時間（RTO）の短縮とデータ損失の最小化を両立でき、災害対策やBCP（事業継続計画）の強化にも直結します。

ただし、リアルタイムに近い同期は高い可用性を実現する一方で、誤操作や不正な更新も即座に複製されるリスクがあるため、バックアップとの併用や設計上の工夫が求められます。自社の業務要件に応じて、レプリケーションとバックアップをバランスよく組み合わせることが重要です。

データベースのレプリケーションについてはこちらの記事で解説しています。

バックアップ処理の監視

バックアップは取得するだけでなく、処理が正しく完了しているか常に監視することが不可欠です。

定期的な監視を行うことでデータの整合性を検証でき、破損やストレージ障害などの問題を早期に検出できます。結果、リカバリ不能といった事態を未然に防止できます。

Oracle Databaseの運用においては、バックアップジョブの進捗や完了ステータスをモニターし、エラーや警告を検知した際に即座に対応できる仕組みが重要です。ジョブ管理画面や監視ツールでは、処理の成否や詳細ログを確認でき、必要に応じて通知やアラートを自動で発報させることが可能です。

さらに、障害時に迅速に復旧できるかを確認するためには、バックアップの監視とあわせて定期的なリストアテストも実施しましょう。バックアップが「取得されているだけ」ではなく、実際に「復旧可能」であることを継続的に検証できます。

まとめ

この記事では、Oracle Databaseのバックアップに関する以下の内容について解説しました。

• 論理・物理バックアップの種類と特徴

• バックアップの実施方法

• バックアップのリカバリ手順

• バックアップ管理における設計・監視・改善のポイント

Oracle Databaseのバックアップ戦略は、自社の業務要件やシステム構成に応じて設計することが重要です。運用の自動化や監視体制を強化し、定期的な見直しやリストアテストを行うことで、障害発生時にも迅速な復旧を可能にします。

また、バックアップ運用やパフォーマンス監視には専用ツール『MaxGauge』の導入が効果的です。バックアップ処理の監視、障害時のアラート通知、パフォーマンス分析を一元的に管理でき、運用負荷の軽減と安定稼働を実現します。

なお、データベースの観測性を高めることで、障害予兆の検知や運用効率の向上にもつながります。

データベース運用のトラブル対応における“可観測性”については、こちらの資料をご確認ください。