1 Oracle Secure Backupの概念

この章では、Oracle Secure Backupを使用したバックアップとリカバリに関連する概念を説明します。

この章の内容は次のとおりです。

Oracle Secure Backupの機能の概要

Oracle Secure Backupは、最も人気のあるLinux、UnixおよびWindowsの各オペレーティング・システムを横断して、Oracle Databaseとファイルシステムのデータをバックアップする、集中化された、ネットワークベースのバックアップ管理アプリケーションです。Oracle Secure Backupは、Recovery Manager (RMAN)とともに使用するSBTインタフェースの働きをします。Oracle Secure Backupでは、Storage Area Network (SAN)およびSCSI環境の、大部分の主要なブランドのテープ・ドライブとライブラリに対するサポートが、日々追加されています。サポート対象ハードウェアの現在のリストは、次のURLにあります。

http://www.oracle.com/technetwork/database/database-technologies/secure-backup/learnmore/index.html

Oracle Secure Backupの使用によって次のことが可能になります。

  • 異種プラットフォーム分散環境における、テープ、ディスク・プールおよびクラウド・ストレージ・デバイスへのバックアップおよびリストア操作の集中管理

    ネットワーク・ファイル・システム(NFS)共通インターネット・ファイル・システム(CIFS)を使用しなくても、ネットワーク内のあらゆる場所からローカルおよびリモートのファイル・システムやテープ・デバイスにアクセスできます。

    関連項目:

    サポートされるコンピュータ・アーキテクチャの詳細は、『Oracle Secure Backupインストレーションおよび構成ガイド』を参照してください。

  • LinuxおよびWindows上における、Oracle Cluster File System(OCFS)対象のバックアップおよびデータのリストア

  • ストレージ・リソースの効果的な使用が可能

    まずディスクにバックアップを格納し、それを定期的にテープ・デバイスに移動することによって、テープ・デバイスのみにバックアップを書き込むことによる競合を低減させることができます。

  • 格納されている全データの暗号化

  • バックアップ対象を指定するためのワイルドカードと除外リストの使用

  • マルチレベルの増分バックアップの実行

  • 同じデータ・ストリームが複数のデバイスに出力される、データベース・バックアップの二重化

    各データ・コピーについて、別々のメディア・ファミリ、テープ・デバイスまたはディスク・プールを指定できます。

  • 複数のボリュームにまたがるバックアップの作成

    ボリュームは、LTO5テープ・カートリッジなどの1単位のメディアを表します。

  • 自動テープ・ドライブ共有によるテープ・リソースの最適化

  • データの迅速なリストア

    Oracle Secure Backupでは、ブロックへの直接位置指定と直接アクセス・リストアを使用することで、ファイル特定のための不必要なテープ・ブロックの読取りを回避します。迅速な取得作業のため、Oracle Secure Backupでは全バックアップ・データのテープ位置の記録がカタログ内に保存されます。

  • セキュリティのメンテナンスと、データ管理権限を持つユーザーの制限

    デフォルトでは、Secure Sockets Layer(SSL)が、管理ドメインでのホスト認証と通信に使用されます。

  • 場所から場所へのメディア・ローテーションの管理

  • ユーザー定義ポリシーによるテープ複製の自動化

  • 最終的に別のコンテナに書き込まれる予定のバックアップ・イメージの仮コンテナとしてディスク・プールを一時的に使用。「バックアップ・イメージ・インスタンスのコピーまたは移動」を参照してください。

  • 個々のコンテナをクラウド・ストレージ・デバイスとして構成することでデータをOracle Cloud Infrastructure Object Storage Classicにバックアップ。『Oracle Secure Backupインストレーションおよび構成ガイド』を参照してください。

  • 適切な圧縮率、バックアップ速度、および使用可能なコンピューティング・リソースに基づいて圧縮の様々なレベルから選択して、バックアップ・データを圧縮。圧縮要件は、バックアップ・ジョブ・レベル、ホスト・レベルまたはドメイン・レベルで設定できます。詳細は、『Oracle Secure Backupリファレンス』で、backupコマンドの--compressionオプションの説明を参照してください。

Oracle Secure Backupの管理上の概念の概要

ホスト・コンピュータを管理ドメインに組織することによって、Oracle Secure Backupは異機種の環境のバックアップとリストア操作を管理します。通常、1つの管理ドメインは、1つの管理サーバー、1つ以上のメディア・サーバー、および1つ以上のクライアントから構成されています。

バックアップまたはリストア操作のリクエストを作成した場合、リクエストに実行の資格が生じると、Oracle Secure Backupはこのリクエストに対応するジョブを作成します。各ジョブに関する情報は、ジョブ・ログ、ジョブ・トランスクリプトおよびジョブ・サマリー内に維持されています。

ポリシーと呼ばれる構成設定を使用して管理ドメインの操作を管理できます。ポリシーは管理サーバーに保持されます。デフォルトを使用すると、構成設定のデフォルト値を提示できます。

Oracle Secure Backupは、ユーザー、権限およびクラスに関する情報を格納することによって、管理ドメイン全体で整合的なユーザー・アイデンティティを維持します。ユーザーに個別の権限を付与したり、クラス(名前付きの権限セット)を割り当てたりすることができます。Oracle Secure Backupは、事前構成済クラスのセットを提供します。

この項には次のトピックが含まれます:

管理ドメインについて

管理ドメインは、バックアップおよびリストア操作を実行するための共通単位として管理する、ホストのネットワークを指します。管理ドメインの各ホストは、次のロールの1つを割り当てられている必要があります。

  • 管理サーバー

    管理サーバーは、ドメイン内のすべてのホストに関する構成情報を含みます。また、バックアップとリストア操作に関するメタデータを含むバックアップ・カタログも格納します。1つの管理ドメインに、管理サーバーは1台のみ存在できます。

  • メディア・サーバー

    メディア・サーバーは、セカンダリ・ストレージ・デバイスが接続されているホストです。セカンダリ・ストレージ・デバイスとの間でのデータの移動を管理します。メディア・サーバーは、SANが接続されたディスク・プールや、スタンドアロンであるか、テープ・ライブラリに含まれているテープ・ドライブに、直接接続できます。

  • クライアント

    バックアップする必要があるデータを含む管理ドメインのホストはすべて、クライアントと呼ばれます。クライアントは、Oracle Databaseとファイルシステムのデータを含むことができます。NDMP NASサーバーや、Linux、Unix、Windowsのホストである可能性があります。データがバックアップされる場合、管理サーバーはクライアントとして機能することもあります。

管理ドメイン内のホストに複数のロールを割り当てることができます。バックアップする必要があるOracle Databaseを含むため、メディア・サーバーはクライアントとしても機能します。バックアップする必要があるデータは、クライアントやメディア・サーバーに存在することがあります。

関連項目:

管理ドメインの詳細や例は、『Oracle Secure Backupインストレーションおよび構成ガイド』を参照してください。

Oracle Secure Backup ホーム: ディレクトリ構造

Oracle Secure Backupは、管理ドメインに関する情報を管理サーバー上のOracle Secure Backupホームにファイルの階層として体系化します。Oracle Secure Backup Homeディレクトリは、ソフトウェアのインストール先です。管理ドメインを定義するファイルは、管理サーバーのOracle Secure Backup Homeディレクトリの構造化された階層に整理されます。

図1-1に、Oracle Secure Backupホームのディレクトリ構造を示します。このディレクトリ構造はすべてのプラットフォームで同じですが、デフォルトのOracle Secure BackupホームはUNIXおよびLinuxの場合は/usr/local/oracle/backup、Windowsの場合はC:\Program Files\Oracle\Backupです。

図1-1 管理サーバー上のディレクトリ

図1-1の説明が続きます
「図1-1 管理サーバー上のディレクトリ」の説明

Oracle Secure Backupのカタログについて

管理サーバーは、管理ドメインに対するバックアップおよびリストア操作に関連するメタデータを保存するカタログを保持します。obtoolまたはWebツールを使用してカタログを参照し、バックアップしたものをレビューしたり、リストアする項目を検索したりできます。

Oracle Secure BackupカタログはRMANとバックアップ・メタデータを共有するために統合されますが、RMANリカバリ・カタログとは別です。RMANリカバリ・カタログはOracleデータベース・ファイルに格納され、RMANとは別個に保持されます。

Oracle Secure Backupは、SBTを介してファイルシステム・バックアップまたはデータベース・バックアップを実行する場合、バックアップするオブジェクトの名前と属性を記録します。このデータは、管理サーバーに格納されているカタログに書き込まれます。各バックアップ・イメージに関連付けられたバックアップ・イメージ・インスタンスに関する情報も格納します。

バックアップ・カタログ: ディレクトリ構造

Oracle Secure Backupは、管理ドメイン内のすべてのクライアントに対して個別のバックアップ・カタログを保持します。各ホストに対するカタログは、クライアント名が付けられたadmin/history/hostのサブディレクトリに保存されます。たとえば、admin/history/host/brhost2には、クライアント・ホストbrhost2というクライアントに対するカタログが保存されます。カタログそのものは、indices.curというバイナリ・ファイルです。

Oracle Secure BackupがRMANバックアップのためにSBTメディア・マネージャのロールで動作する場合、部分データは、sbtpiece.datおよびsbtpiece.idxと呼ばれるディレクトリadmin/state/general/にあるデータベース・ファイルに格納されます。

関連項目:

ユーザー権限の詳細は、Oracle Secure Backupのクラスと権限の概要を参照してください

カタログを参照する際、Oracle Secure Backupでは、データの保存元のクライアントにおけるファイルシステム・ツリーの形式でデータが表示されます。ファイルシステムのルートには、スーパーディレクトリと呼ばれる架空のディレクトリが現れ、これには頂点のファイルシステム・レベルから保存されたファイルとディレクトリがすべて含まれます。Oracle Secure Backupは、カタログに保存されているすべてのトップ・レベルのファイルシステム・オブジェクトにアクセスできる開始ポイントとして、このディレクトリを使用します。

通常、カタログのスーパーディレクトリにはUNIXおよびLinuxシステムのrootディレクトリのみが含まれます。Windowsシステムでは、バックアップを行った各トップ・レベルのファイル・システム(ドライブ文字とコロンで識別される)が含まれます。

Oracle Secure Backupカタログには、各バックアップに保存されたそれぞれのファイルシステム・オブジェクトの記録が含まれます。ディレクトリの存在は暫定的であり、内容も時間経過とともに変わります。たとえば、昨日ディレクトリとしてバックアップされたオブジェクトの名前が、今日のバックアップではファイルを指し、明日のバックアップではシンボリック・リンクを指す可能性もあります。Oracle Secure Backupではオブジェクト・タイプにおけるこのような変更をすべて適宜追跡します。

Oracle Secure Backupのカタログにはバックアップ関連の情報が含まれます。admin/history/hostディレクトリには、管理ドメインのホスト名が付けられたサブディレクトリが含まれます。各サブディレクトリには、カタログ・データを保存するファイルが含まれます。Oracle Secure Backupは、2GB超のカタログ・ファイルをサポートします。このサポートは、2GBを超えるファイルをサポートするオペレーティング・システムおよびファイル・システムに限定されています。

カタログによって消費される領域の量は、ネイティブ・ホストとNDMPホストでは異なります。ネイティブOracle Secure Backupバックアップの場合に、予測されるカタログの増大は、次の3つの要素の合計によってバイト単位で見積ることができます。

  • (新しいファイルおよびディレクトリの数)*(43 +ファイル・リーフ名の平均の長さ)

  • (変更された既存のファイルの数)*(統計レコード用の27バイト)

  • (変更されていない既存のファイルの数)* 0.5

サード・パーティのNDMPファイラをバックアップする場合に、予測されるカタログの増大は、次の3つの要素の合計によってバイト単位で見積ることができます。

  • (新しいファイルおよびディレクトリの数)*(53 +ファイル・リーフ名の平均の長さ)

  • (変更された既存のファイルの数)*(統計レコード用の35バイト)

  • (変更されていない既存のファイルの数)* 0.5

また、NDMPバックアップの場合は、新規、変更済、未変更のいずれであっても、バックアップされるファイルごとに、NDMP位置ファイルで16バイト消費されます。

ノート:

Oracle Secure Backupでは、バックアップ処理中にカタログの一時コピーが作成されます。Oracle Secure Backup管理サーバーの記憶域の計画にあたっては、一時コピーおよびカタログ・アップデートを考慮する必要があります。

Oracle Secure Backupによって、カタログと構成ファイルの内容の保護が自動化されます。インストール時にOracle Secure Backupによって、これらのファイルをバックアップ・コンテナにバックアップするために必要なバックアップ・ジョブのスケジュールが設定されます。たとえばディスク障害によってカタログ・データが失われた場合、最も新しいバックアップ・カタログをリストアし、その後で残りのデータをリストアすることができます。

通常は、構成データやカタログにアクセスするにはobtoolまたはOracle Secure Backup Webツールを使用してください。このようなデータを含むファイルにファイル・システムで直接アクセスしないようにしてください。

関連項目:

Oracle Secure Backupホームのファイルおよびディレクトリの内容の詳細は、『Oracle Secure Backupインストレーションおよび構成ガイド』を参照してください。

テープからのバックアップ・カタログ・データのインポートについて

Oracle Secure Backupは、importvolobtarコマンドを使用する、テープからのバックアップのインポートおよびカタログ化をサポートします。テープ機能でカタログを使用すると、このプロセスがより効率的になります。

Oracle Secure Backup 12.1から、はるかに高速な処理でテープからOracle Secure Backupドメインにバックアップをインポートし、カタログ化できます。その結果、Oracle Secure Backupカタログを参照して、以前は認識されていなかったボリュームから現在の管理ドメインにリストアするファイルを選択することができます。例1-1は、ボリュームをインポートしてカタログ化する方法を説明しています。

ボリュームのカタログ化の結果、バックアップがもともと現在のドメインで作成されたかのように、バックアップに関する情報を表示できるようになりました。

関連項目:

  • importvolおよびobtarコマンドの詳細は、『Oracle Secure Backupリファレンス』を参照してください

  • インポートとカタログ・バックアップの方法の詳細は、カタログ・インポートの管理を参照してください

カタログ・インポートの暗号化について

カタログ・インポートの実行時に、暗号化キーなしでOracle Secure Backupドメインにテープからファイル情報をインポートできます。ただし、リストア操作の実行時に、暗号化キーを持つことが必須です。

新しいOracle Secure Backupドメインの暗号化キーを取得するには、リストアの実行時にパスフレーズ・オプションを指定する必要があります。このオプションは、その後のすべてのリストア操作のリストア・パスフレーズを格納します。

関連項目:

restoreコマンド・オプションの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

例1-1 ボリュームのカタログ化

この例では、Oracle Secure Backupはテープ・ドライブvt1をスキャンして、ボリュームIDをVOL000001としてボリュームをカタログ化します。この例は、ボリューム・セットのすべてのボリュームがOracle Secure Backupボリューム・データベースの一部であると想定しています。

ob> catalog --vid VOL000001 --drive vt1
Info: catalog import request 1 submitted; job id is admin/21.

構成ファイルについて

Oracle Secure Backupの管理データには、バックアップに関連したドメイン規模のエンティティが含まれます。これらは、ユーザー、クラス、テープ・デバイス、ディスク・プールおよびメディア・ファミリを含みます。図1-1に、configディレクトリを示します。サブディレクトリがいくつかあり、その1つ1つが管理ドメインを定義するオブジェクトを表します。各オブジェクト・ディレクトリは、オブジェクトの特性を記述したOracle Secure Backupファイルを含みます。

デフォルトとポリシーについて

Oracle Secure Backup のデフォルトとポリシーは、Oracle Secure Backupが管理ドメインの動作を操作する方法を決定する構成設定です。ポリシーの設定は管理サーバーに保持されます。ポリシー・デフォルトは安全優先で設定されていて、セキュリティを維持するのに十分であり、大部分の企業ネットワーク上でデータを保護します。ただし、特別な要件、環境またはバックアップ戦略がある場合は、インストール時にこれらの設定を検討して、要件を満たすことを確認することをお薦めします。

Oracle Secure Backupのポリシーはいくつかのクラスにグループ分けされます。各ポリシー・クラスには、Oracle Secure Backupの処理の特定の側面に関連したパラメータが含まれます。

ノート:

ポリシーのクラスは、分類のための便宜的なものです。ユーザーのクラスと混同しないでください。

ポリシー・クラスの分類

Oracle Secure Backupのバックアップおよびリストア機能の管理に関連するポリシー・クラスは次のとおりです。

  • バックアップの圧縮ポリシー

    このポリシー(設定されている場合)は、圧縮がホストまたはジョブ・レベルで設定されていない場合に、Oracle Secure Backupクライアントでファイル・システム・バックアップの圧縮に関連した設定を制御します。

  • バックアップ暗号化ポリシー

    このポリシーは、バックアップ・コンテナに書き込まれるバックアップの暗号化を制御します。たとえば、バックアップ暗号化が必須かどうか、キー・サイズ、およびキー管理の方法を指定できます。

  • クラウド・ポリシー

    このポリシーは、ターゲットがクラウド・ストレージ・デバイスの場合、各種操作の動作を制御します。

  • バックアップ・イメージ・インスタンスのコピー・ポリシー

    このポリシーは、バックアップ・イメージ・インスタンスのコピーが作成される方法を制御します。たとえば、コピー・インスタンス・ジョブにデフォルト優先度を指定できます。

  • デーモン・ポリシー

    このポリシーはデーモンとサービスの動作面を制御します。たとえば、ログインを監査するかどうかを指定したり、索引デーモンによるカタログの更新を制御します。

  • デバイス・ポリシー

    このポリシーは、デバイス検出時にどのようにしてバックアップ・コンテナを自動的に検出するかを制御します。テープ・デバイスの書込み警告が生成されるタイミングも制御します。

  • 複製ポリシー

    このポリシーは、Oracle Secure Backupがボリュームの複製を実行する方法を制御します。たとえば、ネットワーク上で複製を実行する必要があるか、1つのローカル・ホストのみで複製を実行する必要があるかを制御できます。

  • 索引ポリシー

    このポリシーはOracle Secure Backupによるカタログの生成および管理を制御します。たとえば、カタログのクリーンアップ間の経過時間を指定します。

  • ログ・ポリシー

    このポリシーは管理ドメインにおけるログイン履歴を制御します。たとえば、管理サーバー上のアクティビティ・ログに、すべて、バックアップのみ、リストア操作のみなど、どのイベントを記録するか指定します。

  • メディア・ポリシー

    このポリシーは管理ドメインにおけるメディア管理を制御します。たとえば、デフォルトのメディア・ファミリのボリュームに対するバーコード・ラベルの取得と保存期間および書込みウィンドウの設定が、テープで必要かどうかを選択できます。

  • ネーミング・ポリシー

    このクラスは、管理ドメインのWindows Internet Name Service (WINS)サーバーのIPアドレスを指定する1つのポリシーを含みます。

  • NDMPポリシー

    このポリシーは、NDMPアクセス・モードを使用し、NDMPデフォルトを指定するホストに適用される設定を制御します。たとえば、バックアップ環境変数を構成したり、認証におけるユーザー名を指定したり、各NDMPサーバーにOracle Secure Backupを認証するために使用されるパスワードを指定したりします。

    コマンドラインまたはコマンド・スクリプトでのクリア・テキストによるパスワードの指定は推奨されません。セキュリティの脆弱性です。推奨される方法は、Oracle Secure Backupユーザーがパスワードの入力要求に応じる方法です。

  • 操作ポリシー

    このポリシーはバックアップおよびリストアの操作面を制御します。たとえば、RMANバックアップ・ジョブが、必要なリソースが使用可能になるまでOracle Secure Backupスケジューラ・キューで待機する時間を設定します。

  • スケジューラ・ポリシー

    このポリシーはOracle Secure Backupスケジューラの動作を制御します。たとえば、スケジューラがバックアップ・ジョブのディスパッチを試行する頻度を指定します。

  • セキュリティ・ポリシー

    これらのポリシーは管理ドメイン・セキュリティの側面を制御します。たとえば、転送中のバックアップ・データに対するSSL暗号化を有効にしたり、ホストのアイデンティティ証明書に対するキーのサイズを設定します。デフォルトのセキュリティ・ポリシーの変更方法は、『Oracle Secure Backupインストレーションおよび構成ガイド』で説明しています。

  • ステージング・ポリシー

    このポリシーは、stagescanジョブの側面を制御します。

  • ボールティング・ポリシー

    このポリシーは、データ保護戦略の一環として、様々な場所でのテープのローテーションなどのメディア管理を制御します。

関連項目:

Oracle Secure Backupのポリシーの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

ジョブとリクエストについて

Oracle Secure Backupでは、バックアップまたはリストアのリクエストはジョブと区別されます。リクエストは、まだ実行準備ができていない、バックアップまたはリストア操作のローカルに保存された指定です。ジョブは、Oracle Secure Backupスケジューラに転送されているリクエストのことで、実行準備ができています。

スケジューラ・ポリシーは、スケジューラによるバックアップおよびリストア・ジョブの処理方法を決定します。スケジューラがジョブをディスパッチする頻度も左右されるため、ユーザーはこの設定を熟知する必要があります。

ノート:

この項ではファイルシステムのバックアップおよびリストア・ジョブについて説明します。データベースのバックアップおよびリストア・ジョブについて学習するには、RMANによるOracle Secure Backupへのアクセス方法を参照してください。

関連項目:

図1-2に、Oracle Secure Backupユーザーがオンデマンド・バックアップまたはリストア・ジョブを作成するプロセスを示します。

図1-2 バックアップおよびリストアのリクエストとジョブ

図1-2の説明が続きます
「図1-2 バックアップおよびリストアのリクエストとジョブ」の説明

図1-2に示されているプロセスのステップは次のとおりです。

  1. ユーザーはファイルシステムのバックアップまたはリストアのリクエストを作成します。たとえば、クライアント・ホストbrhost2上の/homeディレクトリのバックアップに対するリクエストを送信します。

    Oracle Secure Backupは、ユーザーのOracle Secure Backup Webツールまたはobtoolセッションにおけるバックアップおよびリストアのリクエストのキューを保持します。ユーザーはこのキューの参照や変更ができます。ユーザーがセッションを終了すると、スケジューラにまだ送信されていないリクエストは消失します。

  2. 必要に応じて、ユーザーはこのキューのリクエストを変更します。たとえば、ジョブ・リクエストを削除できます。

  3. ユーザーは、管理サーバー上で稼働中のスケジューラ(obscheduled)にバックアップ・リクエストを送信します。

    ファイルシステムのバックアップまたはリストアのリクエストをユーザーがOracle Secure Backupスケジューラに送信すると、そのリクエストはジョブになります。Oracle Secure Backupは各ジョブに、管理ドメイン内のすべてのジョブにおいて一意の名前を割り当てます。

  4. スケジュール時刻になると、サービス・デーモンがジョブを実行します。

ジョブの作成について

この項では、オンデマンドおよびスケジュール済のファイルシステム・バックアップおよびリストア・ジョブの作成方法について詳しく説明します。次のイベントによってOracle Secure Backupではジョブが作成されます。

  • Oracle Secure Backupは、デフォルトでは5分間隔で各バックアップ・スケジュールに定義されているトリガーを検査します。その日に起動する各トリガーについて、スケジュールに列挙された各データセットごとに1つのジョブが作成されます。

    ノート:

    スケジューラがトリガーを検査する間隔を変更するには、スケジューラのapplybackupsfrequencyポリシーに別の値を指定します。

    関連項目:

    ジョブの説明で、Oracle Secure Backupはこれをデータセット・ジョブとして識別します。スケジュールされたデータセット・ジョブに数値のジョブ識別子(15など)が割り当てられます。

  • オンデマンド・リクエストを作成して、「実行」をクリックするか、obtoolbackup --goコマンドを使用してリクエストをスケジューラに送信するたびに、Oracle Secure Backupではデータセット・ジョブが作成されます。admin/15などのように、コマンドを実行したユーザーが前に付けられたIDが、ジョブに割り当てられます。

  • データセット・ジョブについてスケジュールされた開始時刻に、Oracle Secure Backupはデータベースを読み取ってから、対象の各ホストに対して1つの下位ジョブを作成します。

    ジョブの説明で、Oracle Secure Backupはこれをバックアップ・ジョブと呼びます。Oracle Secure Backupは、各バックアップ・ジョブに、親(データセット)ジョブIDを接頭辞とし、ドット(.)と一意の小さい数字を続けた識別子を割り当てます。たとえば、15.1は、スケジュールされたジョブ15の下位ジョブです。

  • Oracle Secure Backupによるデータのリストアを明示的にリクエストしてから、「実行」をクリックするか、obtoolrestore --goコマンドを使用してリクエストをスケジューラに送信するたびに、Oracle Secure Backupではこのリストア操作を開始するために読取りが必要な、各バックアップ・イメージ・インスタンスに対するリストア・ジョブが作成されます。各ジョブにadmin/15のようなIDが割り当てられます。

    1つのリストア・リクエストに対応するため複数のジョブが作成された場合、先頭ジョブ以外のジョブは、前のジョブの成功に依存するというマークが付けられます。この表記の結果、後のジョブの依存対象であるジョブが失敗したとき、後のジョブにも「失敗」のマークが付けられます。

最も早いジョブの実行時刻に達した後、スケジューラが次に実行するジョブを決定する次の判断基準は、ユーザーが割り当てたスケジュールの優先度です。スケジューラは、利用できるすべてのリソースに対して優先度順にジョブをディスパッチし、リソースが利用できるようになるのを待機して、引き続きジョブをディスパッチします。最もスケジュール優先度の数値が小さいジョブが、最も高い実際のジョブ優先度に対応しており、最初にディスパッチされます。

ジョブのログについて

Oracle Secure Backupでは各ジョブに対するログが保存されます。このログにはジョブの作成、ディスパッチ、および完了時間のような高レベルのイベントが記述されます。ログはOracle Secure Backup Webツールとobtoolの両方で参照できます。

ジョブのトランスクリプトについて

Oracle Secure Backupでは各ジョブに対する実行トランスクリプトが保存されます。ジョブのトランスクリプトにはその処理の詳細が記述されます。このトランスクリプトはジョブを最初にディスパッチしたときに作成され、ジョブの進行に従って更新されます。ジョブにオペレータの支援が必要なとき、Oracle Secure Backupはトランスクリプトを使用して支援を求めます。

ジョブ・サマリーについて

ジョブ・サマリーは、Oracle Secure Backupで生成されるテキスト・ファイルのレポートで、選択したファイルシステム・バックアップおよびリストア・ジョブのステータスを記述します。各レポートにはジョブ・ステータスで区別された4つのセクションがあります。

  • 現在、実行準備が整っているジョブ(まだ開始していない)

  • 現在、実行中のジョブ

  • 正常に終了したジョブ

  • 取消、破棄または失敗となったジョブ

異なる時間範囲やアクティビティを網羅する複数のサマリー・レポートをOracle Secure Backupで生成するため、ジョブ・サマリー・スケジュールを作成できます。ジョブ・サマリー・スケジュールを作成する際、次のオプションを選択できます。

  • ジョブ・サマリーに対する一意の名前

  • Oracle Secure Backupがジョブ・サマリーを生成した日付

  • ジョブ・サマリーが電子メールで送信される宛先のユーザー

  • ジョブ・サマリーが対応する期間の開始時刻

    終了時刻は常にサマリー生成時刻です。

  • ジョブ・サマリーの内容

ユーザーとクラスについて

Oracle Secure Backupは、ユーザーとクラスを介してユーザー・レベル・アクセス制御を提供します。ユーザーとクラスに関する情報は、管理サーバーに格納されます。Oracle Secure Backupユーザーは、管理ドメイン全体で同一のアイデンティティを持つエンティティです。クラスを使用して、ユーザーがバックアップ、リカバリまたは管理操作を実行するために必要とする権限を付与できます。クラスは、Oracle Secure Backupユーザーに付与できる権限の、名前付きのコレクションです。

Oracle Secure Backupには、事前定義されたクラスのセットが含まれます。Oracle Secure Backupをインストールすると、adminユーザーが自動的に作成され、事前定義されたadminクラスを割り当てられます。追加のOracle Secure Backupユーザーを作成し、必要なクラスまたはオペレーティング・システムの権限をユーザーに割り当てることができます。自身のクラスを定義して、そのクラスに権限を割り当てることもできます。

Oracle Secure Backupのデーモンについて

Oracle Secure Backupのデーモンは、Oracle Secure Backupの処理を実行する際のバックグラウンド・プロセスです。一部のデーモンは連続的に稼働しますが、その他のデーモンは特定の処理の実行のみで稼働し、処理が終わると終了します。

ノート:

Windowsオペレーティング・システムでは、サービス・デーモンのみがWindowsサービスです。その他のOracle Secure BackupデーモンはWindowsサービスではありません。

この項の内容は次のとおりです。

デーモンの種類

Oracle Secure Backupの管理ドメインは、様々なデーモンを使用してバックアップ、リストアおよび構成などのタスクを実行します。デーモン・プログラムは、LinuxまたはUNIXではOracle Secure Backupホームのetcサブディレクトリ、Windowsではbinディレクトリにあります。この項では、Oracle Secure Backupのデーモンについて説明します。

表1-1に、Oracle Secure Backupのデーモンと各デーモンが実行するホストを示します。

表1-1 Oracle Secure Backupデーモンとホスト・タイプ

デーモン 管理サーバー メディア・サーバー クライアント

サービス

はい

はい

はい

スケジュール

はい

いいえ

いいえ

索引

はい

いいえ

いいえ

Apache Webサーバー

はい

いいえ

いいえ

NDMP

はい

はい

はい

プール・マネージャ

はい

いいえ

いいえ

ロボット

いいえ

はい

いいえ

プロキシ

いいえ

いいえ

はい

この項の内容は次のとおりです。

サービス・デーモン

observicedサービス・デーモンは、様々なサービスを提供します。管理サーバー、メディア・サーバーおよびクライアントで継続的に実行されます。

管理サーバーでは、observicedはスケジュール・デーモンのリクエストに応じてジョブを実行し、ログ・ファイルおよびトランスクリプトをクリーンアップして、Oracle Secure Backup構成データへのアクセスをドメイン内の他のホストに提供します。observiced認証局(CA)としても機能するため、管理ドメイン内のホストからの証明書への署名要求を受諾し、署名済証明書をその要求元のホストに送り返します。observicedは初期化の際に、スケジュール・デーモンとApache Webサーバーを起動します。

メディア・サーバーまたはクライアントで稼働中のときは、observicedは管理ドメインのメンバーシップを処理し、ホストのリモート管理を許可し、証明書操作を処理します。要求元のホストのアイデンティティ証明書は、その操作が許可されているかどうかの検証に使用されます。

すべてのホストで、サービス・デーモンは通常、システム・スタートアップの一部として起動します。UNIXおよびLinuxでは、スタートアップは通常/etc/init.dのエントリで実行され、Windowsシステムではサービスはサービス コントロール マネージャで起動します。

スケジュール・デーモン

obscheduledデーモンはOracle Secure Backupのスケジューラです。スケジュール・デーモンは管理サーバー上で連続的に稼働します。

スケジュール・デーモンは各スケジュール済バックアップを管理し、ドメイン内の使用可能なすべてのテープ・デバイスのリストを保持し、バックアップ・コンテナが使用可能になると同時にバックアップを割り当てます。このデーモンは、RMANコマンドに応答してobtoolユーザーとSBTインタフェースからジョブ作成リクエストを受信します。

スケジューラ・ポリシーは、バックアップ・リクエストのスケジュール方法を制御します。

索引デーモン

obixdデーモンは各クライアントに対するバックアップ・カタログを管理します。索引デーモンは管理サーバー上で断続的に稼働します。

索引デーモンは、あらゆるバックアップの終わりに起動して、obtarで生成された索引データをバックアップ・カタログにインポートします。また、リストアまたは参照のためにカタログへのアクセスが必要になるとobixdが起動します。

Apache Webサーバー・デーモン

obhttpdデーモンはOracle Secure Backupに対するWebツールを提供します。このデーモンは管理サーバー上で連続的に稼働します。

Webサーバー・デーモンは、システム・スタートアップの一部として通常起動するobservicedデーモンによって、起動するように合図されます。

NDMPデーモン

obndmpdデーモンは、NDMPテープ・サービスを実装し、メディア・サーバーとクライアントとの間のデータ通信を提供します。このデーモンはクライアントとメディア・サーバーの両方で稼働します。obtarによって送信される制御メッセージへの応答が妨げられることがないよう、データ通信の制御をサブプロセスに渡します。

アクティブ・バックアップまたはリストア操作時、2つのobndmpdのインスタンスが稼働します。同一のホストがメディア・サーバーとクライアントの両方として動作する場合、3つのobndmpdのインスタンスが稼働します。それぞれ、コントローラ、データ・サービス、ムーバーとして動作します。

ロボット・デーモン

obrobotdデーモンはテープ・ライブラリ内のテープを操作します。このデーモンはメディア・サーバー上で断続的に稼働します。

obtarなどのOracle Secure Backupコンポーネントがテープ・ライブラリと対話する必要がある場合、メディア・サーバー上のobservicedobrobotdのインスタンスを起動するよう要求します。ロボット・デーモンは、インベントリの操作、テープ・ライブラリ内のメディアの移動などのすべてのリクエストを処理します。obrobotdの各実行が1つのテープ・ライブラリを管理します。テープ・ライブラリのすべてのユーザーが接続を閉じている場合にobrobotdは存在します。

プール・マネージャ・デーモン

obpoolmgrデーモンは、ディスク・プールの内容を管理します。管理サーバー上で連続的に実行されます。

obpoolmgrデーモンは、期限切れのバックアップ・イメージ・インスタンスを削除し、ディスク・プール領域の使用状況を監視し、バックアップ操作時にディスク・プール領域が不足すると、obtarと対話します。バックアップ・イメージ・インスタンスは、期限が切れても削除されません。ディスク・プールの空き領域がディスク・プールのために指定したしきい値を割り込むと削除されます。

プロキシ・デーモン

obproxydデーモンは、SBTのバックアップおよびリストア操作へのユーザー・アクセスを検証します。プロキシ・デーモンは、処理中にアクセスされたSBTライブラリを含むホストで稼働します。プロキシ・デーモンの起動はプラットフォームに依存します。

プロキシ・デーモンは、プロセスのオペレーティング・システム・ユーザーのアイデンティティを使用してSBTライブラリを起動し、ローカル・ホスト名を使用してバックアップ処理で使うOracle Secure Backupアカウントを決定します。このオペレーティング・システム・ユーザーおよびホストに対する事前認可が存在し、関連付けられたOracle Secure BackupユーザーがRMANバックアップの実行を許可されている場合は、Oracle Secure Backupへのログインが許可されます。

ファイルシステム・バックアップにおけるデーモンのやり取り
次の図は、管理サーバー、メディア・サーバーおよびクライアント上のデーモン間の関係を簡単に図示しています。

図1-3 管理ドメインのデーモン

図1-3の説明が続きます
「図1-3 管理ドメインのデーモン」の説明

図のメディア・サーバーにはobtarインスタンスが示されていますが、obtar自体はデーモンではありません。基礎をなすOracle Secure Backupエンジンで、バックアップまたはリストア操作時にデータ、テープ・サービスおよびディスク・プールを操作します。obtoolまたはOracle Secure Backup Webツールでコマンドを発行すると、Oracle Secure Backupによって内部でobtarコマンドに変換されます。

observicedデーモンが全ホストで稼働中で、管理サーバー上のobservicedデーモンがobscheduledおよびobhttpdデーモンを起動しており、クライアント・ファイル・システムのバックアップ・ジョブが作成されて実行をスケジュールされていると想定します。Oracle Secure Backupデーモンは次のようにobtarとやり取りします。

  1. 管理サーバーで、obscheduledobservicedにバックアップ・ジョブを実行するようにリクエストを送信します。

  2. 管理サーバー上のobservicedはメディア・サーバー上のobrobotdに、バックアップ・ジョブに必要な各ボリュームをマウントするようにリクエストを送信します。

  3. 管理サーバー上のobservicedはメディア・サーバー上のobservicedに、obtarを起動するようにリクエストを送信します。

  4. メディア・サーバー上のobtarは、クライアント上のobndmpdデーモンとメディア・サーバー上のobndmpdデーモンの間のデータ接続を確立します。バックアップ・データは、このデータ接続を介して送信され、バックアップ・コンテナに書き込まれます。

    通常、obtarはメディア・サーバー上で稼働します。メディア・サーバーがOracle Secure Backupソフトウェアを実行していない場合は、obtarは管理サーバー上で稼働します。Oracle Secure Backupを実行しないメディア・サーバーの例としては、NDMPベースのファイラがあります。

  5. obtarは管理サーバー上のobixdにカタログ情報を送信してから終了します。

  6. 管理サーバーで、observicedobscheduledにジョブ・ステータスの更新を送信します。

バックアップ・イメージとバックアップ・イメージ・インスタンスの概要

バックアップ・イメージは、1つのバックアップ操作の結果から構成されているデータのセットです。バックアップ・イメージ・インスタンスは、実際のバックアップ・データを含みます。

バックアップ操作が開始されると、Oracle Secure Backupは次のものを作成します。

  • バックアップ・イメージ

    バックアップ・イメージは、バックアップ・データが格納されるバックアップ・コンテナに固有でない、バックアップに関する基本的な情報を格納します。

    関連項目:

    バックアップ・イメージ

  • バックアップ・イメージ・インスタンス

    バックアップ・イメージ・インスタンスには、バックアップ・データと、バックアップに関するいくらかの追加の情報が含まれます。Oracle Secure Backupは、バックアップ操作時に、指定されたパラメータに基づいて1つのバックアップ・イメージ・インスタンスを作成します。たとえば、テープ・ドライブmy_drvを使用してバックアップを作成する必要があると指定した場合、バックアップ・イメージ・インスタンスはこのテープ・ドライブのボリュームを使用して作成されます。

必要に応じて、異なるバックアップ・コンテナに、追加のバックアップ・イメージ・インスタンスを作成できます。

バックアップ・イメージ

バックアップ・イメージは、バックアップを記述したメタデータのセットです。バックアップに関する情報(たとえばバックアップの名前、バックアップのタイプ、作成日時、サイズ、バックアップ・レベルおよびバックアップUUID)が含まれます。各バックアップ操作は、正確に1つのバックアップ・イメージを作成します。Oracle Secure Backupは、各バックアップ・イメージにバックアップUUIDを割り当てます。バックアップ・イメージUUIDは、管理ドメイン全体で一意です。

関連項目:

バックアップ・イメージ名で使用される形式の詳細は、『Oracle Secure Backupリファレンス』を参照してください。

バックアップ操作の実行時に、バックアップ・イメージの名前を指定できます。各バックアップ・イメージ名は、Oracle Secure Backupカタログ内で一意である必要があります。名前で日付を指定しない場合、—yymmdd形式の6桁の日付がバックアップ・イメージ名の最後に自動的に追加されます。名前に時刻を含めない場合、-hhmmss形式の6桁の時刻がバックアップ・イメージ名の最後に自動的に追加されます。名前に日付または時刻を追加しない場合、両方の値が-yymmdd-hhmmss形式でバックアップ・イメージ名の最後に自動的に追加されます。名前を指定しない場合、Oracle Secure Backupはホスト名、タイムスタンプおよびシステムが生成する順序番号で構成される名前を生成します。

バックアップ・イメージは、次のタイプのデータを含むことができます。

  • Oracle Secure Backupドメインのホストからのファイルシステム・データ

  • Oracle Databaseバックアップの一部を含む、RMANが生成したバックアップ・ピース

  • NDMPデータサービスからバックアップ操作によって生成されたデータ

バックアップ・イメージ・インスタンス

Oracle Secure Backupは、バックアップ・データを複数のバックアップ・コンテナに書き込むことができます。バックアップ・イメージ・インスタンスは、特定のバックアップ・コンテナに格納されるバックアップ・イメージの完全な表現です。バックアップ・イメージ・インスタンスには、バックアップされた実際のデータが含まれます。特定のバックアップ・イメージに対して、複数のバックアップ・イメージ・インスタンスが存在し、各インスタンスが異なるバックアップ・コンテナに格納されることが嘉納です。

たとえば、ファイルシステム・バックアップを実行する場合、Oracle Secure Backupは1つのバックアップ・イメージと1つのバックアップ・イメージ・インスタンスを作成します。このバックアップ・イメージ・インスタンスが、テープ・ドライブdrive1上に作成されるとします。その後、テープ・ドライブdrive2とディスク・プールmy_disk上に、このバックアップ・イメージの他のインスタンスを作成できます。すべてのバックアップ・イメージ・インスタンスに含まれるバックアップ・データは、同じです。ただし、異なるメディアに格納されるため、メディア・ファミリや暗号化のタイプなど、一部のプロパティが異なる場合があります。

Oracle Secure Backupは、各バックアップ・イメージ・インスタンスにUUIDを割り当てます。このUUIDは、管理ドメイン全体で一意です。各バックアップ・イメージ・インスタンスには、管理ドメイン全体で一意である名前も割り当てられます。Oracle Secure Backupは、関連するバックアップ・イメージの名前に基づいて、バックアップ・イメージ・インスタンスの名前を生成します。たとえば、daily_db_bkというバックアップ・イメージの場合、最初に作成されたバックアップ・イメージ・インスタンスはdaily_db_bk.1と呼ばれ、次に作成されたインスタンスはdaily_db_bk.2と呼ばれ、以下同様に続くという例が考えられます。

関連項目:

バックアップ・イメージ名で使用できる形式の詳細は、『Oracle Secure Backupリファレンス』を参照してください。

テープにバックアップを格納する場合、各バックアップ・イメージ・インスタンスにバックアップ・カタログ・データが付随します。カタログ・インポート操作時に、バックアップ・カタログ・データは、現在のOracle Secure BackupドメインのOracle Secure Backupカタログ・ファイル内に、そのバックアップ・イメージ・インスタンスをリビルドする情報を提供します。デフォルトで、この機能は、ボリューム・セットの範囲内で格納されるすべてのバックアップ・イメージ・インスタンスに関する情報をカタログ化します。

バックアップ・イメージとバックアップ・イメージ・インスタンスの関係

図1-4は、バックアップ・イメージバックアップ・イメージ・インスタンスの関係を示しています。バックアップ操作が完了すると、Oracle Secure Backupはバックアップ・イメージMY_BKUPとバックアップ・イメージ・インスタンスMY_BKUP.1を作成します。このインスタンスは、テープ・ボリュームVOL0001に作成されます。その後、別のバックアップ・イメージ・インスタンスが、ディスク・プールMY_DPに作成されます。バックアップ・イメージの名前は、MY_BKUP.2です。各バックアップ・イメージ・インスタンスは、それ自身の一意のUUIDを持っています。

図4-1 バックアップ・イメージとバックアップ・イメージ・インスタンス

図1-4の説明が続きます
「図1-4 バックアップ・イメージとバックアップ・イメージ・インスタンス」の説明
バックアップ・イメージ・インスタンスとカタログ・データ

バックアップ・イメージ・インスタンスバックアップ・コンテナ書き込まれる場合、Oracle Secure Backupはこのバックアップのカタログ・データをバックアップ・イメージ・インスタンスとともに格納します。このカタログ・データがあると、バックアップ・コンテナがもう1つの管理ドメインにインポートされたとき、すぐにカタログを更新できます。カタログ・データをバックアップ・イメージ・インスタンスとともに格納すると、障害回復シナリオで効果的です。Oracle Secure Backupカタログ情報が破損して、カタログのバックアップのコピーが利用できない場合、この情報を使用してカタログを再作成できます。

Oracle Secure Backupのメディアの概念の概要

Oracle Secure Backupは、データ保護戦略の一部として作成したバックアップを、指定されたストレージ・メディアに格納します。この項ではストレージ・メディアの概要を提供し、バックアップを異なるストレージ・メディアに格納する方法を説明します。

この項には次のトピックが含まれます:

バックアップ・コンテナについて

バックアップ・コンテナは、バックアップ・イメージ・インスタンスが格納される物理メディアです。バックアップ操作を実行するときに、バックアップを格納するバックアップ・コンテナを指定できます。あるバックアップ・コンテナから別のものにバックアップ・イメージ・インスタンスをコピーしたり、移動したりすることもできます。

Oracle Secure Backupは、次のタイプのバックアップ・コンテナをサポートします。

  • ディスク・プール

    ディスク・プールは、バックアップ・イメージ・インスタンスのリポジトリであるファイルシステム・ディレクトリです。ファイルシステム・ディレクトリの内容は、Oracle Secure Backupによって管理されます。

  • テープ・ボリューム

    テープ・ボリュームとは、LTO5テープ・カートリッジなど、メディアの物理的な部分です。テープ・ボリュームは、Oracle Secure BackupによってボリュームIDを割り当てられた物理カートリッジです。このボリュームIDは、カタログが、リストアを実行するために参照します。このボリュームは、テープ・ドライブやライブラリに存在し、システム管理者の任意の判断に応じて、他の場所にボールティングまたは格納されます。

    関連項目:

    ボリュームについて

  • クラウド・ストレージ・デバイス

    クラウド・ストレージ・デバイスでは、次の場所にデータが格納されます。

    • Oracle Cloud Infrastructure Object Storage Classic

    • Oracle Cloud Infrastructure Archive Storage Classic

    • Oracle Cloud Infrastructure標準オブジェクト・ストレージ

    • Oracle Cloud Infrastructureアーカイブ・オブジェクト・ストレージ

    • Oracle Cloud Infrastructure低頻度アクセス・オブジェクト・ストレージ

    Oracle Secure Backupによって、Oracle Cloud内の構成済の各クラウド・ストレージ・デバイス用に新しいコンテナが作成されます。クラウド・ストレージ・デバイスにバックアップされたすべてのデータは、クラウド内の関連するコンテナに格納されます。

    関連項目:

バックアップおよびリストア操作のデフォルトのバックアップ・コンテナ

デフォルトで、Oracle Secure Backupはテープ上にバックアップ・イメージ・インスタンスを格納します。次のいずれかの条件に適合する場合、バックアップ・イメージ・インスタンスはディスク・プール上に格納されます。

  • Oracle Secure Backupドメインに構成されているテープ・デバイスがない

  • バックアップ・ジョブ(オンデマンドまたはスケジュール済)には、デバイス制約としてディスク・プールが構成されています

Oracle Secure Backupは、デフォルトではクラウド・ストレージ・デバイスをジョブのターゲットとして使用しません。クラウド・ストレージ・デバイスは、ジョブ・コマンドで制限として指定されている場合のみ、クラウド・ストレージ・デバイスにデータをバックアップします。

データのリストア時に、Oracle Secure Backupはまず、利用できるあらゆるオンライン・ディスク・プールから、データをリストアしようとします。必要なデータがディスク・プールにない場合、Oracle Secure Backupはそれをテープからリストアします。テープにデータがない場合は、クラウド・ストレージからリストアされます。

バックアップ・セクションについて

バックアップ・イメージ・インスタンスは、1つ以上のバックアップ・セクションから構成されることがあります。バックアップ・セクションは、バックアップ・コンテナに連続して格納される、バックアップ・イメージ・インスタンスの部分です。各バックアップ・セクションは、バックアップ・セクションの作成時にOracle Secure Backupによって生成される一意のバックアップ・セクションIDによって識別されます。

バックアップ・イメージ・インスタンスが複数のテープ・ボリュームにわたる場合、バックアップ・セクションの数はバックアップ・イメージ・インスタンスが存在するテープ・ボリュームの数と同じです。

バックアップ・イメージ・インスタンスが複数のディスク・プールに書き込まれる場合、バックアップ・イメージ・インスタンス全体は正確に1つのバックアップ・セクションから構成されています。

ボリュームについて

ボリュームは、テープなどのメディアの物理的ピースです。Oracle Secure Backupは各ボリュームを一意のボリュームIDで識別します。このボリュームIDは、メディア・ファミリのボリュームで説明する方法を使用して取得されます。

ボリュームIDの他に、ボリュームにはタグも付けられます。ボリューム・タグは31文字以内の英数字の文字列で、通常は、テープ・カートリッジに添付されているUPCバーコード・ラベルから取得されます。大部分のライブラリは、バーコード・リーダーを備えています。Oracle Secure Backupではこれを使用することで、テープをロードしたりボリューム・ラベルを読み取ったりしなくてもテープのアイデンティティを識別できます。Oracle Secure Backupはボリューム・タグをボリュームIDに関連付け、バックアップおよびリストア操作時に使用するために、どのバックアップ・イメージ・インスタンスを含んでいるかを記憶します。

バックアップ・イメージ・インスタンスとボリュームのラベル

Oracle Secure Backupでは、ボリューム・ラベルには通常ボリュームID(lev0-0001など)とボリューム・タグ(バーコード)が含まれています。この2つの属性で一意にテープを識別します。通常、Oracle Secure Backupでは、テープへの最初の書込み時にボリューム・ラベルが作成されます。バックアップ・イメージ・インスタンスの最初のブロックは、バックアップ・イメージ・ラベルとして参照されます。ファイル番号、セクション番号およびバックアップ・イメージ・インスタンスの所有者が含まれます。

ラベルが表示されるとき、ボリューム関連情報が「Volume label」というヘッダーとともに表示され、バックアップ・イメージ・インスタンス関連情報が「Backup Image label」というヘッダーとともに表示されます。これらは実際には、1つのラベルの別々の部分です。

Oracle Secure Backupのスケジューリング・システムで生成されるボリュームについて、メディア・ファミリやボリューム有効期限などの項目が表示される場合があります。

Oracle Secure Backupはラベル付けされたボリューム・セット上の各バックアップ・イメージ・インスタンスを、1から始まるバックアップ・イメージ・ファイル番号で番号付けします。

Oracle Secure Backupは複数のバックアップ・イメージ・インスタンスをボリュームに書き込むとき、各バックアップ・イメージ・インスタンスの後ろにテープ・ファイル・マークを配置します。最後のイメージの後ろに、Oracle Secure Backupはテープ・ファイル・マークを書き込んでから、データ終了(EOD)ラベル、続いて2つのテープ・ファイル・マークを書き込みます。図1-5は、2つのバックアップ・イメージ・インスタンスを内包するボリュームの形式を示しています。この図にはラベルとテープ・ファイル・マークの位置が示されています。

図1-5 ボリューム上の2つのバックアップ・イメージ・インスタンス

図1-5の説明が続きます
「図1-5 ボリューム上の2つのバックアップ・イメージ・インスタンス」の説明

バックアップ・イメージ・インスタンス、ボリュームのラベルおよび特別な「End of Data」ラベルと「End of Volume」ラベルは、形式が共通しており、ボリュームおよびバックアップ・イメージのデータの両方を含みます。ボリューム・ラベルは、ボリュームに対するラベルと、ボリューム上の最初のバックアップ・イメージ・インスタンスのラベルの、二重の役割を果します。同様に、バックアップ・イメージ・ラベルには、後に続くバックアップ・イメージ・インスタンスの情報と、ボリューム・ラベルからのボリューム情報のコピーが含まれます。このため、ボリューム・ラベルを読み取るためにテープを巻き戻さなくても、ボリューム情報を得ることができます。

図1-5に示すボリュームがセット内の最初のボリュームであると仮定します。最初のバックアップ・イメージ・インスタンスに対するボリューム・ラベルは、例1-2のようになります。

2番目のバックアップ・イメージ・インスタンスに対するボリューム・ラベルは、例1-3のようになります。

Oracle Secure Backupによってバックアップ・イメージ・インスタンスが作成された後、EODラベルの直前にボリュームが配置されます。EODラベルには前にあるバックアップ・イメージ・ラベル内のデータのコピーが含まれますが、イメージ・ファイル番号だけは数字が1つ増えます。Oracle Secure BackupはEODラベルを使用して、ボリュームを巻き戻すことなく、次のバックアップ・イメージ・インスタンスに対するボリュームID、バックアップ・イメージ・ファイル番号、および順序番号を提供します。

Oracle Secure Backupでバックアップ・イメージ・インスタンスが読み取られた後は、そのバックアップ・イメージ・インスタンスの後ろのテープ・ファイル・マークの後ろで、かつ次のバックアップ・イメージ・インスタンスのボリューム・ラベルの前に、ボリュームが配置されます。

例1-2 バックアップ・イメージ・インスタンス1

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       1
 Section:           1
 Sequence number:   1
...

例1-3 バックアップ・イメージ・インスタンス2

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       2
 Section:           1
 Sequence number:   1
...

ボリューム・セットについて

Oracle Secure Backupでは1つのバックアップ・イメージ・インスタンスを複数のボリュームに広げることができます。ボリューム・セットは1つ以上のテープ・ボリュームのグループで、最初のボリュームは2番目のボリュームに続き、2番目のボリュームは3番目に、のように続いていきます。

ボリューム・セット内の各ボリュームにはボリューム順序番号があり、直前のボリュームより増えていきます。結果的に、1回のセッションで大量のデータをバックアップまたはリストアできます。Oracle Secure Backupは常に、現在のボリュームの順序の次の番号に続けようとしますが、場合によっては、これは可能でありません。このシナリオでは、同じメディア・ファミリ内の、まだ書き込まれていず、利用できる次のボリュームIDに書き込みます。Oracle Secure Backupでは、ボリューム・セットの最初のテープ以外のいかなるテープも、既存のOracle Secure Backupボリュームに付加できません。後続のテープは、常に順序内の次の利用できるボリュームIDを使用して新しいボリュームに書き込みます。たとえば、ボリューム・セットの最初のテープは VOL00005であるが、VOL00006VOL00007が、他のバックアップがすでに書き込まれたボリュームである場合、VOL00005のボリューム・セットの2番目のテープはVOL00008になります。

Oracle Secure Backupが複数のボリュームの読取りおよび書込みを行うときは、次のデータを使用してボリューム・セット内のボリュームの正しい順序に従います。

  • EOVラベル

    バックアップ・イメージ・インスタンスが1つのボリュームを超えて次のボリュームに続く場合、Oracle Secure Backupは最初のボリュームを特別なEOVラベルを付けて終了します。このラベルには、セット内の次のボリュームのボリュームIDが含まれます。ボリューム・セット内では、最後のボリューム以外のすべてのボリュームがEOVラベルで終了します。最後のボリュームはEODラベルで終了します。

  • 順序番号

    ボリューム・ラベルに記録される順序番号は、ボリューム・セット内のボリュームの順序を示しています。セット内の最初のボリュームの順序番号は1です。

  • セクション番号

    ボリューム・ラベルに記録されるセクション番号は、複数のボリュームに及ぶバックアップ・イメージ・インスタンスのセクションの順序を示しています。

    ノート:

    バックアップ・イメージ・インスタンスが複数のボリュームにまたがらない場合、セクション番号は常に1になります。

図1-6は、3つのバックアップ・イメージ・インスタンスを内包するボリューム・セットを示しています。バックアップ・イメージ・インスタンス2は2つのボリュームに及んでいます。

図1-6 複数のボリュームに及ぶ1つのバックアップ・イメージ・インスタンス

図1-6の説明が続きます
「図1-6 複数のボリュームに及ぶ1つのバックアップ・イメージ・インスタンス」の説明

1番目のバックアップ・イメージ・インスタンスに対するボリューム・ラベルの一部は、例1-4のようになります。

2番目のバックアップ・イメージ・インスタンスの1番目のセクションに対するボリューム・ラベルの一部は、例1-5のようになります。

2番目のバックアップ・イメージ・インスタンスの2番目のセクションに対するボリューム・ラベルの一部は、例1-6のようになります。

2番目のバックアップ・イメージ・インスタンスの2番目のセクションに対するボリューム・ラベルの一部は、例1-7のようになります。

例1-4 バックアップ・イメージ・インスタンス1、セクション1

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       1
 Section:           1
 Sequence number:   1

例1-5 バックアップ・イメージ・インスタンス2、セクション1

Volume label:
 Volume ID:         VOL000014
 Owner:             jane
 Host:              chicago
 File number:       2
 Section:           1
 Sequence number:   1

例1-6 バックアップ・イメージ・インスタンス2、セクション2

Volume label:
 Volume ID:         VOL000015
 Owner:             jane
 Host:              chicago
 File number:       2
 Section:           2
 Sequence number:   2

例1-7 バックアップ・イメージ・インスタンス3、セクション1

Volume label:
 Volume ID:         VOL000015
 Owner:             jane
 Host:              chicago
 File number:       3
 Section:           1
 Sequence number:   2

ディスク・プールについて

ディスク・プールは、バックアップ・イメージ・インスタンスのリポジトリの働きをするファイルシステム・ディレクトリです。各ディスク・プールはファイルシステム・ディレクトリ・パスに関連付けられ、このディレクトリの内容はOracle Secure Backupによって管理されます。ディスク・プールは、ファイルシステム・バックアップ、Oracle DatabasesのRMANバックアップおよびNDMPファイラによって作成されるバックアップを格納できます。ディスク・プールには、複数のバックアップおよびリストア操作が同時アクセスできるため、バックアップおよびリストア・ジョブのパフォーマンスが向上します。

各ディスク・プールは、デバイスとしてOracle Secure Backupに表示されます。1つのディスク・プールは、1つのOracle Secure Backup管理ドメインにのみ属することができます。複数のOracle Secure Backup管理ドメインで共有することはできません。

バックアップ・イメージ・インスタンスは、期限切れになるか、明示的に削除されるか、テープに移動されるまで、ディスク・プール内にとどまります。Oracle Secure Backupは、期限切れになった直後でなく、ディスク・プール領域しきい値を超過したときに、期限切れのバックアップ・イメージ・インスタンスを削除します。

ディスク・プール上のストレージ容量

ディスク・プールを作成する場合は、容量の値を設定することをお薦めします。容量の値は、このディスク・プールに格納されているバックアップ・イメージ・インスタンスが占有できる領域の量を表します。指定された容量に到達した場合、領域消費量がその容量を割り込むまで、Oracle Secure Backupはこのディスク・プールに対していかなるジョブもスケジュールしません。

ディスク・プールに容量が設定されていない(容量が無制限)の場合は、現在の領域使用率が容量の値として使用されます。その値に空き領域目標率が適用され、その使用率レベルまでパージが自動的に実行されます。

たとえば、現在のディスク・プール使用率が100 GB、空き領域目標が20%の場合は、20 GBの期限切れバックアップ・イメージ(あると想定)で使用されている領域がパージされます。

ディスク・プールの領域使用率

各ディスク・プールに対して、領域使用率のしきい値を指定することができます。このしきい値は、空き領域目標として参照されます。パーセンテージで表され、Oracle Secure Backupがディスク・プールで維持しようとする空き領域の量を表します。ディスク・プールによって消費されている領域が指定されたしきい値を上回ると、Oracle Secure Backupは期限切れのバックアップ・イメージ・インスタンスを削除します。

ディスク・プール・オーファン

ディスク・プールへのバックアップが失敗した場合、このバックアップと関連するディスク・プール上の既存のデータは、ディスク・プール・カタログに追加されません。Oracle Secure Backupは、ディスク・プールにこれらのバックアップ・ファイルがあることを検出しません。そのようなファイルは「オーファン」と呼ばれます。Oracle Secure Backupは、日次自動クリーンアップ・プロセスを実行して、カタログ内に対応するエントリを持たないファイルを削除します。場合によっては、これが重要なデータを失う原因になることがあります。そのため、ディスク・プールを新しいドメインにインポートした直後に、それをカタログ化することによって、クリーンアップ時のディスク・プール・オーファン自動削除を回避することを強くお薦めします。ポリシー設定を変更することによって、日次クリーンアップ処理を無効にできます。

関連項目:

バックアップ・イメージ・インスタンスとテープ・ボリュームについて

Oracle Secure Backupを理解するには、物理的なバックアップ・ファイルとそのファイルが保存されるメディアの関係を理解する必要があります。図1-7は、バックアップ・ファイルがどのようにボリュームと関係するかを示しています。この概念は次のとおりです。

図1-7 バックアップ・イメージ・インスタンス、バックアップ・セクションおよびボリューム

図1-7の説明が続きます
「図1-7 バックアップ・イメージ・インスタンス、バックアップ・セクションおよびボリューム」の説明
バックアップ・イメージ・インスタンスとバックアップ・セクション

Oracle Secure Backupでバックアップ操作を実行すると、バックアップ・イメージ・インスタンスが作成されます。図1-8に示すとおり、バックアップ・イメージ・インスタンスは1つ以上のバックアップ・セクションで構成されるファイルです。

図1-8 バックアップ・イメージ・インスタンスとバックアップ・セクション

図1-8の説明が続きます
「図1-8 バックアップ・イメージ・インスタンスとバックアップ・セクション」の説明

バックアップ・イメージ・インスタンスは、Oracle Secure Backupのカタログ内でバックアップUUIDによって一意に識別されます。同様に、バックアップ・セクションは、そのバックアップ・セクションOIDによってカタログで一意に識別されます。

例1-8に、brhost2-20130329-123722.1というバックアップUUIDを持つバックアップに対するlsbiコマンドの出力を示します。

例1-9は、例1-8に示すバックアップ・イメージ・インスタンスに属するバックアップ・セクションに対するlsbiコマンドの出力を示しています。

例1-8 バックアップ・イメージ・インスタンス

ob> lsbi brhost2-20130329-123722.1 
        Instance Name                 Created       Container(s)brhost2-20130329-123722.1         2013/03/29.05:37  VOL000001

例1-9 バックアップ・セクション

ob> lsbi --sections brhost2-20130329-123722.1
        Instance Name                 Created       Container(s)
brhost2-20130329-123722.1         2013/03/29.05:37  spantape-000001,                                                                spantape-000002                 BSOID  File Sect   Size     103     1    1  100.1 MB     104     1    2   24.4 MB
チェックサムを計算することによるバックアップの検証について

Oracle Secure Backupでは、バックアップのライフサイクルの任意の時点におけるデータ破損を検出することにより、バックアップの整合性を保証します。これには、データベース・バックアップ、ファイルシステム・バックアップ、およびNDMPファイラからのバックアップが含まれます。

データ破損は、ハードウェア障害、人的エラーまたは悪意のある攻撃、ネットワークまたは待機時間の問題、記憶域の問題、またはアプリケーションの破損(読取り処理または書込み処理の一部として)によって発生する可能性があります。(バックアップ、ステージングまたはコピー・インスタンス操作の一部としての)バックアップ・イメージ・インスタンスの作成中、Oracle Secure Backupはチェックサムを計算および格納します。バックアップ・イメージ・インスタンスの整合性を確認するために、メディア・サーバーはチェックサムを再計算し、このバックアップ・イメージ・インスタンスが作成されたときに格納されたチェックサムを読み取り、再計算されたチェックサムと格納されたチェックサムを比較します。格納されているチェックサムと再計算されたチェックサムが一致する場合、バックアップ・イメージ・インスタンスは有効で、データ破損はありません。

バックアップを確認するプロセスは、バックアップの検証と呼ばれます。バックアップの検証を使用して、ボールティングまたはステージングを実行する前にバックアップ・イメージ・インスタンスを検証することもできます。バックアップの検証は、バックアップが作成された直後に実行、または指定した間隔で検証ジョブを実行する自動化されたスクリプトを介して実行できます。検証リクエストごとに個別のvalidatechecksumジョブが作成されます。バックアップの検証では、バックアップのリストアや別の場所へのコピーを行いません。

Oracle Secure Backup管理ドメインのアップグレード時に、すべてのストレージ・デバイス用のデバイス・ポリシーはSYSTEMDEFAULTに設定されます。アップグレード後に明示的にこの設定を変更しないかぎり、デフォルトでは、アップグレード後にテープ・デバイスおよびディスク・プールに作成されたすべてのバックアップに対してチェックサム計算が実行されます。

バックアップのチェックサム計算の構成レベル

チェックサム計算は、次のいずれかの方法で構成できます。

  • 特定のタイプのすべてのストレージ・デバイスに対してチェックサム計算を構成するには、そのタイプのデバイスのデバイス・ポリシーを設定します。

  • 特定のデバイスのチェックサム計算を構成するには、そのデバイスのチェックサム計算を有効にします。

チェックサム検証をデバイス・タイプ・レベルと特定のストレージ・デバイスの両方で構成すると、デバイス・タイプ・レベルの設定が個別のデバイス・ポリシー設定よりも優先されます。

チェックサム計算を実行できる操作

チェックサムの計算は、次のタイプのジョブについて適用可能です。
  • バックアップ
  • インスタンスのコピー
  • ステージング
これらのすべての操作では、バックアップ・イメージ・インスタンス全体が別のストレージ・コンテナにコピーされます。作成される新しいバックアップ・インスタンスごとにチェックサムが再計算されて格納されます。ソース・デバイスのチェックサムと新しいバックアップ・インスタンスのチェックサムが一致している必要があります。

コピー・インスタンス・ジョブでは、ソース・バックアップにチェックサムが格納されていない場合でも、コピーされたバックアップ・イメージ・インスタンスはチェックサムを計算および格納できます。

チェックサム計算の制限

  • 既存のバックアップに対してチェックサムの計算を実行することはできません。

    たとえば、Oracle Secure Backup 12.2.を使用してバックアップ・イメージ・インスタンスを作成したとします。その後、管理ドメインがOracle Secure Backup 18.1.にアップグレードされました。バックアップ・イメージ・インスタンスが作成された時点ではチェックサムが計算されていないため、Oracle Secure Backup 12.2を使用して作成されたバックアップは検証できません。

  • 再起動されたバックアップおよびNDMPファイラへのバックアップは検証できません。

  • 同時に検証できるバックアップ・イメージ・インスタンスは1つのみです。

  • NDMPファイラから別のNDMPファイラにバックアップ・イメージ・インスタンスをコピーしたときは、チェックサムの検証はサポートされません。

  • ボリュームの複製時にチェックサム検証はサポートされません。

  • validatechecksumジョブの一部としてチェックサム計算を実行する場合、ハードウェア暗号化による一時バックアップ・イメージ・インスタンスはサポートされません。

関連項目:

バックアップの検証の実行方法の詳細は、『Oracle Secure Backupリファレンス』を参照してください。

データ・ブロックとブロッキング・ファクタについて

テープ・ドライブは通常、データをブロック単位でテープに書き込みます。各書込み操作で、データがブロック単位で書き込まれ、ブロック間にギャップが設定されます。書込み操作の間、テープは連続的に実行されます。

データ・ブロックのブロック・サイズは、テープに書き込まれたブロックのサイズ(バイト単位)です。特定のバックアップまたはリストア操作で、読取りまたは書込みを行うブロックのサイズはすべて同じです。データ・ブロックのブロッキング・ファクタは、ブロックに含まれる512バイトのレコードの数を表します。たとえば、Oracle Secure Backupのデフォルトのブロッキング・ファクタ(128)では、テープのブロック・サイズは128*512バイト、つまり64KBになります。

最大ブロッキング・ファクタは、Oracle Secure Backupで使用されるブロッキング・ファクタの上限です。この制限値は、特にリストアの際、Oracle Secure Backupが実際のブロック・サイズの不明なテープから使用ブロック・サイズを最初に選択するときに効果を果します。最大ブロッキング・ファクタにより、この最初のブロック・サイズは、テープ・デバイスおよび基盤となるオペレーティング・システムの両方にとって受け入れ可能な値に制限されます。

Oracle Secure Backupはバックアップを開始するとき、いくつかの要素に基づいて使用するブロック・サイズを決定します。これらの要素を、優先度の高い要素から順に示すと次のようになります。

  • obtar -bオプションを使用して指定されたブロッキング・ファクタ。

    このオプションは、operations/backupoptionsポリシーの一部として指定することもできます。このオプションを指定すると、他のすべての要素に優先します。

    関連項目:

    obtar -bオプションおよびoperations/backupoptionsポリシーの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

  • 使用するテープ・ドライブの構成。

    ドライブを構成する際に、Oracle Secure Backupが使用する特定のテープ・ドライブのブロッキング・ファクタまたは最大ブロッキング・ファクタ(あるいはその両方)を指定できます。ブロック・サイズの制限がテープ・ドライブごとに大きく異なる場合、この方法で指定することがあります。

    関連項目:

    テープ・ドライブの構成の詳細は、『Oracle Secure Backupインストレーションおよび構成ガイド』を参照してください。

  • media/blockingfactorおよびmedia/maxblockingfactorポリシーで設定された、ドメイン全体のブロッキング・ファクタまたは最大ブロッキング・ファクタ(あるいはその両方)。

    関連項目:

    media/blockingfactorポリシーおよびmedia/maxblockingfactorポリシーの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

  • デフォルトのブロッキング・ファクタ(128)と最大ブロッキング・ファクタ(128)。ブロック・サイズは64KB(デフォルト)。

これらの要素のいずれかによって候補となったブロッキング・ファクタは、次のテストに合格する必要があります。

  • ブロック・サイズは、適用するポリシーまたはテープ・ドライブ構成の属性によって有効となる最大ブロック・サイズ(ブロッキング・ファクタ)以下である必要があります。

  • ブロック・サイズは、使用するテープ・ドライブおよびアタッチ・ポイントでサポートされている必要があります。

    テープ・ドライブ、デバイス・ドライバまたはカーネル・オペレーティング・システムの制限が、他のすべての事項に優先される場合があります。

Oracle Secure Backupはリストア操作を開始するとき、そのテープへの書込みに使用されたブロック・サイズを認識していません。読み取るブロックのサイズが小さすぎるとエラー状態になり、テープの位置変更が必要となるため、Oracle Secure Backupは常に、読取り可能な最大ブロック・サイズを使用してリストア操作を開始します。これは、現行のmedia/maxblockingfactorポリシーの設定またはテープ・ドライブの構成属性のいずれかです。したがって、最大ブロッキング・ファクタは、リストアできる最大ブロック・サイズ以上の値に設定されている必要があります。

バックアップ・イメージ・インスタンスから最初のデータを読み取った後、Oracle Secure Backupは、リクエストされたデータ量と実際のブロック・サイズを比較し、それ以降の読取りサイズをテープに合せて調整します。

メディア・ファミリについて

メディア・ファミリとは、ボリューム・セットの名前付きの分類を指します。この分類によって、異なる時刻に作成されたバックアップ・コンテナが確実に特性を共有できます。この方法で、メディア・ファミリを一般的なバックアップ処理にマップできます。メディア・ファミリによって、保存方法、書込みウィンドウ、保存期間が適切に定義されます。

メディア・ファミリをディスク・プールに関連付けることができます。ただし、ディスク・プールに適用できる唯一の属性は、保存時間です。テープとディスク・プールへのバックアップで同じメディア・ファミリを使用することは可能です。バックアップがディスク・プールに格納されている場合、メディア・ファミリで指定された保存時間のみが使用されます。

メディア・ファミリ属性

メディア・ファミリは、作成時にボリュームに割り当てられる複数の特性を定義する属性です。メディア・ファミリには、ボリュームが時間管理かコンテンツ管理か、期限切れになるか、なるとしたらいつか、ローテーションと複製のポリシー、ボリュームID名の形態などが含まれます。

テープに関連付けられたメディア・ファミリ属性は、なんであれ、特定のボリューム・セットの最初のボリュームが書き込まれたときにメディア・ファミリにより定義済であった属性です。その後でメディア・ファミリ設定になされた変更は、既存のテープには適用されず、それ以降にこのファミリを使用して書き込まれるか、再利用されるテープのみに適用されます。

メディア・ファミリの各ボリュームは次の属性を共有します。

  • ボリュームの識別順序

    Oracle Secure Backupは次のいずれかの状態が発生すると、各テープ・ボリュームに一意のIDを書き込みます。

    • Oracle Secure Backupが初めてテープに書き込んだ場合。

    • Oracle Secure Backupがテープを最初から上書きした場合。

    ボリュームIDは、通常はメディア・ファミリ名の固定部分があり、Oracle Secure Backupで割当てされ更新される順序番号がその後に続きます。たとえば、メディア・ファミリがfull_backupの場合、ボリュームIDはfull_backup-000029となる場合があります。デフォルトでは、メディア・ファミリ内の最初のボリュームの順序番号は1です。順序番号は、メディア・ファミリ内の後続のボリュームごとに1ずつ増分されます。ただし、メディア・ファミリが削除され、同じ名前を使用して別のメディア・ファミリが作成されると、ボリュームの順序番号は1にリセットされます。

  • ボリューム有効期限ポリシー

    有効期限ポリシーは、メディア・ファミリのボリュームがいつ上書きおよび再利用が可能になるかを定義します。メディア・ファミリは、次の相互排他のボリューム有効期限ポリシー・タイプのいずれかを持つことができます。

    • コンテンツ管理

      ボリュームの有効期限を、Oracle Databaseに関連付けられているRMAN保存パラメータを使用して決定します。コンテンツ管理のメディア・ファミリは、Oracle Databaseバックアップのみを格納できます。

    • 時間管理

      ボリュームの有効期限を、メディア・ファミリに関連付けられているユーザー定義の保存を使用して決定します。時間管理のメディア・ファミリは、Oracle Databaseバックアップとファイルシステム・バックアップの両方を格納できます。

    ファイル・システム・バックアップでメディア・ファミリが指定されていない場合、nullメディア・ファミリがデフォルトとして使用され、ボリュームID VOLと表示されます。RMANバックアップでメディア・ファミリが指定されていない場合、RMAN-DEFAULTメディア・ファミリがデフォルトとして使用されます。

    ボリュームに関連付けられたメディア・ファミリは、そのテープへの最初のOracle Secure Backup書込み時に、テープに割り当てられます。ボリュームは、期限切れにならないようにすること、未使用領域を残すことおよび次のバックアップ操作で選択されないようにすることができます。同じメディア・ファミリからのバックアップのみ、このテープに追加できます。一杯になった、または閉じられたボリュームには、期限切れにならないかぎり、書き込まれません。Oracle Secure Backupは、バックアップを開始するときに、指定されたメディア・ファミリに属し、利用できる領域がある、直近のボリュームを検索します。そのようなボリュームがない場合、ライブラリ記憶域要素にある最初の新規または再利用可能なボリュームが、バックアップに使用されます。

    時間管理のボリューム・セットが期限切れになると、このセット内の各ボリュームは自動的に、上書きまたは再利用可能と判断されます。コンテンツ管理のボリューム・セットは、ボリューム・セットの他のメンバーに関係なく期限切れになります。ボリュームのすべての部分が期限切れになると、再利用可能になります。

  • 書込みウィンドウ

    書込みウィンドウとは、一定期間の間、更新のために時間管理のボリューム・セットが開かれたままになっている状態のことです。更新とは、書込みウィンドウがまだ開いている同じメディア・ファミリの既存のテープを追加できる、他のバックアップです。書込みウィンドウは、セット内の最初のボリュームに対するボリューム作成時間に開き、書込みウィンドウの期間が経過した後に閉じます。

    書込みウィンドウが閉じるときにバックアップをテープに書込み中の場合、そのバックアップは最後まで終了しますが、次のバックアップをボリュームに書き込むことはできません。書込みウィンドウのクローズ時間の後では、ボリューム・セットは、(有効期限ポリシーによる定義に従って)期限切れになるまで、あるいは手動でラベル付けを解除されるまで更新できません。

  • ローテーション・ポリシー

    ローテーション・ポリシーは、メディアのライフサイクルを通したバックアップ・メディアの物理的な管理を定義します。このポリシーは、ボリュームが、初期のアクティブな場所から保管場所に移動し、再使用のためにアクティブな場所に戻る順序とタイミングを決定します。

    関連項目:

    ローテーション・ポリシーの詳細は、「ボールティング」を参照してください

メディア・ファミリの属性は、ボリューム作成時間にメディア・ファミリ内のボリュームに適用されます。メディア・ファミリ属性はボリュームの属性の一部です。データが最初にボリュームに書き込まれた後は、ボリュームを再書込みする以外に、ボリュームの属性を変更することはできません。メディア・ファミリ属性を変更した場合、これらの変更は、このファミリですでに作成されているボリュームには適用されません。

関連項目:

メディア・ファミリのボリューム

メディア・ファミリを作成するとき、ボリューム・ラベルの一部となるボリュームIDの生成方法を指定します。

Oracle Secure Backupでテープ・ボリュームがラベル付けされる際、ボリュームIDはボリューム順序ファイルの内容に基づいて割り当てられます。このファイルは管理サーバーに格納されています。場所はボリュームのメディア・ファミリによって定義されます。通常、ボリューム順序ファイルはOracle Secure Backupホームのadmin/state/generalサブディレクトリにあります。

メディア・ファミリを定義する際、ボリュームIDの割当て方法をOracle Secure Backupに指示します。この指示は次のような方法で実行できます。

  • メディア・ファミリのデフォルトのボリューム順序ファイル

    ほとんどの場合、このファイルを使用します。各メディア・ファミリに対するボリューム順序ファイルはadmin/state/family/family_nameディレクトリにあります。たとえば、メディア・ファミリをnew_dataという名前で定義すると、ファイルはadmin/state/family/new_dataディレクトリにあります。

    Oracle Secure Backupは各ボリュームIDを構成する際、メディア・ファミリ名で始め、次にダッシュ、その次に6桁の順序番号(最初は000001)を付加します。たとえば、ユーザーがメディア・ファミリをnew_dataという名前で定義すると、Oracle Secure Backupは.vid.new_dataというボリューム順序ファイルを管理サーバー上に作成します。このファイルの最初のボリュームIDはnew_data000001です。Oracle Secure BackupがIDをボリュームに割り当てるたびに、この数字は1ずつ増加します。つまり、Oracle Secure Backupが割り当てる次のボリュームIDはnew_data000002となり、以後も同様になります。

  • ユーザー指定のボリューム順序ファイル

    Oracle Secure Backupはインストール時、デフォルトのボリューム順序ファイルを作成します。管理サーバーのadmin/state/generalサブディレクトリにあります。このファイルの最初のボリュームIDはVOL000001です。Oracle Secure BackupがIDをボリュームに割り当てるたびに、この数字は1ずつ増加します。つまり、Oracle Secure Backupが割り当てる次のボリュームIDはVOL000002となり、以後も同様になります。

    独自のボリューム順序ファイルを指定すると、デフォルトのボリューム順序ファイルは無視され、指定したファイルがボリュームIDの取得に使用されます。ユーザーはフルパス名を入力して、このファイルを後でどこに作成するか指定できます。Oracle Secure Backupではこのファイルは自動的に作成されません。ファイルの作成は手動で行う必要があります。ユーザーはテキスト・エディタを使用して、ボリュームIDの接頭辞をカスタマイズできます。

    各ボリュームIDファイルには1つのボリュームIDが含まれます。ボリュームIDの最大文字数は31文字です。最初の数文字を使用してボリュームを分類できます。たとえば、次のような文字で始まるボリュームIDを作成できます。

    • 接頭辞8mm(あるテープ・デバイスで作成されたボリュームを識別するため)およびDAT(別のテープ・デバイスで作成されたボリュームを識別するため)

    • 接頭辞INCRまたはFULL(全体バックアップまたは増分バックアップで使用されるボリュームを識別するため)

    • laなどの、オペレータのイニシャル(バックアップを実行するユーザーを識別するため)。

    作成した順序番号にユーザーが数字を入れなかった場合は、Oracle Secure Backupが順序番号に1を付加し、その順序番号が使用されるたびに数字を1ずつ増加していきます。

  • ユーザー指定のボリュームID

    mkmfコマンドの--viduniqueオプションを使用すると、明示的なボリュームIDを指定できます。たとえば、以前作成したテープが部分的に読取り不可能な場合に、ユーザー独自のボリュームIDを作成できます。バックアップを再度実行して--viduniqueオプションを使用することで、ユーザーのボリュームIDを順序どおりにするボリュームIDを指定します。

    また、restoreコマンドの--vidオプションを使用して、読取り中のボリュームが正しいことを確認できます。

    関連項目:

    mkmfおよびrestoreコマンドの構文とセマンティックの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

ボリューム・セットとメディア・ファミリ

図1-9は、ボリューム・セットがどのようにメディア・ファミリと関係するかを示しています。この概念は次のとおりです。

  • ボリューム・セットは、バックアップ・イメージ・インスタンスで網羅される1つ以上の物理ボリュームの論理グループです。

  • メディア・ファミリは共通の属性を共有する、ボリュームの論理分類です。たとえば、メディア・ファミリ内のボリュームは、データの書込みおよび保存に使用される共通のネーミング・パターンを共有します。

図1-9 ボリューム、ボリューム・セットおよびメディア・ファミリ

図1-9の説明が続きます
「図1-9 ボリューム、ボリューム・セットおよびメディア・ファミリ」の説明

Oracle Secure Backupでファイルをバックアップする際、ユーザーは、ユーザーのバックアップに関連付けられたメディア・ファミリで定義された、共通の特性を持つボリューム・セットを生成します。

ボリューム有効期限ポリシー

メディア・ファミリを作成する際、メディア・ファミリのボリュームがいつ上書きまたは再利用が可能になるかを決定する、ボリューム有効期限ポリシーを指定します。図1-10に示すとおり、メディア・ファミリのボリュームは、コンテンツ管理の有効期限ポリシー、または時間管理の有効期限ポリシーのどちらかを使用します。

図1-10 ボリューム有効期限ポリシー

図1-10の説明が続きます
「図1-10 ボリューム有効期限ポリシー」の説明
コンテンツ管理の有効期限ポリシー

コンテンツ管理の有効期限ポリシーを使用するボリュームに対して、ファイルシステム・バックアップではなくRMANバックアップを実行できます。コンテンツ管理のボリュームの有効期限は、ボリュームに格納されているバックアップ・ピースに関連付けられている属性に基づいて決まります。ボリューム上の各バックアップ・ピースが削除済のマークが付けられると、ボリュームは再利用可能になります。コンテンツ管理のボリューム・セット内のボリュームは、そのセット内の他のボリュームがまだ期限内であっても、期限切れとなることがあります。

コンテンツ管理のボリュームは、ユーザー定義のRMAN保存設定に基づくため、バックアップ・ピースを削除済といつマークするかはRMANによってOracle Secure Backupに指示されます。実際のバックアップ・ピースはボリュームから削除されません。Oracle Secure Backupカタログの属性の値のみが更新されます。

Oracle Secure Backupをインストールする際、ソフトウェアにはRMAN-DEFAULTと呼ばれる、デフォルトのコンテンツ管理メディア・ファミリが含まれます。このメディア・ファミリの削除や名前変更はできませんが、Oracle Secure Backup Webツールまたはobtoolchmfコマンドによって特定の属性は変更できます。

図1-10に示すとおり、RMANまたはOracle Secure Backupインタフェースを使用してバックアップ・ピースを削除できます。Oracle Secure Backupツールによってバックアップ・ピースを削除すると、テープの内容と一致しないRMANリポジトリ内のメタデータはそのままになります。RMANバックアップがOracle Secure Backupレベルでテープから削除されている場合、またはテープ上のRMANバックアップがその他の理由で使用不可であったり消失している場合は、すぐにRMAN CROSSCHECKコマンドを使用して、RMANリポジトリを更新します。

関連項目:

時間管理の有効期限ポリシー

時間管理メディア・ファミリのボリュームは、ボリューム有効期限に達すると期限切れになります。この時点で、このボリューム・セット内の各ボリュームは上書きが可能であるとOracle Secure Backupで自動的に判断されます。

図1-10に示すとおり、ボリューム有効期限は次の要素を加算して算出されます。

  • セット内の最初のボリュームに対するボリューム作成時間

    これは、Oracle Secure Backupがバックアップ・イメージのファイル番号1をボリューム・セット内の最初のボリュームに書き込んだ時間です。

  • 書込みウィンドウ期間

    これは、メディア・ファミリのボリュームへの書込みが可能な、ユーザー指定の期間範囲です。ボリューム・セット内のすべてのボリュームが同じ書込みウィンドウを共有します。

  • 保存期間

    これは、メディア・ファミリのボリュームへの上書きが不可能な、ユーザー指定の期間範囲です。ボリューム・セット内のすべてのボリュームが同じ保存期間を共有します。

    書込みウィンドウが構成されていない場合、最初のテープの書込みから保存期間が開始します。書込みウィンドウが構成されている場合は、ボリューム・セットの書込みウィンドウが閉じたときに保存期間が開始します。

    保存期間の設定によって、指定された期間が過ぎるまで、このメディア・ファミリのすべてのボリュームへの上書きが不可能になります。あるボリュームがいっぱいになり、Oracle Secure Backupが引き続き次のボリュームにバックアップを行う場合、各ボリュームに同じ保存期間が割り当てられます。

たとえば、メディア・ファミリの書込みウィンドウを7日間、保存期間を14日間に設定した場合、ボリューム・セットのすべてのボリュームのデータは、書込みウィンドウが閉じてから14日間保存されます。Oracle Secure Backupが、まず1月1日の正午にセット内の最初のボリュームに書き込み、その後セット内の次の20ボリュームにデータを書き込んだとすると、セット内の21ボリュームはすべて1月22日の正午に期限切れとなります。

時間管理のボリュームに対してファイルシステム・バックアップとRMANバックアップの両方を実行することができます。つまり、時間管理の有効期限ポリシーを持つボリュームには、ファイルシステム・バックアップとRMANバックアップのピースを混同できます。時間管理のボリュームにRMANバックアップを実行すると、時間管理の有効期限ポリシーによって、RMANに設定されている保存の設定が上書きされます。

ノート:

RMANバックアップを時間管理ボリュームに対して実行した場合、RMANリポジトリではバックアップ・ピースが使用可能であるとレポートされていても、ボリュームが期限切れになり再利用される可能性があります。この場合、RMANでCROSSCHECKコマンドを使用して、矛盾を解決する必要があります。

クラウド・ストレージ・デバイスについて

Oracle Secure Backupのクラウド・ストレージ・デバイスを使用して、Oracle Cloud Infrastructure Object Storage ClassicおよびOracle Cloud Infrastructure Object Storageとの間でデータをバックアップおよびリストアします。クラウド・ストレージ・デバイスは、Oracle Cloudユーザーのアイデンティティ・ドメイン内のクラウド・ストレージ・コンテナを操作します。クラウド・ストレージ・コンテナは、バックアップ・イメージ・インスタンスのリポジトリとして機能します。

各クラウド・ストレージ・デバイスは、1つのクラウド・コンテナのみに関連付けられています。クラウド・コンテナのストレージ・クラス・オプションは次のとおりです。

  • Oracle Cloud Infrastructure ClassicとOracle Cloud Infrastructureの両方のための標準ストレージ・クラス(object)

  • Oracle Cloud Infrastructure ClassicとOracle Cloud Infrastructureの両方のためのアーカイブ・ストレージ・クラス(archive)

  • Oracle Cloud Infrastructureのための低頻度アクセス・ストレージ・クラス(infrequentaccess)

関連項目:

クラウド・ストレージ・デバイスは、Oracle Secure Backupのデバイス・リソースです。バックアップ・ジョブは、クラウド・ストレージ・デバイスを使用するように明示的に構成する必要があります。クラウド・ストレージ・デバイスは、ファイル・システム・バックアップ、またはOracleデータベースのRMANバックアップを格納できます。クラウド・ストレージ・デバイスには、複数のバックアップおよびリストア・ジョブが同時にアクセスできます。現在のジョブ数がデバイスのconcurrentjob設定で定義されます。各バックアップ・ジョブまたはリストア・ジョブでは、Oracle Cloudストレージへのパラレル・データ接続を作成します。パラレル接続の数はデバイスのstreamsperjob設定によって制御されます。

クラウド・ストレージ・デバイスとその関連コンテナは、1つのOracle Secure Backup管理ドメインにのみ属することができます。複数のOracle Secure Backup管理ドメインで共有することはできません。

Oracle Secure Backupが各バックアップ・イメージ・インスタンスを格納する際は、インスタンスを複数のセグメントに分割し、各セグメントを単一のオブジェクトとしてコンテナに格納します。セグメント・サイズはオブジェクトのサイズを定義し、デバイスのsegmentsizeパラメータによって指定されます。

バックアップ・イメージ・インスタンスは、期限切れになるか、明示的に削除されるか、クラウド・アーカイブ・コンテナに移行されるまでクラウド・コンテナ内に残されます。Oracle Secure Backupは、期限切れになった直後でなく、デバイスの空き領域しきい値を超過したときに、期限切れのバックアップ・イメージ・インスタンスを削除します。

Oracle Secure Backupにより、バックアップ・データは、クラウドに書き込まれる前にクライアント上で確実に暗号化されます。バックアップ・ジョブが暗号化を必要としない場合は、Oracle Secure Backupのクライアント側ソフトウェアの暗号化が自動的に強制オンとなり、クライアントで設定された暗号化ポリシーがクラウド・ストレージ・デバイスに書き込まれるバックアップ・データに適用されます。

バックアップ・データをディスク・プールにステージングし、自動化されたステージングを使用してクラウド・ストレージ・デバイスに移動できます。ディスク・プールのバックアップ・データをクラウド・ストレージ・デバイスにコピーするには、バックアップ・データを暗号化する必要があります。ただし、クラウド・ストレージ・デバイスは、自動ステージングのソース・デバイスとして使用できません。

バックアップ・イメージ・インスタンスは、手動コピー・ジョブを使用して標準ストレージ・クラス(object)コンテナから低頻度アクセス・ストレージ・クラス・コンテナまたはアーカイブ・ストレージ・クラス・コンテナに移動できます。両方のコンテナが同じアイデンティティ・ドメイン内に存在する必要があります。標準オブジェクト・ストレージ・コンテナと低頻度アクセス・ストレージ・コンテナまたはアーカイブ・ストレージ・コンテナの間でのコピーでは、データがクライアントにダウンロードされません。

マルチパート・アップロードを使用したOracle Secure Backup

Oracle Secure Backupは、マルチパート・アップロードを使用してセキュアなバックアップおよびリストア操作を実行し、効率的なバックアップ・ジョブを実現できます。

バックアップ・ジョブとリストア・ジョブは、メディア・サーバーで実行されます。Oracle Secure Backupは、セグメント化されたチャンクのデータをクラウド・ストレージ・デバイスにアップロードします。バケットで、各セグメントが単一のオブジェクトとして書き込まれます。セグメント・サイズは、10MBから1GBの間のどれでもかまいません。大規模なバックアップでは、バケット内に多数のオブジェクトが生成されます。大量のオブジェクトの管理は、バックアップの数が増えるにつれて困難になります。処理によっては、インスタンスの削除、ストレージの再利用、クラウド・コピー、長時間を要するバックアップのカタログ化など、パフォーマンスの問題が発生するものがあります。

マルチパート・アップロードでは、バックアップ・セグメントが並行してアップロードされ、バックアップ全体がアップロードされると、セグメントが連結されて単一のオブジェクト(セグメント)が形成され、バケット内のオブジェクト数が少なくなります。これは、前述の操作のパフォーマンスを向上させるのに役立ちます。

関連項目:

Client Direct to Cloudについて

Oracle Secure Backupには、Oracle Cloud Infrastructureオブジェクト・ストレージにバックアップをアップロードするためのオプションが用意されています。

図1-11 Client Direct to Cloud機能



通常、バックアップ操作中、クライアントはバックアップ・データをOracle Secure Backupメディア・サーバーに送信します。このメディア・サーバーはデータをメモリーにバッファリングし、後でクラウド・オブジェクト・ストレージにアップロードします。これらのステップでは、メディア・サーバーに追加のリソースが必要です。十分なリソースがなく、同時に実行されるバックアップ・ジョブが多すぎると、バックアップ・スループットが低下する可能性があります。

バックアップ・ジョブのスループットを向上させるには、Client Direct to Cloud機能を使用します。この機能を使用すると、クライアント・ホストは、メディア・サーバーの介入なしにバックアップ・データをOracle Cloud Infrastructureオブジェクト・ストレージに直接アップロードできます。管理サーバーにCPU、メモリー、ストレージなどの十分なリソースがある場合、このオプションを使用すると、バックアップのアップロードに追加のメディア・サーバーを使用する必要がなくなります。

ノート:

クライアント・ホストとクラウド・ストレージ・デバイスの両方でClient Direct to Cloud機能を有効にする必要があります。クライアントまたはクラウド・ストレージ・デバイスのいずれかの場所でのみ有効になっている場合、この機能は無効状態のままになります。

主な利点

  • バックアップをクラウド・ストレージに直接アップロードできるため、バックアップ・スループットが向上します。

  • メディア・サーバーでの追加のメモリーまたはCPUが必要なくなります。

  • クライアントがバックアップをクラウド・ストレージに直接アップロードするため、この構成はよりスケーラブルです。

関連項目:

不変バケットのバックアップについて

Oracle Secure Backupは、Oracle Cloud Infrastructureが提供する不変バケット機能をサポートしています。この機能により、Oracle Secure BackupOracle Cloud Infrastructureのオブジェクト・ストレージおよびアーカイブ・ストレージにバックアップを格納できますが、データの変更や削除は防止されます。

Oracle Cloud Infrastructureには、特定の期間にわたって不変バケット内のデータを保護するための様々なタイプの保持ルールが用意されています。バケットの保持ルールを構成すると、バケット内のすべてのオブジェクトに適用されます。

保持ルール

バックアップ・データの場合、Oracle Secure Backupでは、Oracle Cloud Infrastructureの次の保持ルールを作成および管理できます:

  • コンプライアンス・ルール: これらのルールは、特定のバケットがオブジェクトを格納する期間を定義します。この期間中は、データに複数回アクセスして読取りできますが、変更または削除することはできません。オブジェクトに複数のコンプライアンス・ルールがある場合、オブジェクト・ストレージでは最長期間のルールが考慮されます。保存ルールは、オブジェクトの最終変更タイムスタンプにも依存します。

    たとえば、オブジェクト・ストレージ・バケットには、3つのオブジェクトA、BおよびCがあり、それぞれ3か月、6か月および1年前にアップロードまたは最終変更されています。
    • バケットに9か月間のコンプライアンス・ルールを作成すると、オブジェクトAとBはすぐに不変になりますが、オブジェクトCは変更または削除できます。

    • バケットの保持期間を2年に変更すると、3つのオブジェクトはすべて不変になります。オブジェクトCは1年後に可変になり、オブジェクトBは1年6か月後に可変になり、オブジェクトAは1年9か月後に可変になります。

    Oracle Cloud Infrastructureには、これらの時間ベースの保持ルールにロックを適用するオプションが用意されています。保持ルールがロックされている場合、保持時間を増やすことはできますが、そのルールを短くしたり削除したりすることはできません。ルールを削除するには、オブジェクト・ストレージ・バケット内のすべてのオブジェクトを可変にし、バケットを削除する必要があります。

    ノート:

    オブジェクト・ストレージ・バケットは、空の場合のみ削除できます。

  • 法的保留: これらのルールは、バックアップを保持する規制上の義務を示します。法的保留には期間は関連付けられていません。

    不変バケット内のバックアップ・データにコンプライアンス・ルールがあり、それに法的保留を適用した場合、法的保留が優先されます。その結果、データは、コンプライアンス・ルールで指定された期間を超えてオブジェクト・ストレージに残ります。コンプライアンス・ルールは、そのバケットの法的保留が削除された後にのみ有効になります。法的保留にロックを適用することはできません。

Oracle Secure Backupを使用すると、Oracle Cloud Infrastructureオブジェクト・ストレージのバケットに対して1つの時間ベースのコンプライアンス・ルールと1つの法的保留ルールを作成できます。

ノート:

Oracle Secure Backupからルールを管理するには、Oracle Secure Backupを使用してルールを作成してください。Oracle Secure Backupを使用して、Oracle Cloud Infrastructureコンソールなどの他のソースを使用して作成されたルールを変更または削除することはできません。