| SSF/Backup Facility 運用手引書 |
|
目次
索引
|
| 第1章 バックアップ運用の設計 |
SAN環境下のETERNUS3000/6000,GR seriesにある業務データのバックアップには、ダイレクトバックアップを使用します。
ダイレクトバックアップには、以下のバックアップ運用方法が提供されています。バックアップ実施状況や運用環境に合わせて運用方法を選択してください。
アドバンスド・コピー機能のOPC(One Point Copy)を使用する場合は、バックアップ指令前に操作は不要で、バックアップ指令後に実コピー処理を行うため、バックアップ指令前に時間がとれない場合などに有効な運用方法です。
しかし、実コピー中は、テープ運用（バックアップポリシー「実コピー待ち合わせ」の設定による）やバックアップ元の業務ボリュームへのリストア操作の制限など運用に影響がある場合があります。
また、バックアップ直後から業務ボリュームに対して高負荷のかかる業務処理を実施する場合や、バックアップが完了したらETERNUS3000/6000,GR seriesの電源を落とすような運用を行う場合は、バックアップエンジンとして「EC」を選択してください。
|
|
|
|
|
アドバンスド・コピー機能のEC(Equivalent Copy)を使用する場合、バックアップ指令前に等価性維持状態にする必要がありますが、バックアップ指令直後に完全なバックアップデータが作成されるため、採取したバックアップデータをすぐに運用可能です。
しかし、業務ボリュームの容量、運用形態によっては等価性維持状態になるまでの時間が長くなり、バックアップ開始時間を調整する必要があるなど運用に影響がある場合があります。
「EC」を使用したバックアップ運用で問題となった等価性維持状態になるまでの時間を短縮することができます。
しかし、テープ運用（バックアップポリシー「バックアップ先」の“両方”や「ディスク保存世代超過処理」の“最古世代をテープに退避”が選択できない）など運用に影響がある場合があります。
また、ダイレクトバックアップを使用する場合、以下の共通項目の設計が必要です。
上記項目を設計するには、「論理ユニットの割り当て論理」と「世代管理の論理」の知識が必要です。
アドバンスド・コピー機能（EC/OPC）を使用したバックアップにおけるバックアップデータ格納領域の割り当て論理について説明します。
業務ボリュームのバックアップデータを格納する領域は、OPC利用時はバックアップ実行時に、EC利用時はバックアップ同期処理の開始時に、I/Oアクセス中でない論理ユニットから選択します。
Symfowareデータベースのバックアップでは、「バックアップ先論理ユニット固定化機能」により、“バックアップ先論理ユニット設定ファイル(lupool.conf)”にロググループに含まれるデータベーススペースのバックアップ先論理ユニットを定義します。
よって、「図 論理ユニットプールからの格納領域割り当て(OPC利用時)」および「図 論理ユニットプールからの格納領域割り当て(EC利用時)」で 論理ユニットプールから切り出される論理ユニットは、lupool.confファイルで各データベーススペース(業務ボリューム)に対応付けられた論理ユニットです。
|
|
|
|
|
バックアップデータは、業務ボリュームに設定されたバックアップポリシーに基づいて世代管理されます。バックアップ時の世代管理動作は、以下のように分類されます。
|
バックアップポリシーのパラメタ |
世代管理動作 |
|
|---|---|---|
|
バックアップ先 |
ディスク保存世代超過処理 |
|
|
ディスク |
最古世代を削除 |
パターン1を参照してください |
|
最古世代をテープに退避 |
パターン2を参照してください |
|
|
テープ |
― |
パターン3を参照してください |
|
両方 |
― |
パターン4を参照してください |
上記パラメタの組み合わせを例に、論理ユニットの割り当て論理を説明します。
|
|
|
|
|
|
|
|
|
|
バックアップポリシーの「バックアップ先」に“ディスク”が、「ディスク保存世代超過処理」に“最古世代を削除”が設定されている場合、バックアップデータは論理ユニットプールのみを使用して管理されます。
すでにバックアップデータの保存世代数がバックアップポリシーの「ディスク保存世代数」に達している状態で、バックアップを行った場合、以下の処理論理で、論理ユニットプールに保存されるバックアップデータの世代数と「ディスク保存世代数」を等しい状態に戻します。
具体例を下図で説明します。「ディスク保存世代数」が“3”に設定されており、３世代分のバックアップデータが論理ユニットプールに存在しています。この状態でバックアップを行うと、一時的に４世代分のバックアップデータが存在するため、世代超過が発生します。そこで、最古世代(絶対世代番号1のバックアップデータ)を削除し、論理ユニットプールに最近の３世代分(絶対世代番号2〜4)のバックアップデータを保持します。
|
|
|
|
|
バックアップポリシーの「バックアップ先」に“ディスク”が、「ディスク保存世代超過処理」に“最古世代をテープに退避”が設定されている場合、バックアップデータは論理ユニットプールとテープの双方を使用して管理されます。
パターン１と同じように、すでにバックアップデータの保存世代数がバックアップポリシーの「ディスク保存世代数」に達している状態で、バックアップを行った場合、以下の処理論理で、論理ユニットプールに保存されるバックアップデータの世代数と「ディスク保存世代数」を等しい状態に戻します。
具体例を下図で説明します。「ディスク保存世代数」が“3”に設定されており、３世代分のバックアップデータが論理ユニットプールに存在しています。この状態でバックアップを行うと、一時的に4世代分のバックアップデータが存在するため、世代超過が発生します。そこで、最古世代(絶対世代番号1のバックアップデータ)をテープに書き出した後に最古世代を削除し、論理ユニットプールに最近の３世代分(絶対世代番号2〜4)のバックアップデータを保持します。
テープに格納されたバックアップデータの世代については、世代超過という概念では管理されず、バックアップデータに対する有効期間という概念で管理されます。バックアップデータに対する有効期間は、バックアップポリシーの「有効期間」に設定できます。「有効期間」に設定された期間を超過すると、自動的にその世代のバックアップデータが削除されます。
|
|
|
|
|
バックアップポリシーの「バックアップ先」に“テープ”が設定されている場合、バックアップデータはテープのみを使用して管理されます。
バックアップ実行時は、業務ボリュームのデータをテープに直接書き込むのではなく、業務ボリュームに対してアドバンスト・コピーを実施するための論理ユニットを、論理ユニットプールから切り出します。そして、業務ボリュームから、切り出した論理ユニット（以降、テンポラリ論理ユニットと呼びます）にアドバンスト・コピーを行います。アドバンスト・コピー完了後、テンポラリ論理ユニットにあるデータをテープに書き込みます。テープへの書き込みが完了すると、テンポラリ論理ユニットを論理ユニットプールに返却します。
|
|
|
|
|
テープに格納されたバックアップデータの世代については、パターン2と同じように、世代超過という概念では管理されず、バックアップデータに対する有効期間という概念で管理されます。バックアップデータに対する有効期間は、バックアップポリシーの「有効期間」に設定できます。「有効期間」に設定された期間を超過すると、自動的にその世代のバックアップデータが削除されます。
|
|
|
|
|
この処理の流れを、下図に示します。
バックアップポリシーの「バックアップ先」に“両方”が設定されている場合、バックアップデータは論理ユニットプールとテープの双方を使用して管理されます。
パターン１と同じように、すでにバックアップデータの保存世代数がバックアップポリシーの「ディスク保存世代数」に達している状態でバックアップを行った場合、以下の処理論理で、論理ユニットプールに保存されるバックアップデータの世代数と「ディスク保存世代数」を等しい状態に戻します。
テープへのバックアップデータの保存は、論理ユニットプールに保存されたバックアップデータをテープに書き出し、書き出し完了時にテープのバックアップデータを世代として管理します。したがって、最近のバックアップデータは、下図のように、論理ユニットプールとテープの双方に存在します。下図では、最近の3世代が論理ユニットプールとテープで管理され、それ以前の世代がテープのみで管理されていることを示しています。
テープに格納されたバックアップデータの世代については、パターン2およびパターン3と同じように、世代超過という概念では管理されず、バックアップデータに対する有効期間という概念で管理されます。バックアップデータに対する有効期間は、バックアップポリシーの「有効期間」に設定できます。「有効期間」に設定された期間を超過すると、自動的にその世代のバックアップデータが削除されます。
|
|
|
|
|
保存しているバックアップデータが設定した世代数に達している場合に新たなバックアップを行うと、通常のバックアップ運用では、下図のように、新しいバックアップを登録した後で、最も古いバックアップデータが削除されます。
3世代の保存を設定している場合の、4世代目のバックアップの動き
最新のバックアップが失敗した場合でも、設定された保存世代数を維持するためにこの様な処理を行います。
しかし、上記の方式では、設定した保存世代数よりも１世代分多くバックアップ用の論理ユニットが必要となります。
バックアップ用の論理ユニット保存世代分しか確保できない場合は、バックアップの直前に、最も古いバックアップ履歴を削除することにより、運用することができます。ただし、バックアップが失敗すると、保存世代数が１世代分減ることになります。
バックアップ用の論理ユニットを１世代分しか持たない場合、前述の「＋１世代のバックアップ用の論理ユニットを持たないバックアップ運用」と同じ運用を行うと、バックアップが失敗した場合にバックアップデータが無くなってしまいます。また、バックアップ中に業務ボリュームが故障すると、業務データが復旧できなくなってしまいます。
バックアップ用の論理ユニットを１世代分しか持たない場合は、バックアップ時または、次のバックアップ前にバックアップデータをテープにコピーしておく必要があります。バックアップポリシーの「バックアップエンジン」で“EC”または“EC (SUSPEND)”を選択した場合は、バックアップ同期処理の開始前にバックアップデータをテープにコピーした後、最も古いバックアップ履歴を削除する必要があります。
|
|
|
|
|
下図は、Fibre ChannelとFC-SW（ファイバチャネルスイッチ）を使用して、ETERNUS3000/6000,GR seriesをSSF/Backup Facilityに接続した構成です。この構成では、ETERNUS3000/6000,GR series同士が連携した処理を行うことはありません。
それぞれのETERNUS3000/6000,GR series内にバックアップの論理ユニットを配置し、個別にバックアップ運用を行います。
|
|
|
|
|
バックアップ運用の形態に合わせ、論理ユニットプールを複数作成することができます。
例えば、以下の２つの運用を実施するとします。
バックアップポリシーを設定する時、業務ボリュームのバックアップ先として、論理ユニットプール名を指定します。そのため、ユーザが少なくとも1つの論理ユニットプールを作成しなければ、バックアップ運用は開始できません。
ただし、以下に示すような形の論理ユニットプールは作成できません。
論理ユニットプールの中に別の論理ユニットプールを含むことはできません。個々に論理ユニットプールを作成してください。
1つの論理ユニットを複数の論理ユニットプールに登録することはできません。1つの論理ユニットは、1つ論理ユニットプールにのみ登録できます。
1つの論理ユニットプールに別々のETERNUS3000/6000,GR seriesにある論理ユニットを登録することはできません。1つの論理ユニットプールには、同じETERNUS3000/6000,GR seriesにある論理ユニットのみ登録してください。
別のETERNUS3000/6000,GR seriesにある論理ユニットに対し、同じ名前の論理ユニットプールは作成できません。論理ユニット名はストレージシステム内でユニークである必要があります
ディスクへのバックアップでは、バックアップポリシー「バックアップ先ディスク」の“論理ユニットプール名”に指定した論理ユニットプールから自動的にバックアップ論理ユニットを割り当てます。論理ユニットの割り当ては、以下の規則に従っておこなわれます。
テープへのバックアップでは、バックアップポリシー「作業用論理ユニットプール」の“作業用論理ユニットプール名”に指定した論理ユニットプールから自動的にテンポラリ論理ユニットを割り当てます。論理ユニットの割り当ては、以下の規則に従っておこなわれます。
|
|
|
|
|
ETERNUS3000/6000,GR seriesを複数台導入する場合、それぞれのETERNUS3000/6000,GR seriesに必要に応じて論理ユニットプールを作成する必要があります。
|
|
|
|
|
テープへのバックアップは、通常、業務ボリュームをテンポラリ論理ユニットにコピーし、このコピーをテープにバックアップします。
通常のテープへのコピーでは、アドバンスト・コピー機能でテンポラリ論理ユニットにコピーした時点で業務ボリュームの使用が可能になるため、すぐに業務を再開できます。
“論理ユニットプールを使用しないテープへのバックアップ”では、テンポラリ論理ユニットを使用しないでバックアップを行います。
“論理ユニットプールを使用しないテープへのバックアップ”は、テンポラリ論理ユニットを使用しないため、論理ユニットを作業用に空けておく必要がありません。しかし、バックアップする間、バックアップ対象の業務ボリュームを使用する業務を停止する必要があります。
|
|
|
|
|
|
|
|
|
|
“ECのSuspend/Resumeを使用したバックアップ”は、ETERNUS3000/6000,GR series のEC拡張機能を利用して、ECの等価性維持状態までの時間を短縮し、バックアップ運用を高速に行う機能です。
従来の“EC”によるバックアップは、バックアップ同期処理の開始を指令されるたびにバックアップ論理ユニットにフルコピーを行うため、バックアップ可能な等価性維持状態になるまでに時間がかかっていました。
“ECのSuspend/Resumeを使用したバックアップ”では、バックアップ実行時にバックアップ同期処理を一時中断(suspend)し、バックアップ指令時点のバックアップ論理ユニット上にある業務ボリューム(論理ユニット)と等価なデータをバックアップデータとして管理します。
その後、このバックアップデータが不要となった時点（バックアップ履歴が削除された時点）で、バックアップ同期処理を再開(resume)し、次回のバックアップに備えます。
このとき、業務ボリューム(論理ユニット)の前回のバックアップ指令時点から更新されたデータの分のみ、バックアップ同期処理を行うため、等価性維持状態までの時間を短縮することができます。
つまり、“等価性維持状態”→“一時中断(suspend)”→“再開(resume)”を繰り返すことで、バックアップデータ作成から次回のバックアップ可能な等価性維持状態までの時間を短くし、高速なバックアップサイクルを実現します。
“ECのSuspend/Resumeを使用したバックアップ”は、同一の業務ボリューム(論理ユニット)に対して、バックアップポリシーの「ディスク保存世代数」に設定した値まで、複数の一時中断(suspend)状態のバックアップ論理ユニットを保持することができ、１つのバックアップ論理ユニットで運用するより、高速なバックアップ運用が可能となります。
|
|
|
|
|
下図（バックアップポリシー「ディスク保存世代数」に“1”が設定されている場合）で説明します。
|
|
|
|
|
|
|
|
|
|
複数の業務ボリュームに対するバックアップデータの保存先として、同一のテーププールを使用するように設定すると以下の問題が発生する可能性があります。
上記のような問題がなるべく発生しないようにするには、業務ボリュームごとにテーププールを分けるようにします。
Symfowareデータベースのバックアップの場合、バックアップポリシーの設定はロググループ単位となります。このため、ロググループに含まれるデータベーススペース(業務ボリューム)はすべて同じテーププールを使用するように設計します。
業務ボリュームと論理ユニット、どちらもバックアップ元のサイズが、そのままバックアップデータのサイズとなります。
論理デバイスバックアップの場合、あるスライスの資源をバックアップ／リストアする場合の1回のバックアップデータ量は、そのスライスのサイズと等しくなります。
|
|
|
|
|
論理ユニットバックアップの場合、バックアップ1回のバックアップデータ量は、その論理ユニットのサイズと等しくなります。
|
|
|
|
|
Symfowareデータベースのバックアップの場合、ロググループ単位でバックアップを行うため、バックアップ1回のバックアップデータ量は、ロググループに含まれる全てのデータベーススペース(業務ボリューム) のサイズの合計と等しくなります。
|
|
|
|
|
以下に業務ボリュームと論理ユニットの関係について説明します。
下図の場合、業務サーバのデバイス/dev/dsk/c1t4d1がETERNUS3000/6000,GR seriesの論理ユニット#1に配置されていて、その内のスライス1(/dev/dsk/c1t4d1s1)がバックアップ対象の業務ボリュームになっています。
バックアップに必要な論理ユニット数の見積もりは、バックアップデータ量を基準に行います。
ETERNUS3000/6000,GR series内にバックアップデータを保存する場合、以下の手順でバックアップ運用に必要な論理ユニット数を見積もります。この見積もりは、OPC利用時/EC利用時で同じです。
|
|
|
|
|
論理デバイスバックアップを利用してバックアップ運用する業務ボリュームが複数存在する場合は、すべての業務ボリュームに対して上記の見積もり方法で必要な論理ユニット数を算出してください。
1つの論理ユニットに格納できる世代数は、以下の計算式で算出できます。
|
論理ユニットのサイズ ÷ 業務ボリュームのサイズ |
計算結果が少数点の値を含む場合は、小数点以下を切り捨ててください。
例えば、論理ユニットのサイズが10GB、業務ボリュームのサイズが4GBの場合は計算結果が“2.5”となるため、1つの論理ユニットに格納できる世代数は“2”となります。これは、余り2GBをバックアップデータ格納領域として使用することができないためです。
すべての世代を格納できる論理ユニット数は、以下の計算式で算出できます。
|
「世代数+1」 ÷ 1つの論理ユニットに格納できる世代数 |
計算結果が少数点の値を含む場合は、小数点以下を切り上げてください。
例えば、「世代数+1」が“7”、1つの論理ユニットに格納できる世代数が“2”の場合は計算結果が“3.5”となるため、すべての世代を格納できる論理ユニット数は“4”となります。
Symfowareデータベースのバックアップの運用で、ETERNUS3000/6000,GR series内にバックアップデータを保存する場合、「バックアップ先論理ユニット固定化機能」によって、データベーススペースが使用している論理ユニットとバックアップ先の論理ユニットを１対１で対応付けるように設計します。
よって、バックアップ先の論理ユニットは、その論理ユニットに対応付けした論理ユニットを使用するデータベーススペースの合計サイズと同じサイズの論理ユニットを用意します。
バックアップポリシーの「バックアップ先」に“テープ”を設定してバックアップ運用する業務ボリュームの場合、バックアップ処理途中でテンポラリ論理ユニットを使用してアドバンスト・コピーを行います。この時、業務ボリュームサイズ以上の容量を持つテンポラリ論理ユニットを用意する必要があります。
したがって、バックアップポリシーの「バックアップ先」を“テープ”に設定する場合に必要となる論理ユニットは「業務ボリュームサイズ以上の容量を持つものを1つ」としてください。
Symfowareデータベースのバックアップの運用における テンポラリ論理ユニットも「バックアップ先論理ユニット固定化機能」によって対応付けられたバックアップ論理ユニットと同様に、対応付けした論理ユニットを使用するデータベーススペースの合計サイズと同じサイズの論理ユニットを用意します。
バックアップポリシーの「バックアップ先」に“両方”を設定してバックアップ運用する業務ボリュームの場合、テンポラリ論理ユニットの代わりにバックアップ論理ユニットを使用するため、“+1” 分の領域を省くことが可能です。
全世代のバックアップ履歴をテープに、最新世代のバックアップ履歴のみをETERNUS3000/6000,GR series内に保存する場合を例に説明します。
|
|
|
|
|
テープ媒体にバックアップデータを保存する場合、以下の方法でバックアップ運用に必要なテープ数を見積もります。
|
|
|
|
|
論理デバイスバックアップにおける必要なテープの必要本数は、以下の計算式で算出できます。
|
｛バックアップ対象業務ボリューム数×(有効期間÷バックアップ間隔＋1)×（複写数＋1）｝÷（テープの容量÷バックアップ対象業務ボリュームの容量）
※ 計算結果が少数点の値を含む場合は、小数点以下を切り上げてください。 |
|
|
|
|
バックアップポリシーのテープ書き込みポリシーが「新規テープの先頭から」の場合、以下の点に注意してください
|
|
|
|
|
|
|
論理ユニットバックアップにおける必要なテープの必要本数は、以下の計算式で算出できます。
|
｛バックアップ対象論理ユニット数×(有効期間÷バックアップ間隔＋1)×（複写数＋1）｝÷（テープの容量÷バックアップ対象論理ユニットの容量）
※ 計算結果が少数点の値を含む場合は、小数点以下を切り上げてください。 |
|
|
|
|
バックアップポリシーのテープ書き込みポリシーが「新規テープの先頭から」の場合、以下の点に注意してください
|
|
|
|
|
|
|
Symfowareデータベースのバックアップの運用でのテープ書き込み処理は、“データベーススペース”と“リカバリ制御ファイル”を 一対として、テープ媒体へ書き込みます。
また、Symfowareデータベースのバックアップにおける必要なテープの必要本数は、データベースの構成、テーププールの構成、磁気テープライブラリシステムの構成（テープドライブ数など）および、バックアップポリシーの設定など 環境によって違ってきます。
そのため、詳細な設計については、富士通技術員に相談してください。
バックアップ先がETERNUS3000/6000,GR series内の論理ユニットプールとなる場合は、ETERNUS3000/6000,GR seriesに装備されるアドバンスト・コピー機能により、バックアップは数秒で完了します。
|
|
|
|
|
|
|
|
|
|
テープへのバックアップにかかる時間は、磁気テープライブラリシステムの性能により異なります。以下の計算式で必要な時間を計算します。
|
(ａ×ｂ1＋(カートリッジ搬送時間×2)×ｂ2)×ｃ ａ ：（テープの容量÷テープドライブの書き込み性能）＋巻き戻し時間 |
|
|
|
|
|
|
|
|
|
|
バックアップデータをETERNUS3000/6000,GR series内の論理ユニットプールとテープに同時に保存する場合、ダイレクトバックアップは、論理ユニットプールにバックアップデータを保存してから、論理ユニットプールにあるバックアップデータをテープに保存します。このため、論理ユニットプールへのバックアップが完了した時点で業務を再開できます。ただし、テープへのバックアップにかかる時間は、磁気テープライブラリシステムの性能により異なります。バックアップにかかる時間を見積もる場合は、テープへのバックアップにかかる時間を基準に計算します。また、バックアップポリシーの「実コピー待ち合わせ」に“行う”を設定する場合は、実コピーにかかる時間も考慮してください。
|
|
|
|
|
論理デバイスバックアップの運用を設計する時は、以下の点を考慮してください。
なお、Symfowareデータベースのバックアップの運用設計については、「Symfowareデータベースのバックアップ」を参照してください。
論理デバイスバックアップに必要なシステム環境およびソフトウェア構成は以下の通りです。
SSF/Backup FacilityがStorage管理サーバの場合
|
SSF/Backup Facility |
業務サーバ |
|
|
搭載するソフトウェア |
プラットフォーム |
搭載するソフトウェア |
|
Softek AdvancedCopy Manager V10.5 for Solaris OE のマネージャ |
|
Softek AdvancedCopy Manager V10.0L60 for Windowsのエージェント |
|
Softek AdvancedCopy Manager V10.5 for Solaris OE のエージェント |
|
|
Softek AdvancedCopy Manager V10.0L60 for Linux のエージェント |
|
|
Softek AdvancedCopy Manager V10.5 for HP-UX のエージェント |
|
|
Softek AdvancedCopy Manager V10.5 for AIX のエージェント |
|
SSF/Backup Facility以外にStorage管理サーバを設置する場合
|
SSF/Backup Facility |
業務サーバ |
Storage管理サーバ |
||
|
搭載するソフトウェア |
プラットフォーム |
搭載するソフトウェア |
プラットフォーム |
搭載するソフトウェア |
|
Softek AdvancedCopy Manager V10.5 for Solaris OE のエージェント |
|
Softek AdvancedCopy Manager V10.0L60 for Windowsのエージェント |
|
Softek AdvancedCopy Manager V10.5 for Solaris OE のマネージャ |
|
Softek AdvancedCopy Manager V10.5 for Solaris OE のエージェント |
|||
|
Softek AdvancedCopy Manager V10.0L60 for Linux のエージェント |
|||
|
Softek AdvancedCopy Manager V10.5 for HP-UX のエージェント |
|||
|
Softek AdvancedCopy Manager V10.5 for AIX のエージェント |
|||
ファイルシステムの中には、メタ領域とデータ領域を別のパーティションに配置できるものがあります。論理デバイスバックアップでは、論理ボリューム同様、そのようなファイルシステムのバックアップ／リストアをサポートしていません。メタ領域とデータ領域が別のパーティションに配置されるファイルシステムをバックアップ運用の対象とする場合は、論理ユニットバックアップを利用してください。
業務サーバのプラットフォームが HP-UXの時、以下のデバイスを業務ボリュームとすることが可能です。
/dev/vg0
/dev/dsk/c1t1d1s1
HP-UXシステムでは、LVM(Logical Volume Manager)と呼ばれるディスク管理のサブシステムにより、複数の物理ボリューム(PV)をボリュームグループ(VG)と呼ばれる論理的な単位にまとめ、かつそれを論理ボリューム(LV)として複数に分割することでディスクスペースの管理を行っています。
しかし、ダイレクトバックアップでは物理ボリューム単位でコピー処理を行っているため、「１物理ボリューム(PV)が１ボリュームグループ(VG)の構成である」必要があります。
また、以下の例のように、この条件を満たさないボリューム構成の場合は、HP-UXのLVMによって、ボリューム構成を見直す必要があります。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
HP-UXのボリュームグループ(VG)をバックアップする場合、以下の点に注意する必要があります。
HP-UXのボリュームグループ(VG)をリストアする場合、以下の点に注意する必要があります。
業務サーバのプラットフォームが AIXの時、以下のデバイスを業務ボリュームとすることが可能です。
/dev/vg0
AIXシステムでは、LVM(Logical Volume Manager)と呼ばれるディスク管理のサブシステムにより、複数の物理ボリューム(PV)をボリュームグループ(VG)と呼ばれる論理的な単位にまとめ、かつそれを論理ボリューム(LV)として複数に分割することでディスクスペースの管理を行っています。
しかし、ダイレクトバックアップでは物理ボリューム単位でコピー処理を行っているため、「１物理ボリューム(PV)が１ボリュームグループ(VG)の構成である」必要があります。
また、以下の例のように、この条件を満たさないボリューム構成の場合は、AIXのLVMによって、ボリューム構成を見直す必要があります。
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
AIXのボリュームグループ(VG)をバックアップする場合、以下の点に注意する必要があります。
AIXのボリュームグループ(VG)をリストアする場合、以下の点に注意する必要があります。
論理デバイスバックアップでは、リストアもバックアップ同様、業務ボリューム単位に行われます。ボリューム破壊などを契機にバックアップデータを使って業務ボリュームの復旧を行う際は、リストア先として元の業務ボリュームを指定することで、業務ボリュームの内容をバックアップ時点まで戻すことができます。
業務ボリュームにファイルシステムを構築している場合、リストア実施後に以下の対処が必要となる場合があります。
業務ボリュームがマウントされた状態でリストアを行ったにも関わらず、リストア完了後にその業務ボリュームがアンマウント状態になっているのであれば、その業務ボリュームがファイルシステムとしてマウントできない状態になっている可能性があります。その場合、手動でマウント操作を行ってください。マウントできないのであれば、fsckコマンドを実行し、ファイルシステムとして整合性の取れた状態にしてから、再度マウント操作を行ってください。
操作ミスにより重要ファイルを削除してしまった場合など、業務ボリューム全体ではなく、ある特定のファイルだけを復旧するには sprestfileコマンドを使用します。
sprestfileコマンドは、下記の業務サーバ上で実行できます。
|
動作環境 |
|
Windows NT 4.0 Server SP5 以上/ Enterprise Edition SP5 以上 |
|
Solaris 2.6 OS |
＊１：グローバルゾーンのみサポート
|
|
|
|
|
以下に、ある特定のファイルのみを復旧する手順を示します。
|
/dev/dsk/c0t0d0s1 /dev/dsk/d0t0d1s1 /mnt1 ufs |
第1エントリ：業務ボリュームのデバイス名です。
第2エントリ：一時利用ボリュームのデバイス名です。
第3エントリ：一時利用ボリュームのマウントポイントです。
第4エントリ：ファイルシステムのタイプです。
 |
|
|
|
| # /opt/FJSVspcmd/usr/bin/sprestfile -g 2 /dev/dsk/c0t0d0s3 /tmp/restore dir/file1 dir/file2 |
リストア指定ファイル（ここでは、“/tmp/rest_file”とします）に復旧するファイル名を記述します。
|
dir/file1 |
| # /opt/FJSVspcmd/usr/bin/sprestfile -g 2 -F /tmp/rest_file /dev/dsk/c0t0d0s3 /tmp/restore |
|
|
|
|
|
|
|
|
|
以下に、ある特定のファイルのみを復旧する手順を示します。
|
g1d1p2 g1d3p2 Z: |
第1エントリ：業務ボリュームのデバイス名です。
第2エントリ：一時利用ボリュームのデバイス名です。
第3エントリ：一時利用ボリュームのドライブを割り付けるdrive letterです。
|
|
|
|
| C:\(インストールフォルダ)\DirectBackup Agent Command\bin\sprestfile -g 2 g1d1p2 D:\temp \dir\file2 |
リストア指定ファイル（ここでは、“rest_file”とします）に復旧するファイル名を記述します。
| \dir\file1 \dir\file2 \dir\file3 |
|
C:\(インストールフォルダ)\DirectBackup Agent Command\bin\sprestfile -g 2 -F D:\rest_file g1d1p2 D:\temp |
|
|
|
|
|
|
|
|
|
|
論理ユニットバックアップの運用を設計する時は、以下の点を考慮してください。
論理ユニットバックアップでは、業務サーバのプラットフォームを意識せず、指定された論理ユニットのバックアップを行います。したがって、複数の論理ユニット上に構成されているデータ(代表的なものは論理ボリューム)をバックアップするには、バックアップ実行者が“バックアップ対象が複数の論理ユニット上に構成されている”ことを意識する必要があります。
例えば、下記の図のように、コンカチネートされた論理ボリュームをバックアップするには、2つの論理ユニット(#1と#2)をバックアップしなければなりません。
ファイルシステムの中には、メタ領域とデータ領域を別のパーティションに配置できるものがあります。そのようなファイルシステムにおいて、メタ領域とデータ領域が別々の論理ユニットに配置されている場合は、論理ボリュームと同じようにそれらの論理ユニットを同期してバックアップする必要があります。
|
|
|
|
|
ufsファイルシステムに代表されるようにメタ領域とデータ領域が1つのパーティションから構成されるファイルシステムでは、上で説明した考慮は不要です。
PRIMECLUSTER GDS、PRIMECLUSTER GFSで構築された領域(論理ユニット)を論理ユニットバックアップでバックアップしないでください。リストアを行うことにより、GDS/GFS内部でもつ識別/管理情報がリストア先の論理ユニットで上書きされ、不整合な状態となります。
論理ユニットバックアップでは、リストアも論理ユニット単位に行われることに十分注意してください。ボリューム破壊などを契機にバックアップデータから業務ボリュームの復旧を行う際に、リストア先として元の論理ユニットを指定すると下記の図のように、復旧させたい業務ボリューム(上から3番目のスライス)だけでなく、同じ論理ユニットに存在する別のスライスの内容もバックアップ時点まで戻ってしまいます。
業務ボリュームの復旧は、以下の手順で行います。
この手順により、下記の図のように、同じ論理ユニットに存在する他の領域の内容を書き換えることなく、業務ボリュームのみをリストアすることができます。
UNIXのファイルシステムを例にとって説明します。一時利用ボリュームにリストアした後は、その一時利用ボリュームの復旧データがあるスライスに対してfsckを行ってファイルシステムとして整合性のある状態にします。そして、そのファイルシステム全体を業務ボリュームに対して ddコマンドなどを使用してコピーします。
|
|
|
ファイル単位の復旧は、以下の手順で行います。
この手順により、復旧させたい一部のデータだけを復旧させることができます。
UNIXのファイルシステムを例にとって説明します。一時利用ボリュームにリストアした後は、その一時利用ボリュームの復旧データがあるスライスに対してfsckを行ってファイルシステムとして整合性のある状態にします。そして、そのスライスを業務サーバからマウントし、業務サーバからファイルシステムとして参照できるようにします。その後は、一時利用ボリューム上のファイルシステムに存在するファイルを業務ボリュームのファイルシステムに対してcpコマンドなどを使用してコピーします。
|
|
|
|
|
Symfowareデータベースバックアップの運用を設計する時は、以下の点を考慮してください。
Symfowareデータベースバックアップ運用に必要な業務サーバの環境は以下です。
以下に代表的なシステム構成図を示します。（業務サーバが Solaris OSの場合）
Symfowareデータベースのバックアップは、ロググループ単位で行います。
バックアップ対象のロググループは一台のETERNUS3000/6000,GR seriesに配置するようにしてください。複数台のETERNUS3000/6000,GR seriesを跨いだロググループはバックアップ運用できません。
|
|
|
|
|
Symfowareデータベースのバックアップでは、ダイレクトバックアップの管理ファイル領域に“リカバリ制御ファイル”を以下のファイル名で作成、保管します。
/sp/dbu/primary(secondary)/recoveryfile/[バックアップ履歴毎に一意なID]
そのため、ダイレクトバックアップの管理ファイル領域の容量見積りにリカバリ制御ファイルの保管容量を追加考慮する必要があります。
|
|
|
|
|
バックアップ先論理ユニット固定化機能は、「Symfowareデータベース バックアップ」のバックアップ/リカバリの際にデータベーススペースが配置された論理ユニットとバックアップ先の論理ユニットを1対１で対応付ける機能です。
バックアップ先として指定した論理ユニットの対応付けの情報はバックアップ/リストア処理を行う前に、“バックアップ先論理ユニット設定ファイル(lupool.conf)”に記述します。
「Symfowareデータベース バックアップ」運用のデータベーススペース（業務ボリューム）は、“バックアップ先論理ユニット設定ファイル”にバックアップ先の論理ユニットを定義する必要があります。
|
|
|
|
|
|
|
|
|
|
グローバルサーバの業務データのバックアップ運用を設計する時は、以下の点を考慮してください。
グローバルサーバの業務データのバックアップ運用には、以下の環境が必要です。
以下に代表的なシステム構成図を示します。
グローバルサーバに搭載されたSystemwalker StorageMGR GR/CFとダイレクトバックアップの連携により、SSF/Backup Facility に接続されたグローバルサーバ上からETERNUS6000の論理ユニット(MLU)に対するバックアップ運用を行うことができます。
グローバルサーバの業務データのバックアップ運用では、Systemwalker StorageMGR GR/CFの制御文によってバックアップ操作を行います。ただし、ハード障害などでグローバルサーバが使用できなくなった場合に備え、グローバルサーバの業務データを復旧させるために必要な「バックアップ履歴情報の参照」と「リストアの実行」の操作は、SSF/Backup Facility 上から実行可能です。機能の種類および実行形態については、「5.1.2.5.7 グローバルサーバの業務データのバックアップ」を参照してください。
ダイレクトバックアップでバックアップを行なう場合、処理開始から終了までの間でシステム資源を消費します。消費するシステム資源の量は、同時に処理するバックアップ要求の数に依存します。
|
|
|
|
|
このため必要となるシステム資源の量を計算するためには、運用スケジュールの中で、同時に処理するバックアップ要求が最も大きくなる値を見積もる必要があります。
初期導入時や、最大バックアップ要求多重度が変化する場合はカーネルパラメタのチューニングが必要になります。
|
|
|
|
|
|
目次
索引
|
