ETERNUS SF AdvancedCopy Manager 運用手引書 13.0 -Solaris- |
目次
索引
![]() ![]() |
本章では、Symfowareのバックアップ運用について説明します。
Symfowareのバックアップ運用は、管理対象のStorageサーバが Solaris、Linux、Windowsの場合のみ有効となります。
AdvancedCopy Managerによってバックアップ運用を行うSymfowareのデータベーススペースは、rawデバイス上に配置されたもののみです。
AdvancedCopy Managerは、ディスクアレイ装置(ETERNUS ディスクアレイ)のディスクボリュームに配置されたSymfowareのデータベーススペースを、業務ボリュームとして管理します。
そのため、AdvancedCopy Managerでは、Symfowareのデータベースの格納構造を意識せずに、データベーススペースという物理的に配置された構造で、バックアップ/リカバリを行うことができます。
Symfowareは、Storageサーバ内に配置されたデータベーススペースやロググループを、いろいろな業務の用途に合わせて、複数の動作環境を作成することができます。この動作環境を、RDBシステム名という名前で区別します。AdvancedCopy Managerは、このRDBシステム名を元に、動作環境内のデータベースの表間のリレーションの整合性を破壊することなく、バックアップ/リカバリを行います。
Symfowareの概要全般については、『Symfoware(R) Server RDB 管理者ガイド』または『Symfoware(R) Server RDB運用ガイド』を参照してください。
AdvancedCopy Managerでは、Symfowareのデータベーススペースを、データベーススペース単位またはロググループ単位で、バックアップを行うことができます。
AdvancedCopy Managerでは、バックアップ対象とするデータベーススペースが配置されているスライスを業務ボリュームとします。
データベーススペース単位のバックアップでは、その業務ボリュームをバックアップ退避先ボリューム(バックアップボリューム)にバックアップします。
ロググループ単位のバックアップでは、ロググループに含まれるすべてのデータベーススペースをそれぞれ業務ボリュームとして定義し、そのすべての業務ボリュームをバックアップします。
ロググループ単位でバックアップする場合、ロググループに含まれるすべてのデータベーススペースが配置されているスライスを、それぞれ業務ボリュームとして登録しておく必要があります。ひとつでも登録から漏れると、AdvancedCopy Managerは登録から漏れたデータベーススペースをバックアップすることができず、データベースのリカバリ時に表間のリレーションの整合性が保てなくなります。
AdvancedCopy Managerは、バックアップ時に、データベースのリカバリに必要なデータを格納したリカバリ制御ファイルを作成し、バックアップした世代毎に管理します。
AdvancedCopy Managerでは、Symfowareのデータベーススペース単位またはロググループ単位でのデータベーススペースのリカバリが行えます。
AdvancedCopy Managerのリカバリは、次のように処理が行われます。
適切なリカバリ制御ファイルとバックアップボリュームを選択します。
バックアップボリュームを業務ボリュームへ複写します。
最新の状態、または特定の時点へ復旧する場合は、リカバリ制御ファイルを元に、アーカイブログを適用します。
アーカイブログファイルに、アーカイブログがいっぱいになると、Symfowareのコマンドや、データベーススペースを使用する利用者のアプリケーションが無応答になるため、アーカイブログを外部媒体に退避することがありますが、AdvancedCopy Managerは、外部媒体に保管したアーカイブログ退避ファイル名を書いたファイル(アーカイブログ退避先名が列挙されたファイル)を指定してリカバリすることができます。
『アーカイブログ退避先名が列挙されたファイル』に指定したファイルに、MT(テープ装置)に退避されたアーカイブログ退避ファイルを記述した場合は、リカバリを行うことができません。
また、リカバリ時には、本マニュアルの『Storageサーバ構成情報設定コマンド』で指定した作業ディレクトリを使用します。
AdvancedCopy ManagerでバックアップしたSymfowareのデータベーススペースは、AdvancedCopy Managerでリカバリする必要があることから、バックアップボリュームをテープなどの二次媒体に退避しても二次媒体から直接リカバリすることはできません。
そのため、Symfowareのデータベーススペースをテープにバックアップする場合は、テープサーバを導入したバックアップ運用を行うことを推奨します。
アーカイブログを退避する運用の場合、データベーススペースのリカバリに必要な退避アーカイブログの対応を知る必要があります。 AdvancedCopy Managerは、そのために必要なロググループ単位に行われるアーカイブログ退避処理と、データベーススペース単位に行われるバックアップ/リカバリの対応管理を行います。データベースの管理者は、単純にアーカイブログ退避状況の記録のみを行えばよくなります。具体的な運用としては、アーカイブログの退避作業をシェルスクリプト化し、Storageサーバ上のファイルに履歴を記録する形態を推奨します。
Symfowareのバックアップ運用の設計は、以下の手順で行います。
AdvancedCopy Managerで、Symfowareのデータベーススペース単位、またはロググループ単位のデータベーススペースのバックアップ/リカバリを行う環境を作成するためには、事前にデータベースの管理者が、業務の用途に合わせてSymfowareの動作環境を作成する必要があります。
Symfowareのマニュアルを参考にして設計を行ってください。
ただし、データベーススペースの配置については以下の制限事項を守って設計を行ってください。
ローデバイス上にデータベーススペースを配置する場合、AdvancedCopy Manager のコピー単位(ボリューム単位)と、データベーススペース領域は一致するので特に考慮する点はありません。
ローデバイス上にデータベーススペースを作成する方法は「Symfoware(R) Server RDBユーザーズガイド データベース定義編」を参照してください。
ローデバイス上にデータベーススペースを配置する構成のみをサポートします。ファイルシステム上にデータベーススペースを配置する構成はサポートされません。
AdvancedCopy Managerでバックアップを行う場合、RDBシステム名、ロググループ名に2バイト以上のコード(ひらがな、漢字など)を使用することはできません。
バックアップ運用を行うサーバを決定します。
バックアップ運用を行うサーバには、次のものがあります。
Storage管理サーバ
複数のStorageサーバを一元管理、集中操作します。Storage管理サーバは、Storageサーバを兼ねることができます。
Storageサーバ
AdvancedCopy Managerの運用を行います。
すべてのStorageサーバには、AdvancedCopy Managerが使用する内部コード系(Storage管理サーバへAdvancedCopy Managerをインストールする際に指定するコード系)のロケールがインストールされている必要があります。
バックアップ対象とするSymfowareのデータベーススペースが割り当てられたスライスを決定します。
AdvancedCopy Managerでは、バックアップ対象となるSymfowareのデータベーススペースが割り当てられたスライスのことを業務ボリュームと呼びます。
業務ボリュームは以下のようにスライスの割り当てを行う必要があります。
VTOCを含まないようにスライスを作成してください。
同一ディスク内には、重複しないようにスライスを作成してください。
ロググループ単位でバックアップする場合、ロググループに含まれるすべてのデータベーススペースが配置されているスライスを、それぞれ業務ボリュームとして登録しておく必要があります。ひとつでも登録から漏れると、AdvancedCopy Managerは登録から漏れたデータベーススペースをバックアップすることができず、データベースのリカバリ時に表間のリレーションの整合性が保てなくなります。
システムが格納されているスライスや、AdvancedCopy Managerがインストールされているスライスは、バックアップ対象としないでください。
ボリューム全体を定義したスライスは、業務ボリュームとして登録しないでください。
業務ボリュームまたはロググループに対して設定するバックアップポリシーを決定します。
ロググループに対して設定した場合、そのロググループに含まれるすべての業務ボリュームに対してバックアップポリシーが設定されます。
バックアップポリシーには以下の条件項目があります。
保存世代数とはバックアップを行ったデータを何世代残しておくかを意味します。
スナップショット型高速バックアップは、最初に最古の世代を世代管理より解放します。そのため、バックアップ起動中にシステムダウンなどの障害が発生した場合は、バックアップしたデータが必要世代数分存在しない可能性がありますので、直ちにバックアップを再実行することをお勧めします。
スナップショット型高速バックアップで、保存世代数を1として運用する場合は、バックアップデータをテープなどに退避する運用を併用することをお勧めします。
同期型高速バックアップは、最古の世代を世代管理より解放するのは、最新世代のバックアップを完了してからです。そのため、(保存世代数+1)本のバックアップボリュームが必要です。
バックアップ未実施の警告を表示する基準日数を意味します。
最後にバックアップした日より間隔日数を超えた場合に、業務一覧画面上や実行状態表示コマンド(swstexecstat)で遅れが出ていることを表示します。
間隔日数を設定しても、自動的にバックアップが行われるわけではありません。
バックアップボリュームを準備します。
AdvancedCopy Managerでは、業務ボリュームのバックアップ先スライスのことをバックアップボリュームと呼びます。バックアップボリュームは、ETERNUS ディスクアレイに配置する必要があります。
バックアップボリュームのサイズは、業務ボリュームと同じである必要があります。また、バックアップボリュームの数は、バックアップの運用によって、以下の様に異なります。
バックアップ運用 |
必要バックアップボリューム数 |
---|---|
スナップショット型高速バックアップ運用の場合 |
保存世代数 本 |
同期型高速バックアップ運用の場合 |
(保存世代数 + 1)本 |
すでに複数の業務ボリュームにバックアップポリシーが設定されている状態で、新たに登録された業務ボリュームにバックアップポリシーを登録する場合、以下の本数のバックアップボリュームが必要です。
バックアップ運用 |
必要バックアップボリューム数 |
---|---|
スナップショット型高速バックアップ運用の場合 |
(登録されているバックアップポリシーの保存世代数の総和+新たに設定するバックアップポリシーの保存世代数)本 |
同期型高速バックアップ運用の場合 |
(登録されているバックアップポリシーの保存世代数の総和+登録されている業務ボリューム数+新たに設定するバックアップポリシーの保存世代数+1)本 |
ロググループを指定してバックアップポリシーを設定する場合、以下の本数のバックアップボリュームが必要です。
バックアップ運用 |
必要バックアップボリューム数 |
---|---|
スナップショット型高速バックアップ運用の場合 |
(ロググループに含まれる業務ボリュームの数)×(設定するバックアップポリシーの保存世代数)本 |
同期型高速バックアップ運用の場合 |
(ロググループに含まれる業務ボリュームの数)×(設定するバックアップポリシーの保存世代数+1)本 |
バックアップボリュームは以下のようにスライスの割り当てを行う必要があります。
VTOCを含まないようにスライスを作成してください。
同一ディスク内には、重複しないようにスライスを作成してください。バックアップボリューム内には、通常のスライス2のようなボリューム全体を意味するスライスは作成する必要はありません。
Symfowareのバックアップ運用では、次のディレクトリを設定する必要があります。
リカバリ制御ファイル出力先ディレクトリ
作業ディレクトリ
リカバリ制御ファイル出力先ディレクトリとは、バックアップ時に作成されるリカバリ制御ファイルの格納先です。
リカバリ制御ファイルに必要な容量は、1業務ボリュームを1世代分バックアップすると約1Mバイトになります。
N個の業務ボリュームをM世代保存する場合に必要な容量は、次のようになります。
バックアップ運用 |
必要な容量(単位 Mbyte) |
---|---|
スナップショット型高速バックアップ |
N × M |
同期型高速バックアップ |
N × (M + 1) |
バックアップ運用開始時にリカバリ制御ファイル出力先ディレクトリを設定していない場合は、以下のディレクトリを使用します。
通常(非クラスタ)運用の場合
/etc/opt/FJSVswsts/SymfoWARE/Recovery
クラスタ運用の場合
/etc/opt/FJSVswsts/論理ノード名(*1)/SymfoWARE/Recovery
(*1)クラスタセットアップ時に指定したAdvancedCopy Managerの論理ノード名
作業ディレクトリとは、リストア時にデータベースのリカバリ作業を行うための作業ディレクトリです。
バックアップ運用開始時に作業ディレクトリを設定していない場合は、以下のディレクトリを使用します。
/var/opt/FJSVswsts/SymfoWARE
Symfowareにおける一連のバックアップ運用の流れを以下に記述します。
バックアップ運用を開始するにあたり、事前に以下の準備が必要です。
バックアップ運用を開始するにあたり、事前にStorage管理サーバ、Storageサーバ上でデーモンを起動する必要があります。
通常、システムの起動時に自動的に立ち上がりますが、何らかの理由で起動に失敗した場合および一度デーモンを停止した場合は、各サーバでデーモンを起動する必要があります。デーモンの起動については、本マニュアルの『デーモンの起動と停止』を参照してください。
バックアップ運用をバックアップ管理画面から行う場合は、バックアップ管理画面の各操作のアクセス権を設定します。設定方法の詳細については、本マニュアルの『認証機構によるセキュリティ運用』を参照してください。
バックアップ運用をコマンドのみで行う場合は、アクセス権の設定は必要ありません。
以下のURLを指定し、AdvancedCopy Managerの初期画面を起動します。クラスタ運用時はURLが異なります。詳細は、『ETERNUS SF AdvancedCopy Manager使用手引書 初期画面』を参照してください。
http://Storage管理サーバのアドレス(:ポート番号)/swstorage/index.html |
以下のWeb画面(サーバ一覧画面)が起動します。
なお、Web画面を使用せずにコマンドのみで運用する場合は、本操作を行う必要はありません。
Storage管理サーバをクラスタ運用している場合
Storage管理サーバをクラスタ運用している場合、Web画面を使用するためには、『ETERNUS SF AdvancedCopy Manager 使用手引書 認証関連ファイルの設定』の認証関連ファイルの設定が必要となります。
Storage管理サーバにて、管理するStorageサーバを登録します。Storage管理サーバを兼ねているStorageサーバは、サーバの追加をする必要はありません。
[操作]メニューから[サーバの追加]を選択します。以下の画面が表示されます。
追加するStorageサーバのサーバ名、IPアドレスおよび通信に必要なポート番号を指定します。ポート番号にはStorageサーバ側の通信デーモンに指定したポート番号を指定します。
Storageサーバをクラスタで運用している場合、IPアドレスにはAdvancedCopy Manager用に割り当てたStorageサーバの引き継ぎIPアドレスを指定します。また、ポート番号にはクラスタセットアップ時に登録した業務用通信デーモンに指定したポート番号を指定します。
以上の項目を入力後、[OK]ボタンを押して、Storageサーバの追加処理を実施します。
なお、この処理は、本マニュアルの『サーバ情報追加コマンド(stgxfwcmaddsrv)』でも実施できます。
バックアップ管理を実施する場合は、まずStorageサーバ上のデバイス情報を一旦リポジトリに格納する必要があります。Storageサーバのデバイス情報を取り出すため、[操作]メニューから[全デバイスの情報取得/反映]を選択します。以下の画面が表示されます。
デバイス情報を取り出すサーバを確認後、[OK]ボタンを押します。
各サーバからデバイス情報を取得後、以下のダイアログが表示されます。
一番上のリストボックスは、新規にデバイスが検出された場合、表示されます。管理するデバイスを左側のリストボックスに移動します。二番目のリストボックスは、現在管理対象となっているデバイスのうち、今回検出できなかったデバイスです。管理対象外にする場合は、右側のリストボックスに移動します。一番下のリストボックスは、デバイス情報が更新(例えば、マウントポイント名が変更)されたデバイスです。
以上の操作を実施後、[OK]ボタンを押して、デバイス情報の取得処理を実施します。
なお、この処理は、本マニュアルの『デバイス情報取得/反映コマンド(stgxfwcmsetdev)』でも実施できます。
Symfoware情報を取得するためには、事前にSymfoware Server Advanced Backup Controller 6.0以降が動作している必要があります。デバイス情報取得後にSymfoware Server Advanced Backup Controllerをインストールした場合は、再度デバイス取得を実施してください。
この操作は、選択したStorageサーバに定義されているデバイスの総数に比例した時間がかかります。デバイス数が多い場合はCPU負荷やI/O負荷の低い状態で実施してください。
目安として、負荷のない状態で、1デバイス(パーティション)あたり約0.5秒かかりますので、参考として下さい。
サーバ一覧画面の[ファイル]メニューから[Backup管理]を選択すると、バックアップ管理のサーバ一覧画面が表示されます。
各Storageサーバの環境設定を行います。バックアップ管理画面にて、Storageサーバを選択している状態で、[操作]メニューから[サーバ情報の設定]を選択すると、以下の設定画面が表示されます。
対象となるStorageサーバがSolarisまたはLinuxの場合で、Storageサーバ内にSymfowareデータベースが存在している場合は、リカバリ制御ファイル出力先ディレクトリおよび作業ディレクトリを入力します。Storageサーバ内にSymfowareデータベースが存在しない場合や、Symfoware連携を行うための環境が整っていない場合は、本入力項目はハーフトーン表示となり、入力する事はできません。
必要となる項目の入力が完了後、[OK]ボタンをクリックします。
Storage管理サーバがStorageサーバを兼ねている場合、Storage管理サーバでもこの環境設定を行う必要があります。既に、Storageサーバの環境設定が行われている場合は、この作業は必要ありません。
なお、本環境設定は、本マニュアルの『Storageサーバ構成情報設定コマンド(swstsvrset)』でも実施できます。
バックアップを行いたいSymfowareのデータベーススペースを構築したスライスを業務ボリューム、バックアップ先となるボリュームをバックアップボリュームとして定義します。
本マニュアルの『デバイス情報設定コマンド(swstdevinfoset)』を用いて、バックアップを行いたいSymfowareのデータベーススペースを構築したスライスを、業務ボリュームとして定義します。
ロググループの場合は、ロググループに含まれるすべてのデータベーススペースが配置されているスライスを、それぞれ個別に業務ボリュームとして登録する必要があります。ひとつでも登録から漏れるとAdvancedCopy Managerは登録から漏れたデータベーススペースをバックアップすることができず、データベースのリカバリ時に表間のリレーションの整合性が保てなくなります。
Symfowareのデータベーススペースが設定されていないデバイスを、Symfoware用の業務ボリュームとして設定することはできません。
Symfoware用の業務ボリュームに割り当てられたRDBシステム名やデータベーススペース名、ロググループ名等を変更した場合は、以下の手順で業務ボリュームとして登録しなおしてください。
既に登録した業務ボリュームのバックアップ履歴情報を履歴情報削除コマンドですべて削除します。
既に登録した業務ボリュームのバックアップポリシーをすべて削除します。
デバイス情報設定コマンドを使用して業務ボリュームの登録から削除します。
再度、本マニュアルの『Storageサーバ配下のデバイス情報の取り込み』を行います。
デバイス情報設定コマンドを使用して業務ボリュームとして登録しなおします。
ロググループに含まれる業務ボリュームを登録から削除する場合は、その業務ボリュームのバックアップポリシーおよびバックアップ履歴情報をすべて削除してから、業務ボリュームの登録から削除してください。
本マニュアルの『デバイス情報設定コマンド(swstdevinfoset)』を用いて、バックアップ先とするバックアップボリュームを設定してください。既にバックアップボリュームを登録してある場合は、この操作は不要です。
バックアップ管理が必要とするバックアップボリュームの本数については、本マニュアルの『バックアップボリュームの準備』を参照してください。
バックアップボリュームとして登録したパーティション(スライス)の構成などを変更する場合は、構成を変更する前に一旦バックアップボリュームの登録から削除し、構成変更後に再度Storageサーバ配下のデバイス情報の取り込みを行ってから、『デバイス情報設定コマンド(swstdevinfoset)』で登録し直す必要があります。
業務ボリュームの存在する筐体とは別の筐体にあるバックアップボリュームにバックアップを行う場合は、オプションの設定を行います。
REC/ROPC機能が動作可能なディスクアレイ装置が必要です。
両筐体がFCRA(FC Remote Adapter)で接続されていることが必須です。
FCRAによる接続ではデータはINIT側からTARG側へしか流れませんので最低2組のFCRA接続が必要です。
バックアップ運用では、リストアの際にROPC機能を利用するため、ROPC機能が動作しない(REC機能のみが動作可能な)ディスクアレイ装置では、業務ボリュームの存在する筐体とは別の筐体にあるバックアップボリュームにバックアップを行う運用はできません。
オプションの設定は以下のファイルを作成します。
通常(非クラスタ)運用の場合 /etc/opt/FJSVswsts/data/DEFAULT/check.ini クラスタ運用の場合 /etc/opt/FJSVswsts/論理ノード名(*1)/data/DEFAULT/check.ini |
(*1) クラスタセットアップ時に指定したAdvancedCopy Managerの論理ノード名。
記述方法を以下に示します。
[check] RemoteCopy=Yes |
運用開始後にオプション設定ファイルを変更すると、バックアップ運用が継続できなくなる場合があります。そのため、運用開始後はオプション設定ファイルを変更しないでください。
オプション設定ファイルを変更する場合は、バックアップポリシーを再設定する必要があります。
本マニュアルの『バックアップポリシー設定コマンド(swstbkpolset)』を用いて、業務ボリュームまたはロググループにバックアップポリシーを設定します。
ロググループに対して設定した場合、そのロググループに含まれるすべての業務ボリュームに対してバックアップポリシーが設定されます。
バックアップポリシーの詳細は、本マニュアルの『バックアップポリシーの決定』を参照してください。
バックアップポリシーの設定時には、バックアップ運用に必要なバックアップボリュームが登録されている必要があります。バックアップ運用に必要なバックアップボリューム数については、本マニュアルの『バックアップボリュームの準備』を参照してください。
登録されているバックアップポリシーは、本マニュアルの『バックアップポリシー表示コマンド(swstbkpoldisp)』で表示することができます。
登録されているロググループに新たにデータベーススペースを追加し、業務ボリュームとして設定した場合は、再度ロググループ単位でバックアップポリシーの設定を行ってください。
AdvancedCopy Managerのバックアップ運用では、バックアップボリュームとして登録されているボリューム群から、業務ボリュームの容量と同一のボリュームを、AdvancedCopy Managerが自動的に選択し、バックアップ先として利用します。
しかし、運用の都合上、バックアップ先ボリュームを意識したい場合は、あらかじめ「デバイスマップファイル」という業務ボリュームとバックアップボリュームの対応ファイルを作成しておく必要があります。
デバイスマップファイルは、バックアップを行うStorageサーバ上の任意の場所に作成します。このファイルをバックアップ実行時に指定する事で、バックアップ先を意識した運用が可能となります。
複数世代管理を行う場合は、デバイスマップファイルを複数用意する必要があります。
また、バックアップもしくは同期処理の開始時に使用できるデバイスマップファイルは、以下のいずれかの条件を満たしている必要があります。
未使用のバックアップボリュームを指定している
そのバックアップで削除される履歴で使用されているバックアップボリュームを指定している
そのため、バックアップボリュームを複数使用する運用の場合は、バックアップボリュームの状況に合わせてデバイスマップファイルを使い分ける必要があります。
デバイスマップファイルの記述例を以下に示します。
デバイスマップファイル作成時の規則を以下に示します。
1行に業務ボリュームと対応する出力先バックアップボリュームを記述します。業務ボリュームとバックアップボリュームの間を1個以上の「半角空白またはタブ文字」で区切ってください。また、行頭から業務ボリューム名の間、および、バックアップボリュームの後ろから行末(改行記号)の間には1個以上の「半角空白またはタブ文字」が含まれていても構いません。
空白行(「半角空白またはタブ文字」)がファイルに含まれていても構いません。
記号「#」から行末まではコメントとみなされます。
1つのデバイスマップファイルの中で1つの業務ディスクに対して出力先バックアップボリュームを複数指定することはできません。このような場合は、最初に見つかった行の情報が有効になります。デバイスマップファイルからの読みこみ処理では、このような重複行の検出は行いません。
デバイスマップファイルには、処理対象(Device-NameまたはLog-Group-Name)以外の業務ボリュームの記述があっても構いません(冒頭に示した記述例を参照してください)。
ロググループに対して出力先バックアップボリュームを定義する場合は、単一ファイル内に全ての業務ボリュームに関する記述をしなければなりません。(複数ファイルに記述がまたがっていてはいけません。)
Symfowareのバックアップ運用について説明します。
バックアップ運用を行う前に、本マニュアルの『事前準備』を参照して、バックアップ運用に必要な環境設定を行ってください。
AdvancedCopy Managerのバックアップの運用には、以下の2種類があります。
スナップショット型高速バックアップ運用
同期型高速バックアップ運用
Symfowareのスナップショット型高速バックアップは、業務ボリュームまたはロググループを指定して、本マニュアルの『バックアップ実行コマンド(swstbackup)』を用いて行います。ロググループ指定によるバックアップを行う場合、そのロググループに含まれる業務ボリュームすべてを一度にバックアップします。
次に挙げる方法でバックアップを行うことができます。
バックアップ方法 |
説明 |
---|---|
通常ダンプ |
アーカイブログ運用中(通常運用中)のデータベースをバックアップします。 |
参照ダンプ |
長期保存等の目的のためにアーカイブログ運用から切り離されたデータベースをバックアップします。 |
注)参照ダンプでバックアップする場合、Symfowareの"rdbrtr"コマンドを用いて、バックアップする業務ボリューム内の全DSI(実表に対してその格納構造を表現するもの)に更新抑止を設定(データ書き込み不可状態)する必要があります。
ロググループに含まれる業務ボリュームを個別にバックアップする場合は、参照ダンプは指定できません。
バックアップの実行は、業務ボリューム一覧画面を用いてWeb画面による指示が可能です。Web画面の詳細は、『ETERNUS SF AdvancedCopy Manager 使用手引書』を参照してください。
(ロググループに含まれる業務ボリュームを個別にバックアップする場合は、Web画面による指示はできません。)
Symfowareの同期型高速バックアップは、以下の手順で行います。
本マニュアルの『バックアップ同期処理開始コマンド(swststartsync)』を用いて、業務ボリュームまたはロググループを指定し、バックアップ同期処理を開始します。ロググループを指定した場合、そのロググループに含まれる業務ボリュームすべてに対してバックアップ同期処理を実行します。
開始したバックアップ同期処理のキャンセルは、本マニュアルの『バックアップ同期処理キャンセルコマンド(swstcancelsync)』で行います。
本マニュアルの『バックアップ同期処理実行状況表示コマンド(swstsyncstat)』で、バックアップ同期処理中のバックアップボリュームが等価性維持状態にあることを確認します。ロググループを指定してバックアップ同期処理を行っている場合は、ロググループに含まれるすべての業務ボリュームのバックアップボリュームが、等価性維持状態にあることを確認します。
業務ボリュームまたはロググループを指定し、本マニュアルの『バックアップ実行コマンド(swstbackup)』を実行してバックアップを採取します。本マニュアルの『バックアップ実行コマンド(swstbackup)』では、次に挙げる方法でバックアップを行うことができます。バックアップ実行コマンドを実行すると、その時点の状態がバックアップ履歴情報に登録され、バックアップ同期処理は停止されます。
バックアップ方法 |
説明 |
---|---|
通常ダンプ |
アーカイブログ運用中(通常運用中)のデータベースをバックアップします。 |
参照ダンプ |
長期保存等の目的のためにアーカイブログ運用から切り離されたデータベースをバックアップします。 |
注)参照ダンプでバックアップする場合、Symfowareの"rdbrtr"コマンドを用いて、バックアップする業務ボリューム内の全DSI(実表に対してその格納構造を表現するもの)に更新抑止を設定(データ書き込み不可状態)する必要があります。
業務ボリュームとバックアップボリュームが等価状態になる前にバックアップ実行コマンドを実行すると、バックアップ実行コマンドはエラーとなります。
バックアップ同期処理の開始およびバックアップの実行は、業務ボリューム一覧画面を用いてWeb画面による指示が可能です。Web画面の詳細は、『ETERNUS SF AdvancedCopy Manager 使用手引書』を参照してください。
(ロググループに含まれる業務ボリュームを個別にバックアップする場合は、Web画面による指示はできません。)
同期型高速バックアップでは、同期処理を停止または一時停止(サスペンド)することによりバックアップが作成されます。『バックアップ実行コマンド(swstbackup)』をサスペンド指定で実施すると、Suspend/Resume機能により、同期処理を一時停止(サスペンド)してバックアップを行います。Suspend/Resume機能については、本マニュアルの『Suspend/Resume機能によるバックアップ運用』を参照してください。
スナップショット型高速バックアップおよび同期型高速バックアップで退避したデータの復元には、本マニュアルの『リストア実行コマンド(swstrestore)』を用います。
Symfowareのリカバリは、業務ボリュームまたはロググループを指定して、バックアップ実行コマンド(swstbackup)でバックアップされた履歴管理されているバックアップボリュームから、リストア実行コマンド(swstrestore)を用いて行います。
ロググループを指定してリカバリを行う場合、ロググループに含まれる業務ボリュームを一度にリカバリします。
また、“-bundle”オプションを使用して同一ロググループの複数の業務ボリュームを一括してリカバリすることも可能です。これを、バンドル・リカバリと呼びます。
RAIDグループ内に複数のデータベーススペースが配置されている場合、これらのデータベーススペースを一括してリカバリすることにより、ログ適用にかかる時間が短縮され、リカバリ時間が短縮されます。
リカバリは、次に挙げる方法で実行することができます。
最新状態への復旧
リカバリ終了点を指定した特定時点への復旧
バックアップ時点への復旧
リカバリするデータのバックアップした方法(通常ダンプ/参照ダンプ)によって、指定できるリカバリ方法が異なります。次に示すような組み合わせで指定することができます。
バックアップ単位 |
バックアップ方法 |
リカバリ単位 |
リカバリ方法 |
||
---|---|---|---|---|---|
最新状態への復旧 |
リカバリ終了点を指定した特定時点への復旧 *1 |
バックアップ時点への復旧 |
|||
業務ボリューム |
通常ダンプ |
ロググループ |
○ |
○ |
○ |
同一ロググループの複数の業務ボリューム |
○ |
○ |
○ |
||
業務ボリューム |
○ |
× |
× |
||
ロググループ |
通常ダンプ |
ロググループ |
○ |
○ |
○ |
同一ロググループの複数の業務ボリューム |
○ |
○ |
○ |
||
業務ボリューム |
○ |
× |
× |
||
参照ダンプ |
ロググループ |
○ |
× |
○ |
|
同一ロググループの複数の業務ボリューム |
○ |
× |
○ |
||
業務ボリューム |
○ |
× |
× |
( ○:可能 ×:不可能 )
*1 |
: |
データベースの管理者が、業務運用中にSymfowareの"rdbsetrp"コマンドを用いてリカバリポイントを設定します。そのリカバリポイントはデータベースのリカバリ時まで覚えておく必要があります。 |
すべての方法において、リカバリ対象となるデータベーススペースがアクセス禁止状態になっている必要があります。アクセス禁止状態にするには、Symfowareが提供するコマンドの"rdbinh"コマンドまたは"rdbexspc"コマンドを用いて行います。コマンドの詳細は、『Symfoware(R) Server RDB 管理者ガイド』または『Symfoware(R) Server RDB運用ガイド』を参照してください。
ロググループに含まれる業務ボリュームを個別にリカバリする場合は、最新状態へ復旧するリカバリ方法のみ行うことができます。この場合、ロググループ内の表間のリレーションはデータベースの管理者の責任で整合させる必要があります。
“最新状態への復旧”、“特定時点への復旧”を行う場合、アーカイブログファイルが外部媒体に保管されていれば、リカバリ時に必要なアーカイブログ退避ファイル名を列挙したファイルを、リカバリを行う業務ボリュームが存在するStorageサーバに作成しておき、リカバリ時に指定する必要があります。このファイルの記述方法は、『Symfoware(R) Server RDB管理者ガイド』または『Symfoware(R) Server RDB運用ガイド』を参照してください。
リストア実行コマンドで実行したリカバリが、作業ディレクトリの空き容量不足で失敗した場合、“-w”オプションを使用して、一時的に別のディレクトリを作業ディレクトリとして再実行することにより、リカバリが可能になります。“-w”オプションの詳細は、本マニュアルの『リストア実行コマンド(swstrestore)』を参照してください。
“リカバリ終了点を指定した特定時点への復旧”もしくは“バックアップ時点への復旧”を行う場合、Symfowareの管理情報を復旧する処理が行われます。この処理はリカバリの実行処理の一部として実施されるため、コマンドの処理に時間がかかります。
データベーススペース単位にバックアップを実施した場合、ロググループ単位リカバリまたはバンドル・リカバリでは、世代指定に相対世代番号を指定するようにしてください。これは、以下の例のようにデータベーススペース単位にバックアップを実施した場合、特定の業務ボリューム(データベーススペース)の履歴が更新されるため、相対世代番号に対する絶対世代番号がそろわない状態が発生するからです。
(例)ロググループ(LOG1/RDB1)にデータベーススペース1(DB1.DBSP1)とデータベーススペース2(DB1.DBSP2)が存在する場合
1日目:データベーススペース1(DB1.DBSP1)をバックアップ
# /opt/FJSVswsts/bin/swstbackup /dev/dsk/c1t0d0s1 /dev/dsk/c1t0d0s1 swstbackup completed |
2日目:データベーススペース(DB1.DBSP1)とデータベーススペース2(DB1.DBSP2)を個別にバックアップ
# /opt/FJSVswsts/bin/swstbackup /dev/dsk/c1t0d0s1 /dev/dsk/c1t0d0s1 swstbackup completed # /opt/FJSVswsts/bin/swstbackup /dev/dsk/c1t0d0s2 /dev/dsk/c1t0d0s2 swstbackup completed |
履歴情報の表示
# /opt/FJSVswsts/bin/swsthistdisp -n LOG1/RDB1 Server=SV01 Device=/dev/dsk/c1t0d0s1 Mount-Point=DB1.DBSP1/LOG1/RDB1 (SymfoWARE) Generation Version Backup-Date Backup-Device Status Execute ArcSerial 1 2 2002/12/12 22:00 /dev/dsk/c1t0d2s2 succeeded ---- 5 2 1 2002/12/11 22:00 /dev/dsk/c1t0d2s1 succeeded ---- 5 Server=SV01 Device=/dev/dsk/c1t0d0s2 Mount-Point=DB1.DBSP2/LOG1/RDB1 (SymfoWARE) Generation Version Backup-Date Backup-Device Status Execute ArcSerial 1 1 2002/12/12 23:00 /dev/dsk/c1t0d2s3 succeeded ---- 5 |
以上のような履歴を使用したロググループ単位リカバリまたはバンドル・リカバリでは、指定するオプションによって使用されるバックアップデータが異なります。上記の場合、相対世代番号を指定した方が両データベーススペースとも2日目のバックアップデータが使用されるため、リカバリ後のデータベースの整合性を保つことができます。
世代番号の種類 |
指定 オプション |
リカバリに使用されるバックアップデータ |
|
---|---|---|---|
DB1.DBSP1 (/dev/dsk/c1t0d0s1) |
DB1.DBSP2 (/dev/dsk/c1t0d0s2) |
||
相対世代番号 |
-g 1 |
2日目のバックアップデータ (/dev/dsk/c1t0d2s2) |
2日目のバックアップデータ (/dev/dsk/c1t0d2s3) |
絶対世代番号 |
-v 1 |
1日目のバックアップデータ (/dev/dsk/c1t0d2s1) |
ロググループ単位にバックアップを実施した場合、データベーススペース単位バックアップや履歴の削除で絶対世代番号がそろっていない状態でも、ロググループ単位バックアップの絶対世代番号はそろいます。これは、以下の例のように絶対世代番号が小さい業務ボリューム(データベーススペース)の番号が、絶対世代番号が大きい業務ボリューム(データベーススペース)の番号に合わせられるからです。よって、絶対世代番号が小さい業務ボリューム(データベーススペース)では、途中の絶対世代番号が抜けた状態になります。
(例)ロググループ(LOG1/RDB1)にデータベーススペース1(DB1.DBSP1)とデータベーススペース1(DB1.DBSP2)が存在する場合
1日目:データベーススペース1(DB1.DBSP1)をバックアップ
# /opt/FJSVswsts/bin/swstbackup /dev/dsk/c1t0d0s1 /dev/dsk/c1t0d0s1 swstbackup completed |
2日目:データベーススペース1(DB1.DBSP1)とデータベーススペース2(DB1.DBSP2)をロググループ単位でバックアップ
# /opt/FJSVswsts/bin/swstbackup -n LOG1/RDB1 LOG1/RDB1 swstbackup completed |
履歴情報の表示
# /opt/FJSVswsts/bin/swsthistdisp -n LOG1/RDB1 Server=SV01 Device=/dev/dsk/c1t0d0s1 Mount-Point=DB1.DBSP1/LOG1/RDB1 (SymfoWARE) Generation Version Backup-Date Backup-Device Status Execute ArcSerial 1 2 2002/12/12 22:00 /dev/dsk/c1t0d2s2 succeeded ---- 5 2 1 2002/12/11 22:00 /dev/dsk/c1t0d2s1 succeeded ---- 5 Server=SV01 Device=/dev/dsk/c1t0d0s2 Mount-Point=DB1.DBSP2/LOG1/RDB1 (SymfoWARE) Generation Version Backup-Date Backup-Device Status Execute ArcSerial 1 2 2002/12/12 22:00 /dev/dsk/c1t0d2s3 succeeded ---- 5 |
以上のような履歴を使用したロググループ単位リカバリまたはバンドル・リカバリでは、相対世代番号に対する絶対世代番号がそろっているため、どちらの世代指定でも使用されるバックアップデータに違いはありません。
世代番号の種類 |
指定 オプション |
リカバリに使用されるバックアップデータ |
|
---|---|---|---|
DB1.DBSP1 (/dev/dsk/c1t0d0s1) |
DB1.DBSP2 (/dev/dsk/c1t0d0s2) |
||
相対世代番号 |
-g 1 |
2日目のバックアップデータ (/dev/dsk/c1t0d2s2) |
2日目のバックアップデータ (/dev/dsk/c1t0d2s3) |
絶対世代番号 |
-v 2 |
ただし、"-v 1"を指定した場合は、データベーススペース2(DB1.DBSP2)のバックアップデータが存在しないため、リストアコマンドはエラーになります。
リカバリの実行は、業務ボリューム一覧画面またはバックアップ履歴一覧画面を用いて、Web画面による指示が可能です。Web画面の詳細は、『ETERNUS SF AdvancedCopy Manager 使用手引書』を参照してください。
(バンドル・リカバリはWeb画面による指示はできません。)
バンドル・リカバリを実行するには、あらかじめ「デバイスリストファイル」という一括してリカバリしたい業務ボリュームを列挙したファイルを作成しておく必要があります。デバイスリストファイルの詳細は、本マニュアルの『デバイスリストファイルの記述方法』を参照してください。
デバイスリストファイルは、リカバリを行うStorageサーバ上の任意の場所に作成します。このファイルをリカバリ実行時に指定することで、複数の業務ボリュームを一括してリカバリすることができます。
デバイスリストファイルの記述例を以下に示します。
デバイスリストファイル作成時の規則を以下に示します。
1行に業務ボリューム名を1つ記述します。行頭から業務ボリューム名の間、および、業務ボリューム名の後ろから行末(改行記号)の間には1個以上の「半角空白またはタブ文字」が含まれていても構いません。
空白行(「半角空白またはタブ文字」)がファイルに含まれていても構いません。
記号「#」から行末まではコメントとみなされます。
リストア実行コマンドで-bundleオプションが指定された場合、デバイスリストファイルに記述された業務ボリューム全てがリストアの対象となります。以下の場合、リストア処理はエラーとなります。
業務ボリュームに関する記述が1件もなかったとき。
業務ボリュームに関する記述は存在するが、記述形式に誤りがあったとき。
業務ボリュームがSymfowareのボリュームでなかったとき。
業務ボリュームが複数のロググループにまたがっていたとき。
業務ボリュームに関する記述行以外に不正行が存在したとき。
以下の例のように、1つの業務ボリュームを複数指定したとき。
バックアップ実行コマンド(swstbackup)で行ったバックアップの履歴情報を、表示/削除することができます。
バックアップ実行コマンド(swstbackup)で行ったバックアップの履歴情報は、本マニュアルの『履歴情報表示コマンド(swsthistdisp)』を用いて確認することができます。
バックアップ履歴の表示は、バックアップ履歴一覧画面を用いて、Web画面による指示が可能です。Web画面の詳細は、『ETERNUS SF AdvancedCopy Manager 使用手引書』を参照してください。
バックアップ実行コマンド(swstbackup)で行ったバックアップの履歴情報は、本マニュアルの『履歴情報削除コマンド(swsthistdel)』を用いて削除することができます。
バックアップ履歴の削除は、業務ボリューム一覧画面またはバックアップ履歴一覧画面を用いて、Web画面による指示が可能です。Web画面の詳細は、『ETERNUS SF AdvancedCopy Manager 使用手引書』を参照してください。
(ロググループに含まれる業務ボリュームのバックアップ履歴情報を個別に指定して削除する場合は、Web画面による指示はできません。)
バックアップ運用を停止する場合、Storageサーバ上のデーモンを停止します。通常、システムの停止時に自動的に停止します。何らかの理由でデーモンを停止したい場合は、個別に停止させる事も可能です。詳細は、本マニュアルの『デーモンの起動と停止』を参照してください。
デーモンを停止すると、Storageサーバ上で動作しているAdvancedCopy Managerのすべての機能が停止します。
Storage管理サーバのデーモンを停止する場合、管理しているすべてのStorageサーバの運用が停止している事を確認後、Storage管理サーバのデーモンを停止してください。
AdvancedCopy Managerは、SDXオブジェクト上に配置されたSymfowareデータベーススペースをバックアップすることができます。
運用の詳細については、本マニュアルの『SDXオブジェクトの運用』を参照してください。
SDXオブジェクト上にSymfowareデータベーススペースを配置し、論理ボリューム単位でバックアップ運用する場合は、以下の注意点があります。
ロググループ単位の運用を行う場合は、ロググループに属するSymfowareのデータベーススペースを全てSDXオブジェクト上に作成する必要があります。そうでない場合は、データベーススペース単位の運用のみ可能となります。
―ルートクラスに配置されたSymfowareデータベーススペースは、バックアップ運用できません。ローカルクラスまたは共用クラスにデータベーススペースを配置してください。
目次
索引
![]() ![]() |