SSF/Backup Facility 運用手引書
目次 索引 前ページ次ページ
第1章 バックアップ運用の設計

1.3 SAN環境でのバックアップ

SAN環境下のETERNUS ディスクアレイにある業務データのバックアップには、ダイレクトバックアップを使用します。

ダイレクトバックアップには、以下のバックアップ運用方法が提供されています。バックアップ実施状況や運用環境に合わせて運用方法を選択してください。

　

また、ダイレクトバックアップを使用する場合、以下の共通項目の設計が必要です。

  1. 論理ユニットプールの設計
  2. テーププールの設計
  3. バックアップデータ量の算出
  4. テープ量（必要本数）の算出
  5. バックアップ所要時間の見積もり
  6. 最大バックアップ要求多重度の見積もり

上記項目を設計するには、「論理ユニットの割り当て」と「世代管理」の知識が必要です。

　

1.3.1 バックアップの設計 

SAN環境でのバックアップ運用の設計を行う上で、必要となる共通項目の設計について以下に説明します。

　

1.3.1.1 論理ユニットプールの設計 

■論理ユニットプールの作成

バックアップ運用の形態に合わせ、論理ユニットプールを複数作成することができます。

例えば、以下の２つの運用を実施するとします。

  1. Project-Aという業務に関係するデータは、論理ユニットプール“Project-A”にバックアップする。
  2. システムファイルを毎週日曜日に、論理ユニットプール“EverySunday”にバックアップする。

バックアップポリシーを設定する時、業務ボリュームのバックアップ先として、論理ユニットプール名を指定します。そのため、ユーザが少なくとも1つの論理ユニットプールを作成しなければ、バックアップ運用は開始できません。

ただし、以下に示すような形の論理ユニットプールは作成できません。

　

◆論理ユニットプールの中の論理ユニットプールは作成不可

論理ユニットプールの中に別の論理ユニットプールを含むことはできません。個々に論理ユニットプールを作成してください。

　

◆複数の論理ユニットプールによる論理ユニットの共用は不可

1つの論理ユニットを複数の論理ユニットプールに登録することはできません。1つの論理ユニットは、1つの論理ユニットプールにのみ登録できます。

　

◆複数台のETERNUS ディスクアレイにまたがった論理ユニットプールは作成不可

1つの論理ユニットプールに別々のETERNUS ディスクアレイにある論理ユニットを登録することはできません。1つの論理ユニットプールには、同じETERNUS ディスクアレイにある論理ユニットのみ登録してください。

　

◆同じ名前の論理ユニットプールは作成不可

別のETERNUS ディスクアレイにある論理ユニットに対し、同じ名前の論理ユニットプールは作成できません。論理ユニット名はストレージシステム内でユニークである必要があります

　

■バックアップ論理ユニット

ディスクへのバックアップでは、バックアップポリシー「バックアップ先ディスク」の“論理ユニットプール名”に指定した論理ユニットプールから自動的にバックアップ論理ユニットを割り当てます。論理ユニットの割り当ては、以下の規則に従っておこなわれます。

  1. 論理ユニットプール内で、現在I/Oアクセスがない論理ユニットを探索します。すべての論理ユニットでI/Oアクセスが発生している場合、割り当ては失敗します。
  2. I/Oアクセスがない論理ユニットのうち、バックアップデータを格納できる容量をもつ論理ユニットを探索します

　

■テンポラリ論理ユニット

テープへのバックアップでは、バックアップポリシー「作業用論理ユニットプール」の“作業用論理ユニットプール名”に指定した論理ユニットプールから自動的にテンポラリ論理ユニットを割り当てます。論理ユニットの割り当ては、以下の規則に従っておこなわれます。

  1. 論理ユニットプール内で、現在I/Oアクセスがない論理ユニットを探索します。すべての論理ユニットでI/Oアクセスが発生している場合、割り当ては失敗します。
  2. I/Oアクセスがない論理ユニットのうち、バックアップデータを格納できる容量をもつ論理ユニットを探索します。格納できる容量の論理ユニットがみつからない場合、割り当ては失敗します。
  • 論理ユニットの不足によりテープからのリストアが失敗した場合、「論理ユニットプールを使用しないテープへのバックアップ機能」のリストアを行ってください。

　

■ETERNUS ディスクアレイを複数台導入時の論理ユニットプール

ETERNUS ディスクアレイを複数台導入する場合、それぞれのETERNUS ディスクアレイに必要に応じて論理ユニットプールを作成する必要があります。

　
  • 論理ユニットプールには、バックアップ運用したい業務ボリュームがあるETERNUS ディスクアレイと同じ筐体内にあるボリュームを指定する必要があります。他の筐体にある論理ユニットプールは使用できません。

　

1.3.1.2 テーププールの設計 

複数の業務ボリュームに対するバックアップデータの保存先として、同一のテーププールを使用するように設定すると以下の問題が発生する可能性があります。

上記のような問題がなるべく発生しないようにするには、業務ボリュームごとにテーププールを分けるようにします。

Symfowareデータベースのバックアップの場合、バックアップポリシーの設定はロググループ単位となります。このため、ロググループに含まれるデータベーススペース(業務ボリューム)はすべて同じテーププールを使用するように設計します。

　

1.3.1.3 バックアップデータ量の算出 

業務ボリュームと論理ユニット、どちらもバックアップ元のサイズが、そのままバックアップデータのサイズとなります。

論理デバイスバックアップの場合、あるスライスの資源をバックアップ／リストアする場合の1回のバックアップデータ量は、そのスライスのサイズと等しくなります。
  • 業務ボリューム内の一部の単位(ファイルやブロック)でバックアップを行うことはできません。

　

論理ユニットバックアップの場合、バックアップ1回のバックアップデータ量は、その論理ユニットのサイズと等しくなります。
  • 論理ユニット内の一部の単位（スライスや、業務ボリューム内のファイルやブロック）で、バックアップを行うことはできません。

　

Symfowareデータベースのバックアップの場合、ロググループ単位でバックアップを行うため、バックアップ1回のバックアップデータ量は、ロググループに含まれる全てのデータベーススペース(業務ボリューム) のサイズの合計と等しくなります。
  • ロググループに含まれるデータベーススペース(業務ボリューム)を個別にバックアップを行うことはできません。

　

以下に業務ボリュームと論理ユニットの関係について説明します。
下図の場合、業務サーバのデバイス/dev/dsk/c1t4d1がETERNUS ディスクアレイの論理ユニット#1に配置されていて、その内のスライス1(/dev/dsk/c1t4d1s1)がバックアップ対象の業務ボリュームになっています。

[業務ボリュームと論理ユニットの関係]

　

1.3.1.4 バックアップに必要な論理ユニット数の算出 

バックアップに必要な論理ユニット数の見積もりは、バックアップデータ量を基準に行います。

　

■バックアップデータをETERNUS ディスクアレイ内に保存する場合（Symfowareデータベース以外の場合）

ETERNUS ディスクアレイ内にバックアップデータを保存する場合、以下の手順でバックアップ運用に必要な論理ユニット数を見積もります。この見積もりは、OPC利用時/EC利用時で同じです。
  • 以下の説明は、用意できる論理ユニットのサイズがすべて等しい場合を想定して記述しています。
    用意できる論理ユニットのサイズに違いがある場合は、1つ1つの論理ユニットに格納できる世代数を求め、それらの世代数を加算した結果が「世代数+1」以上になるように、必要な論理ユニット数を算出してください。
  • サイズの異なる複数の業務ボリュームのバックアップデータを１つの論理ユニットプールに格納するように設定した場合、論理ユニットプール内のディスク割り当てが動的に行われるため、意図したディスクが割り当てられず、ディスクに無駄が発生する可能性があります。
    これを避けるため、１つのバックアップ元(業務ボリューム)につき、１つの論理ユニットプールを設定することを推奨します。

　

  1. ETERNUS ディスクアレイ内に保存するバックアップデータの世代数を決定します。
  2. ETERNUS ディスクアレイ内にバックアップデータを保存する場合は、一時的に発生する世代超過を考慮する必要があるため、手順1.で求めた値に“1”を加算します。
  3. 業務ボリュームのサイズと手順2.で求めた値(世代数＋1)を乗算します。
    この結果で得られる値が、業務ボリュームのバックアップデータをETERNUS ディスクアレイで格納するのに必要なサイズとなります。
  4. 手順3.で求めた値から、必要な論理ユニット数を算出します。
    手順3.で求めた値以上の容量を持つ論理ユニットを用意できる場合は、必要な論理ユニット数は“1”となります。
    手順3.で求めた値以上の容量を持つ論理ユニットを用意できない場合は、用意できる論理ユニットのサイズから、その論理ユニットに格納できる世代数を求めます。そして、すべての世代を格納できる論理ユニット数を求めます。

論理デバイスバックアップを利用してバックアップ運用する業務ボリュームが複数存在する場合は、すべての業務ボリュームに対して上記の見積もり方法で必要な論理ユニット数を算出してください。

　

◆1つの論理ユニットに格納できる世代数の算出式

1つの論理ユニットに格納できる世代数は、以下の計算式で算出できます。

　　　　論理ユニットのサイズ　÷　業務ボリュームのサイズ

計算結果が少数点の値を含む場合は、小数点以下を切り捨ててください。
例えば、論理ユニットのサイズが10GB、業務ボリュームのサイズが4GBの場合は計算結果が“2.5”となるため、1つの論理ユニットに格納できる世代数は“2”となります。これは、余り2GBをバックアップデータ格納領域として使用することができないためです。

　

◆必要な論理ユニット数の算出式

すべての世代を格納できる論理ユニット数は、以下の計算式で算出できます。

　　　　「世代数+1」　÷　1つの論理ユニットに格納できる世代数

計算結果が少数点の値を含む場合は、小数点以下を切り上げてください。
例えば、「世代数+1」が“7”、1つの論理ユニットに格納できる世代数が“2”の場合は計算結果が“3.5”となるため、すべての世代を格納できる論理ユニット数は“4”となります。

　

■バックアップデータをETERNUS ディスクアレイ内に保存する場合（Symfowareデータベースの場合）

Symfowareデータベースのバックアップの運用で、ETERNUS ディスクアレイ内にバックアップデータを保存する場合、「バックアップ先論理ユニット固定化機能」によって、データベーススペースが使用している論理ユニットとバックアップ先の論理ユニットを１対１で対応付けるように設計します。

よって、バックアップ先の論理ユニットは、その論理ユニットに対応付けした論理ユニットを使用するデータベーススペースの合計サイズと同じサイズの論理ユニットを用意します。

　

■バックアップデータをテープに保存する場合

バックアップポリシーの「バックアップ先」に“テープ”を設定してバックアップ運用する業務ボリュームの場合、バックアップ処理途中でテンポラリ論理ユニットを使用してアドバンスト・コピーを行います。この時、業務ボリュームサイズ以上の容量を持つテンポラリ論理ユニットを用意する必要があります。
したがって、バックアップポリシーの「バックアップ先」を“テープ”に設定する場合に必要となる論理ユニットは「業務ボリュームサイズ以上の容量を持つものを1つ」としてください。

Symfowareデータベースのバックアップの運用における テンポラリ論理ユニットも「バックアップ先論理ユニット固定化機能」によって対応付けられたバックアップ論理ユニットと同様に、対応付けした論理ユニットを使用するデータベーススペースの合計サイズと同じサイズの論理ユニットを用意します。

　

■バックアップデータをETERNUS ディスクアレイ内とテープ両方に保存する場合

バックアップポリシーの「バックアップ先」に“両方”を設定してバックアップ運用する業務ボリュームの場合、テンポラリ論理ユニットの代わりにバックアップ論理ユニットを使用するため、“+1” 分の領域を省くことが可能です。

全世代のバックアップ履歴をテープに、最新世代のバックアップ履歴のみをETERNUS ディスクアレイ内に保存する場合を例に説明します。

  1. バックアップポリシーで、「バックアップ先」に“両方”を、「ディスク保存世代」に“1”を指定します。
  2. 1世代目のバックアップを実行します。（論理ユニットとテープの両方にバックアップされます。）
  3. 2世代目のバックアップを開始する前に、前回のバックアップで残った論理ユニットのバックアップ履歴のみを削除してください。（テープへのバックアップ履歴は残してください。）
  • 3世代目以降のバックアップも、2世代目と同じ要領でおこないます。論理ユニットには最新世代、テープにはそれまでの世代のバックアップ履歴が残ることになります。

　

1.3.1.5 テープ量(必要本数)の算出 

テープ媒体にバックアップデータを保存する場合、以下の方法でバックアップ運用に必要なテープ数を見積もります。
  • 以下の説明は、用意できるテープのサイズがすべて等しい場合を想定して記述しています。

　

■論理デバイスバックアップ

論理デバイスバックアップにおける必要なテープの必要本数は、以下の計算式で算出できます。

｛バックアップ対象業務ボリューム数×(有効期間÷バックアップ間隔＋1)×（複写数＋1）｝÷（テープの容量÷バックアップ対象業務ボリュームの容量）

  • 有効期間:バックアップポリシー「有効期間」に設定した日数
  • バックアップ間隔: バックアップを行う間隔（日数）
  • 複写数: バックアップポリシー「複写数」に設定したテープ複写数

※　計算結果が少数点の値を含む場合は、小数点以下を切り上げてください。

バックアップポリシーのテープ書き込みポリシーが「新規テープの先頭から」の場合、以下の点に注意してください

  • 1巻のテープの容量が、複数の業務ボリューム(または世代)のバックアップデータを格納できるだけの容量がある場合でも、“（テープの容量÷バックアップ対象業務ボリュームの容量）”の部分は、1で計算してください。
  • 1巻のテープの容量よりも業務ボリュームの容量が大きい場合、
    “÷（テープの容量÷バックアップ対象業務ボリュームの容量）”の部分を
    “×（バックアップ対象業務ボリュームの容量÷テープの容量）”に置き換えてください。この時、小数点以下は切り上げてください。

  • バックアップポリシーの各パラメタについては、『ダイレクトバックアップ使用手引書』の「3.2 バックアップポリシーのパラメタの説明」を参照してください。

　

■論理ユニットバックアップ

論理ユニットバックアップにおける必要なテープの必要本数は、以下の計算式で算出できます。

｛バックアップ対象論理ユニット数×(有効期間÷バックアップ間隔＋1)×（複写数＋1）｝÷（テープの容量÷バックアップ対象論理ユニットの容量）

  • 有効期間:バックアップポリシー「有効期間」に設定した日数
  • バックアップ間隔: バックアップを行う間隔（日数）
  • 複写数: バックアップポリシー「複写数」に設定したテープ複写数

※　計算結果が少数点の値を含む場合は、小数点以下を切り上げてください。

バックアップポリシーのテープ書き込みポリシーが「新規テープの先頭から」の場合、以下の点に注意してください

  • 1巻のテープの容量が、複数の業務ボリューム(または世代)のバックアップデータを格納できるだけの容量がある場合でも、“（テープの容量÷バックアップ対象業務ボリュームの容量）”の部分は、1で計算してください。
  • 1巻のテープの容量よりも業務ボリュームの容量が大きい場合、
    “÷（テープの容量÷バックアップ対象業務ボリュームの容量）”の部分を
    “×（バックアップ対象業務ボリュームの容量÷テープの容量）”に置き換えてください。この時、小数点以下は切り上げてください。

  • バックアップポリシーの各パラメタについては、『ダイレクトバックアップ使用手引書』の「3.2 バックアップポリシーのパラメタの説明」を参照してください。

　

■Symfowareデータベースのバックアップ

Symfowareデータベースのバックアップの運用でのテープ書き込み処理は、“データベーススペース”と“リカバリ制御ファイル”を 一対として、テープ媒体へ書き込みます。

また、Symfowareデータベースのバックアップにおける必要なテープの必要本数は、データベースの構成、テーププールの構成、テープライブラリの構成（テープドライブ数など）および、バックアップポリシーの設定など 環境によって違ってきます。
そのため、詳細な設計については、富士通技術員に相談してください。

　

1.3.1.6 バックアップ所要時間の見積もり 

■論理ユニットプールへのバックアップ

バックアップ先がETERNUS ディスクアレイ内の論理ユニットプールとなる場合は、ETERNUS ディスクアレイに装備されるアドバンスト・コピー機能により、バックアップは数秒で完了します。
  • ECを使ったバックアップを行う場合はバックアップを実行する前に、業務ボリュームとバックアップボリュームを等価状態にする指示(バックアップ同期処理開始)を出しておく必要があります。
  • “ECのSuspend/Resumeを使用したバックアップ”では、運用途中では 通常の“EC”より等価性維持状態までの時間が短くなります。ただし、運用開始時やバックアップ同期処理をキャンセルした場合は、通常の“EC”と同じ時間が必要なため、所用時間の見積もりは通常の“EC”と同じ時間を見積もってください。

  • バックアップ同期処理開始の指示を出す方法については、『ダイレクトバックアップ使用手引書』の「9.2.1 バックアップ同期処理の開始」、「10.2.1 バックアップ同期処理の開始」または「11.3.1 バックアップ同期処理の開始」を参照してください。
  • バックアップ同期処理開始から、等価状態になるまでの時間は、ETERNUS ディスクアレイの機種によって異なるため、ETERNUS ディスクアレイのハードのマニュアルで確認してください。

　

■テープへのバックアップ

テープへのバックアップにかかる時間は、テープライブラリの性能により異なります。以下の計算式で必要な時間を計算します。

　　(ａ×ｂ1＋(カートリッジ搬送時間×2)×ｂ2)×ｃ

　　　　ａ ：（テープの容量÷テープドライブの書き込み性能）＋巻き戻し時間
　　　　ｂ1：業務ボリュームの容量÷テープの容量
　　　　ｂ2：業務ボリュームの容量÷テープの容量(小数点以下切り上げ)
　　　　ｃ ：業務ボリューム数÷テープドライブの台数(小数点以下切り上げ)

  • 上記計算式に必要な値については、テープライブラリのマニュアルなどで確認してください。必要な資料が入手できない場合は、富士通技術員に確認してください。

  • テープドライブの巻き戻し時間については、公開されていない可能性があります。不明の場合は、“テープの容量÷テープドライブの書き込み性能”で代用可能です。

　

■論理ユニットプールとテープに同時にバックアップ

バックアップデータをETERNUS ディスクアレイ内の論理ユニットプールとテープに同時に保存する場合、ダイレクトバックアップは、論理ユニットプールにバックアップデータを保存してから、論理ユニットプールにあるバックアップデータをテープに保存します。このため、論理ユニットプールへのバックアップが完了した時点で業務を再開できます。ただし、テープへのバックアップにかかる時間は、テープライブラリの性能により異なります。バックアップにかかる時間を見積もる場合は、テープへのバックアップにかかる時間を基準に計算します。また、バックアップポリシーの「実コピー待ち合わせ」に“行う”を設定する場合は、実コピーにかかる時間も考慮してください。
  • 実コピーの性能については、ETERNUS ディスクアレイのハードのマニュアルなどで確認してください。必要な資料が入手できない場合は、富士通技術員に確認してください。

　

1.3.1.7 最大バックアップ要求多重度の見積もり 

ダイレクトバックアップでバックアップを行なう場合、処理開始から終了までの間でシステム資源を消費します。消費するシステム資源の量は、同時に処理するバックアップ要求の数に依存します。
  • バックアップ要求はGUIやコマンドからバックアップ指示を出すことで生成され、バックアップが終了することで消滅します。バックアップ指示の対象となる操作は以下の通りです。
    • バックアップ
    • バックアップデータのテープへのコピー
  • バックアップ要求はテープドライブの数などに関係なく生成することが可能です。

　

このため必要となるシステム資源の量を計算するためには、運用スケジュールの中で、同時に処理するバックアップ要求が最も大きくなる値を見積もる必要があります。

初期導入時や、最大バックアップ要求多重度が変化する場合はカーネルパラメタのチューニングが必要になります。
  • 具体的な設定手順については、『SSF/Backup Facility 導入手引書』の「4.6.1 カーネルパラメタのチューニング」、「5.10.1 カーネルパラメタのチューニング」、および本書の「付録H カーネルパラメタ見積もりワークシート」を参照してください。

　

1.3.2 論理デバイスバックアップ 

論理デバイスバックアップの運用を設計する時は、以下の点を考慮してください。

なお、Symfowareデータベースのバックアップの運用設計については、「Symfowareデータベースのバックアップ」を参照してください。

　

1.3.2.1 サーバの環境 

論理デバイスバックアップに必要なシステム環境およびソフトウェア構成は以下の通りです。

　

SSF/Backup FacilityがStorage管理サーバの場合

SSF/Backup Facility
(Storage管理サーバ)

業務サーバ

搭載するソフトウェア

プラットフォーム

搭載するソフトウェア

AdvancedCopy Manager 13.0 for Solaris OS のマネージャ
  • Microsoft Windows2000 Server SP4
  • Microsoft Windows2000 Advanced Server SP4
  • Microsoft Windows Server 2003, Standard Edition SP1
  • Microsoft Windows Server 2003, Enterprise Edition SP1
  • Microsoft Windows Server 2003 R2, Standard Edition
  • Microsoft Windows Server 2003 R2, Enterprise Edition

(64ビットプロセッサバージョンは未サポート)

AdvancedCopy Manager 13.0 for Windowsのエージェント
  • Solaris 8 OS
  • Solaris 9 OS
  • Solaris 10 OS (global zoneでのみ動作可能)

AdvancedCopy Manager 13.0 for Solaris OS のエージェント
  • Red Hat Enterprise Linux AS (v.3 for x86)
  • Red Hat Enterprise Linux ES (v.3 for x86)
  • Red Hat Enterprise Linux AS (v.4 for x86)
  • Red Hat Enterprise Linux ES (v.4 for x86)
  • Red Hat Enterprise Linux AS (v.4 for EM64T)
  • Red Hat Enterprise Linux ES (v.4 for EM64T)
  • Red Hat Enterprise Linux AS (v.4 for Itanium)

AdvancedCopy Manager 13.0 for Linux のエージェント

　

SSF/Backup Facility以外にStorage管理サーバを設置する場合

SSF/Backup Facility

業務サーバ

Storage管理サーバ

搭載するソフトウェア

プラットフォーム

搭載するソフトウェア

プラットフォーム

搭載するソフトウェア

AdvancedCopy Manager 13.0 for Solaris OS のエージェント
  • Microsoft Windows2000 Server SP1以降
  • Microsoft Windows2000 Advanced Server SP1以降
  • Microsoft Windows Server 2003, Standard Edition
  • Microsoft Windows Server 2003, Enterprise Edition
  • Microsoft Windows Server 2003 for Itanium based systems

AdvancedCopy Manager 13.0 for Windowsのエージェント
  • Solaris 8 OS
  • Solaris 9 OS
  • Solaris 10 OS (non-global zoneでのみ動作可能)

AdvancedCopy Manager 13.0 for Solaris OS のマネージャ
  • Solaris 8 OS
  • Solaris 9 OS
  • Solaris 10 OS (non-global zoneで動作可能です)

AdvancedCopy Manager 13.0 for Solaris OS のエージェント
  • Red Hat Enterprise Linux AS (v.3 for x86)
  • Red Hat Enterprise Linux ES (v.3 for x86)
  • Red Hat Enterprise Linux AS (v.4 for x86)
  • Red Hat Enterprise Linux ES (v.4 for x86)
  • Red Hat Enterprise Linux AS (v.4 for EM64T)
  • Red Hat Enterprise Linux ES (v.4 for EM64T)
  • Red Hat Enterprise Linux AS (v.4 for Itanium)

AdvancedCopy Manager 13.0 for Linux のエージェント
  • HP-UX 11.0, 11i v1, 11i v2(PA-RISC)
  • HP-UX 11i v2 (Itanium)

AdvancedCopy Manager 13.0 for HP-UX のエージェント
  • AIX 5L 5.1, 5.2, 5.3

AdvancedCopy Manager 13.0 for AIX のエージェント

　

1.3.2.2 メタ領域とデータ領域を持つファイルシステム 

ファイルシステムの中には、メタ領域とデータ領域を別のパーティションに配置できるものがあります。論理デバイスバックアップでは、論理ボリューム同様、そのようなファイルシステムのバックアップ／リストアをサポートしていません。メタ領域とデータ領域が別のパーティションに配置されるファイルシステムをバックアップ運用の対象とする場合は、論理ユニットバックアップを利用してください。

　

1.3.2.3 業務サーバのプラットフォームがHP-UX の時の注意事項

■HP-UX の業務ボリューム

業務サーバのプラットフォームが HP-UXの時、以下のデバイスを業務ボリュームとすることが可能です。

　

HP-UXシステムでは、LVM(Logical Volume Manager)と呼ばれるディスク管理のサブシステムにより、複数の物理ボリューム(PV)をボリュームグループ(VG)と呼ばれる論理的な単位にまとめ、かつそれを論理ボリューム(LV)として複数に分割することでディスクスペースの管理を行っています。

しかし、ダイレクトバックアップでは物理ボリューム単位でコピー処理を行っているため、「１物理ボリューム(PV)が１ボリュームグループ(VG)の構成である」必要があります。

　

また、以下の例のように、この条件を満たさないボリューム構成の場合は、HP-UXのLVMによって、ボリューム構成を見直す必要があります。
  • LVM(Logical Volume Manager)については、HP-UX のマニュアルを参照してください。

  • HP-UX のLVM(Logical Volume Manager)の論理ボリュームをそのまま業務ボリュームとして登録できません。ボリュームグループ(VG)または、物理ボリューム(PV)を業務ボリュームとして登録してください。
  • 業務ボリューム一覧画面では、ボリュームグループ(VG)の情報のみ表示されます。
    しかし、実際のバックアップ運用は論理ボリューム(LV)単位で行われているため、バックアップ実行時には、バックアップ対象のボリュームグループにどの論理ボリュームが属するのか確認するようにしてください。
    確認は、業務ボリューム一覧画面でボリュームグループを選択した状態で、右クリックして表示されるメニューから“マウントポイント一覧”を選択することにより可能です。

  • ボリュームグループ(VG)情報の参照方法については、『ダイレクトバックアップ使用手引書』の「9.4 ボリュームグループ構成情報の参照」を参照してください。

　

■HP-UX 業務ボリュームのバックアップ

HP-UXのボリュームグループ(VG)をバックアップする場合、以下の点に注意する必要があります。

　

■HP-UX 業務ボリュームのリストア

HP-UXのボリュームグループ(VG)をリストアする場合、以下の点に注意する必要があります。

　

1.3.2.4 業務サーバのプラットフォームがAIX の時の注意事項

■AIX の業務ボリューム

業務サーバのプラットフォームが AIXの時、以下のデバイスを業務ボリュームとすることが可能です。

　

AIXシステムでは、LVM(Logical Volume Manager)と呼ばれるディスク管理のサブシステムにより、複数の物理ボリューム(PV)をボリュームグループ(VG)と呼ばれる論理的な単位にまとめ、かつそれを論理ボリューム(LV)として複数に分割することでディスクスペースの管理を行っています。

しかし、ダイレクトバックアップでは物理ボリューム単位でコピー処理を行っているため、「１物理ボリューム(PV)が１ボリュームグループ(VG)の構成である」必要があります。

　

また、以下の例のように、この条件を満たさないボリューム構成の場合は、AIXのLVMによって、ボリューム構成を見直す必要があります。

　
  • LVM(Logical Volume Manager)については、AIX のマニュアルを参照してください。

  • AIX のLVM(Logical Volume Manager)の論理ボリュームをそのまま業務ボリュームとして登録できません。ボリュームグループ(VG)を業務ボリュームとして登録してください。
  • 業務ボリューム一覧画面では、ボリュームグループ(VG)の情報のみ表示されます。
    しかし、実際のバックアップ運用は論理ボリューム(LV)単位で行われているため、バックアップ実行時には、バックアップ対象のボリュームグループにどの論理ボリュームが属するのか確認するようにしてください。
    確認には、AIXの提供する lsvgコマンド等を使用してください。

  • lsvgコマンドの詳細については、AIXのマニュアルを参照してください。

　

■AIX 業務ボリュームのバックアップ

AIXのボリュームグループ(VG)をバックアップする場合、以下の点に注意する必要があります。

　

■AIX 業務ボリュームのリストア

AIXのボリュームグループ(VG)をリストアする場合、以下の点に注意する必要があります。

　

1.3.2.5 リストアにおける考慮点 

■業務ボリューム単位の復旧手順

論理デバイスバックアップでは、リストアもバックアップ同様、業務ボリューム単位に行われます。ボリューム破壊などを契機にバックアップデータを使って業務ボリュームの復旧を行う際は、リストア先として元の業務ボリュームを指定することで、業務ボリュームの内容をバックアップ時点まで戻すことができます。

業務ボリュームにファイルシステムを構築している場合、リストア実施後に以下の対処が必要となる場合があります。
業務ボリュームがマウントされた状態でリストアを行ったにも関わらず、リストア完了後にその業務ボリュームがアンマウント状態になっているのであれば、その業務ボリュームがファイルシステムとしてマウントできない状態になっている可能性があります。その場合、手動でマウント操作を行ってください。マウントできないのであれば、fsckコマンドを実行し、ファイルシステムとして整合性の取れた状態にしてから、再度マウント操作を行ってください。

　

■ファイル単位の復旧手順

操作ミスにより重要ファイルを削除してしまった場合など、業務ボリューム全体ではなく、ある特定のファイルだけを復旧するには sprestfileコマンドを使用します。

sprestfileコマンドは、下記の業務サーバ上で実行できます。

動作環境

Windows 2000 Advanced Server SP4 以上

Solaris 8 OS
Solaris 9 OS
Solaris 10 OS(*1)

＊１：グローバルゾーンのみサポート
  • sprestfileコマンドは、一時利用ボリュームを使用します。
    一時利用ボリュームは、業務サーバから認識できる、元の業務ボリュームと同容量以上のものをリストアを行う各業務サーバにあらかじめ用意しておく必要があります。
  • 業務サーバが Windows の時、使用されていない drive letter を用意してください。

　

◆業務サーバが Solaris OSの場合

以下に、ある特定のファイルのみを復旧する手順を示します。

  1. 復旧するファイルが含まれる業務ボリュームを特定します。
    また、復旧に使用する一時利用ボリュームを特定します。

    　

  2. /opt/FJSVspcmd/usr/etc/sprestfilercファイルにデバイス名情報を記述します。

    　

    /dev/dsk/c0t0d0s1　 /dev/dsk/d0t0d1s1　/mnt1　ufs
    /dev/dsk/c0t0d0s3　 /dev/dsk/d0t0d1s1　/mnt2　ufs
    /dev/dsk/c0t0d0s5　 /dev/dsk/d0t0d1s5　/mnt3　ufs

    　　　第1エントリ：業務ボリュームのデバイス名です。
    　　　第2エントリ：一時利用ボリュームのデバイス名です。
    　　　第3エントリ：一時利用ボリュームのマウントポイントです。
    　　　第4エントリ：ファイルシステムのタイプです。

    • 業務サーバがSolaris OS の場合、指定できるファイルシステムのタイプ（第4エントリ）は、“ufs”のみです。
    • SSF/Backup Facilityがクラスタ構成の場合、両ノードで sprestfilercファイルの設定を行ってください。
    • 先頭文字が“#”で始まる行は、コメント行として扱われます。
    • sprestfilercファイルに記述する「一時利用ボリュームのデバイス名」は、複数の業務ボリュームで、同じボリュームを指定できます。ただし、同時には利用（リストア）しないでください。

    　

  3. sprestfileコマンドを実行し、ファイルを復旧します。

◆業務サーバが Windows の場合

以下に、ある特定のファイルのみを復旧する手順を示します。

  1. 復旧するファイルが含まれる業務ボリュームを特定します。
    また、復旧に使用する一時利用ボリュームを特定します。

    　

  2. (インストールフォルダ)\DirectBackup Agent Command\etc\sprestfilerc ファイルにデバイス名情報を記述します。

    　

    g1d1p2　 g1d3p2　Z:
    g2d1p2　 g2d3p2　P:
    g3d1p2　 g3d3p2　Q:

    　　　第1エントリ：業務ボリュームのデバイス名です。
    　　　第2エントリ：一時利用ボリュームのデバイス名です。
    　　　第3エントリ：一時利用ボリュームのドライブを割り付けるdrive letterです。

    • SSF/Backup Facilityがクラスタ構成の場合、両ノードで sprestfilercファイルの設定を行ってください。
    • 先頭文字が“#”で始まる行は、コメント行として扱われます。
    • sprestfilercファイルに記述する「一時利用ボリュームのデバイス名」は、複数の業務ボリュームで、同じボリュームを指定できます。ただし、同時には利用（リストア）しないでください。

    　

  3. sprestfileコマンドを実行し、ファイルを復旧します。
  • sprestfileコマンドや「リストア指定ファイル」で指定する“復旧するファイル名”は、バックアップ元業務ボリューム(ドライブ)の割り付け配下を指定してください。
    この時、先頭に “\” を付加し “\dir\file1”の形式で記述してください。
    フォルダの指定も可能です。
  • 全角(日本語)のファイル名を使用する時は、コード体系「SJIS」を使用してください。
  • クラスタ環境でsprestfileコマンドを実行する場合、当該コマンドを実行する業務サーバにログインしたときに環境変数SWSTGNODEの設定を行ってから実行してください。
    環境変数の設定方法は以下のとおりです。
    　set SWSTGNODE=当該業務サーバの論理ノード名
  • 復旧するフォルダに指定するドライブのファイルシステムはリストアする業務ボリュームと同じファイルシステムであることを確認ください。
    これらファイルシステムが違う場合はリストアが正常終了しない場合があります。

  • 各ファイルの書式や操作については、『ダイレクトバックアップ使用手引書』の「第9章 論理デバイスバックアップの運用操作」を参照してください。
  • コマンドについては、『ダイレクトバックアップ使用手引書』の「第14章 論理デバイスバックアップおよびSymfowareデータベースのバックアップのためのコマンド」を参照してください。

　

1.3.3 論理ユニットバックアップ 

論理ユニットバックアップの運用を設計する時は、以下の点を考慮してください。

　

1.3.3.1 論理ボリューム 

論理ユニットバックアップでは、業務サーバのプラットフォームを意識せず、指定された論理ユニットのバックアップを行います。したがって、複数の論理ユニット上に構成されているデータ(代表的なものは論理ボリューム)をバックアップするには、バックアップ実行者が“バックアップ対象が複数の論理ユニット上に構成されている”ことを意識する必要があります。

例えば、下記の図のように、コンカチネートされた論理ボリュームをバックアップするには、2つの論理ユニット(#1と#2)をバックアップしなければなりません。

[論理ボリューム構成された業務ボリュームのイメージ]

　

■メタ領域とデータ領域を持つファイルシステム

ファイルシステムの中には、メタ領域とデータ領域を別のパーティションに配置できるものがあります。そのようなファイルシステムにおいて、メタ領域とデータ領域が別々の論理ユニットに配置されている場合は、論理ボリュームと同じようにそれらの論理ユニットを同期してバックアップする必要があります。
  • どちらか片方の論理ユニットのみをバックアップした場合、リストアを行うとファイルシステムとしての整合性が取れなくなります。

ufsファイルシステムに代表されるようにメタ領域とデータ領域が1つのパーティションから構成されるファイルシステムでは、上で説明した考慮は不要です。

　

■PRIMECLUSTER GDS/PRIMECLUSTER GFSで構築された領域

PRIMECLUSTER GDS、PRIMECLUSTER GFSで構築された領域(論理ユニット)を論理ユニットバックアップでバックアップしないでください。リストアを行うことにより、GDS/GFS内部でもつ識別/管理情報がリストア先の論理ユニットで上書きされ、不整合な状態となります。

　

1.3.3.2 リストアにおける考慮点 

論理ユニットバックアップでは、リストアも論理ユニット単位に行われることに十分注意してください。ボリューム破壊などを契機にバックアップデータから業務ボリュームの復旧を行う際に、リストア先として元の論理ユニットを指定すると下記の図のように、復旧させたい業務ボリューム(上から3番目のスライス)だけでなく、同じ論理ユニットに存在する別のスライスの内容もバックアップ時点まで戻ってしまいます。

[元の論理ユニットへ直接リストアした際のイメージ]

　

■業務ボリュームの復旧手順

業務ボリュームの復旧は、以下の手順で行います。

  1. バックアップデータを、一時利用ボリュームにリストアします。
  2. 業務サーバから一時利用ボリュームの資源を参照可能にします。
  3. 業務サーバ上で、一時利用ボリュームにリストアしたバックアップデータを業務ボリュームに手作業でコピーします。

この手順により、下記の図のように、同じ論理ユニットに存在する他の領域の内容を書き換えることなく、業務ボリュームのみをリストアすることができます。

UNIXのファイルシステムを例にとって説明します。一時利用ボリュームにリストアした後は、その一時利用ボリュームの復旧データがあるスライスに対してfsckを行ってファイルシステムとして整合性のある状態にします。そして、そのファイルシステム全体を業務ボリュームに対して ddコマンドなどを使用してコピーします。

　

[一時利用ボリュームを利用したリストアのイメージ]

　

■ファイル単位の復旧手順

ファイル単位の復旧は、以下の手順で行います。

  1. バックアップデータを、一時利用ボリュームにリストアします。
  2. 業務サーバから一時利用ボリュームの資源を参照可能にします。
  3. 業務サーバ上で、一時利用ボリュームにリストアしたバックアップデータの内、復旧したいファイルのみを業務ボリュームに手作業でコピーします。

この手順により、復旧させたい一部のデータだけを復旧させることができます。

UNIXのファイルシステムを例にとって説明します。一時利用ボリュームにリストアした後は、その一時利用ボリュームの復旧データがあるスライスに対してfsckを行ってファイルシステムとして整合性のある状態にします。そして、そのスライスを業務サーバからマウントし、業務サーバからファイルシステムとして参照できるようにします。その後は、一時利用ボリューム上のファイルシステムに存在するファイルを業務ボリュームのファイルシステムに対してcpコマンドなどを使用してコピーします。
  • 一時利用ボリュームは、業務サーバから認識できる、元の論理ユニットと同容量以上の論理ユニットをあらかじめ用意しておく必要があります。

　

1.3.4 Symfowareデータベースのバックアップ

Symfowareデータベースバックアップの運用を設計する時は、以下の点を考慮してください。

　

1.3.4.1 業務サーバの環境

Symfowareデータベースバックアップ運用に必要な業務サーバの環境は以下です。

◆業務サーバが Solaris OSの場合

◆業務サーバが Linux の場合
  • AdvancedCopy Managerによってバックアップ運用を行うSymfowareのデータベーススペースは、rawデバイス上に配置されたもののみです。

　

以下に代表的なシステム構成図を示します。（業務サーバが Solaris OSの場合）

　

1.3.4.2 ロググループの配置 

Symfowareデータベースのバックアップは、ロググループ単位で行います。
バックアップ対象のロググループは一台のETERNUS ディスクアレイに配置するようにしてください。複数台のETERNUS ディスクアレイを跨いだロググループはバックアップ運用できません。
  • 日本語ロググループ名のバックアップ運用は、サポートされていません。

　

1.3.4.3 リカバリ制御ファイル 

Symfowareデータベースのバックアップでは、ダイレクトバックアップの管理ファイル領域に“リカバリ制御ファイル”を以下のファイル名で作成、保管します。

/sp/dbu/primary(secondary)/recoveryfile/[バックアップ履歴毎に一意なID]

そのため、ダイレクトバックアップの管理ファイル領域の容量見積りにリカバリ制御ファイルの保管容量を追加考慮する必要があります。

　

1.3.4.4 バックアップ先論理ユニット固定化機能

バックアップ先論理ユニット固定化機能は、「Symfowareデータベース バックアップ」のバックアップ/リカバリの際にデータベーススペースが配置された論理ユニットとバックアップ先の論理ユニットを1対１で対応付ける機能です。

バックアップ先として指定した論理ユニットの対応付けの情報はバックアップ/リストア処理を行う前に、“バックアップ先論理ユニット設定ファイル(lupool.conf)”に記述します。

「Symfowareデータベース バックアップ」運用のデータベーススペース（業務ボリューム）は、“バックアップ先論理ユニット設定ファイル”にバックアップ先の論理ユニットを定義する必要があります。
  • 本機能は、論理デバイスバックアップおよび論理ユニットバックアップの業務ボリュームに対しては無効です。
  • “バックアップ先論理ユニット設定ファイル”に記述したバックアップ先の論理ユニットは、Symfowareデータベースのバックアップの運用前にバックアップポリシー「バックアップ先ディスク」に指定した論理ユニットプールに登録されている必要があります。

  • 「バックアップ先論理ユニット固定化機能」の設定方法については、『ダイレクトバックアップ使用手引書』の「11.2.5 バックアップ先論理ユニットの定義」を参照してください。

　

1.3.4.5 バックアップにおける考慮点 

　

1.3.4.6 リカバリにおける考慮点 

　

1.3.5 SQL Serverデータベースのバックアップ 

SQL Severデータベースバックアップの運用を設計する時は、以下の点を考慮してください。

　

1.3.5.1 業務サーバの環境 

SQL Serverデータベースのバックアップ運用に必要な業務サーバの環境は以下のとおりです。

　

以下に代表的なシステム構成図を示します。

　

SQL Server 2000/2005データベースバックアップとリストアを高速に実施するためには、AdvancedCopy Managerの以下のコマンドを使用します。
  • SQL Serverバックアップ実行コマンドおよびSQL Serverリストア実行コマンドについては、バックアップ管理機能用とレプリケーション管理機能用の2種類が提供されています。バックアップ管理機能による運用を行う場合は、swstbackup_sqlsvr、swstrestore_sqlsvr、レプリケーション管理機能による運用を行う場合は swsrpbackup_sql、swsrprestore_sqlを使用します。

　

　

バックアップ管理機能用

レプリケーション管理機能用

SQL Serverバックアップ実行コマンド

swstbackup_sqlsvr

swsrpbackup_sql

SQL Serverリストア実行コマンド

swstrestore_sqlsvr

swsrprestore_sql

　
  • SQL Serverデータベースのバックアップ以外の、トランザクションログのバックアップ・リストア（リカバリ）については、SQL Server 2000/2005のEnterprise Manager、Transact-SQL等を用いて実施する必要があります。

　

AdvancedCopy Managerでバックアップ可能なデータベースはユーザーデータベースのみです。したがって、システムデータベース（master、msdb、model、distribution）をAdvancedCopy Managerでバックアップすることはできません。システムデータベースのバックアップ運用については、SQL Server 2000/2005で実施する必要があります。

　

SQL Server 2000/2005

AdvancedCopy Manager

システムデータベース
(master,msdb,model,distribution)

○

−

ユーザーデータベース

データベースバックアップ

○

○

ログバックアップ

○

−

　

SQL Server 2000/2005のVDI(Virtual Device Interface)機構と連携することによって、オンラインバックアップを実現します。

なお、SQL Server 2000/2005のバックアップ運用では、「データベースバックアップ」と「ログバックアップ」を併用することが一般的です。

　

1.3.5.2 バックアップ運用設計 

SQL Server 2000/2005のバックアップ運用を行う前に、以下のバックアップ運用設計を行ってください。

■SQL Serverデータベースのバックアップ運用設計

データベースのバックアップ運用設計を行います。「SQL Server Books Online」の「バックアップと復元の計画の立案」を参考にして設計を行ってください。

さらに、以下のデータベースファイルの配置に関する制限事項を守って設計を行ってください。

◆ロウパーティション上のデータベース

AdvancedCopy Managerはロウパーティション上に構築されたデータベースはサポートしません。データベースはファイルシステム上に構築してください。

◆ファイル配置

AdvancedCopy Managerは、ボリューム単位(パーティション単位)でコピー処理を実施します。そのため、データベースファイルの配置ボリュームには、対象となるデータベースファイル以外のファイルは置かないでください。
  • バックアップ対象のデータベースファイルとは無関係なファイルを置いた場合、そのファイルのデータだけでなく、ファイルシステム全体を破壊する恐れがあります。
  • 特に、データベースファイルをシステムドライブに配置することや、SQL Server 2000/2005とAdvancedCopy Managerの実行ファイル・管理ファイルが存在するボリュームにデータベースを配置しないでください。

  • 1個のボリューム上にN(>2)個のデータベースのファイルを配置すること、および、M(>2)個のボリューム上にN (>2)個のデータベースのファイルを混在配置することは可能ですが、これらN個のデータベースは同一インスタンス配下のデータベースであることが必要です。

  • SQL Server データベースのバックアップ運用については、『ETERNUS SF AdvancedCopy Manager 運用手引書（Windows版）』の「第10章 SQL Server データベースのバックアップ運用」を参照してください。

　

1.3.6 VxVM（VERITAS Volume Manager）配下のボリュームのバックアップ 

VxVM配下のボリュームのバックアップ運用を設計する時は、以下の点を考慮してください。

　

1.3.6.1 業務サーバの環境 

VxVM配下のボリュームのバックアップ運用に必要な業務サーバの環境は以下のとおりです。

◆業務サーバが Solaris OSの場合

　

1.3.6.2 バックアップ運用の単位 

以下の単位でVxVM(VERITAS Volume Manager)配下のボリュームをバックアップ/レプリケーションすることができます。

　

1.3.6.3 論理ボリュームが存在する物理スライス 

論理ボリュームのコピーをサブディスク単位ではなく、sliced属性(専有領域と共有領域が分離)をもつVMディスク(物理ディスク)の共有領域全体をコピーすることによって行います。

指定するデバイス名は、VxVMの論理ボリューム名です。

[sliced属性(専有領域と共有領域が分離)をもつVMディスク(物理ディスク)]

　

VxVM論理ボリュームのコピーを論理ボリュームの単位ではなく、物理スライス(/dev/dsk/cXtXdXsX、/dev/FJSVmplb/dsk/mplbXsX等)の単位で行います。

論理ボリューム単位で運用可能なVxVMボリュームは、以下の条件を満足する必要があります。

　

また、下図に示すような、1つのVMディスク上に複数の論理ボリュームがある場合(すなわち、論理ボリュームとVMディスクがN:1(N>1)の関係にある場合)もサポートされますが、運用の際は以下の点に留意してください。

　

以下のボリューム構成をもつ論理ボリュームは、サポートを行いません。
  • ディスクグループを作成する際、デフォルトではCDSディスクグループになります。論理ボリュームが存在する物理スライス単位でのコピー運用を行う場合は、非CDSディスクグループを作成し、ディスクタイプもslicedタイプにしてください。
  • VxVMボリューム上に作成されたSymfowareデータベーススペースに対して、Symfowareと連携したバックアップ・リカバリを行うことはできません。

　

1.3.6.4 ディスクグループを構成する物理ディスク 

論理ボリュームが使用しているサブディスクが存在するVMディスク（物理ディスク）を管理単位とします。
  • noprivタイプのVMディスクのみ、物理スライスが管理単位となります。

　

[VxVMの構成例]

　

VMディスク全体をコピーするため、サブディスクとなる共有領域だけでなく、VxVMの内部構成情報が格納されている専有領域もコピーされます。

したがって、バックアップやレプリケーションを行う際には、VxVMの構成情報の整合性を保ってコピーを行う必要があります。

AdvancedCopy Managerに指定するデバイス名は、以下の形式です。

/dev/vx/dmp/c#t#d#s#
  • VxVMにおけるエンクロージャーに基づく命名規則の運用下での動作はサポートしていません。

　
  • VxVM配下のボリュームのバックアップ運用については、『ETERNUS SF AdvancedCopy Manager 運用手引書』の「4.9 VxVMボリュームの運用」を、VxVM配下のボリュームのレプリケーション運用については、『ETERNUS SF AdvancedCopy Manager 運用手引書』の「8.9 VxVMボリュームの運用」を参照してください。

　

1.3.7 グローバルサーバのデータのバックアップ

グローバルサーバの業務データのバックアップ運用を設計する時は、以下の点を考慮してください。

　

1.3.7.1 グローバルサーバの環境 

グローバルサーバの業務データのバックアップ運用には、以下の環境が必要です。

以下に代表的なシステム構成図を示します。

　

1.3.7.2 Systemwalker StorageMGR GR/CFとの連携 

グローバルサーバに搭載されたSystemwalker StorageMGR GR/CFとダイレクトバックアップの連携により、SSF/Backup Facility に接続されたグローバルサーバ上からETERNUS6000/ETERNUS8000の論理ユニット(MLU)に対するバックアップ運用を行うことができます。

グローバルサーバの業務データのバックアップ運用では、Systemwalker StorageMGR GR/CFの制御文によってバックアップ操作を行います。ただし、ハード障害などでグローバルサーバが使用できなくなった場合に備え、グローバルサーバの業務データを復旧させるために必要な「バックアップ履歴情報の参照」と「リストアの実行」の操作は、SSF/Backup Facility 上から実行可能です。機能の種類および実行形態については、「5.1.2.3.8 グローバルサーバの業務データのバックアップ」を参照してください。

　

目次 索引 前ページ次ページ
All Rights Reserved, Copyright(C) 富士通株式会社 2006