システムと Backup ソフトウェアの復旧

次の例では、オペレーティングシステムと Backup バイナリファイルを格納したディスクが損傷または完全に破壊されているため、損傷したディスクを取り替え、オペレーティングシステムと Backup ソフトウェアの両方をインストールし直す必要があるとします。ディスクが完全には破壊されておらず、オペレーティングシステムまたは Backup がなおも動作していれば、この節の説明の中で、現在の状況にあてはまる手順だけを選んでください。これらの手順は、特に説明がなければ、Backup のサーバーにもクライアントにもあてはまります。

オペレーティングシステムを復旧する場合は、X Window システムからではなく、システムコンソールから、シングルユーザーモードで復旧します。

オペレーティングシステム復旧の準備方法

サーバーまたはクライアント用にオペレーティングシステムを復旧する場合は、次の手順で準備します。

1. 必要に応じて、損傷したディスクを取り替えます。

   交換用ディスクのサイズは、元のディスクと同じか、それより大きくします。

2. 保存されているディスクパーティション情報を使って、元のディスクと同じ構造のディスクパーティションを作成し直します。

   「ディスク情報」を参照してください。

3. 「ディスク情報」セクションに表示される出力情報を使って、復旧対象のパーティションごとにファイルシステムを作成してから、ブロックパーティションをマウントします。

   Backup ではファイルシステムの初期化や作成はしないで、データを既存のファイルシステム内に復旧します。

4. 適切なコマンドを使って交換用ディスクをフォーマットします。

   SunOS、Solaris システムの場合は、newfs コマンドまたは mkfs コマンドを使います。

5. オリジナルのソフトウェアと付属のマニュアルを使って、オペレーティングシステムを、前と同じ場所にインストールし直します。

   オペレーティングシステムの消失前に使われていたのと同じシステム名、TCP/IP ホスト名、DNS ドメイン名を使います。

   この時点でオペレーティングシステムを完全に構成にすることも、動作し得るネットワークシステムの作成に最低限必要な数だけのファイルをインストールし、最小限の構成を行うこともできます。詳細は、「オペレーティングシステムの復元」を参照してください。

6. 必要に応じて SCSI コントローラ、テープデバイスドライバをインストールし、構成します。

7. オリジナルのソフトウェアと付属のマニュアルを使って、Backup ソフトウェアをインストールし直します。

   Backup クライアント上では、Backup バイナリファイルにアクセスするだけです。/usr/sbin/nsr ディレクトリから Backup を実行するか、または Backup が稼動しているほかのシステムから、バイナリファイルを NFS マウントすることができます。インストールの詳細は、『Solstice Backup 5.1 ご使用にあたって』を参照してください。障害発生前にインストールしていた Backup パッチがあれば、それらも再インストールします。

   Backup ソフトウェアの複数のリリースを使用している場合は、障害前に稼動していたものと同じか、それよりも新しいリリースを再インストールします。バックアップに使ったリリースと同じか、それよりも新しいものが必要です。

   Backup サーバーの場合のみ - Backup サーバーソフトウェアを再インストールする場合、インデックスと構成ファイルが破壊されていなければ、Backup は、それらを自動的に探し直して見つけます。

   Backup サーバーの場合のみ - この時点で、クライアントシステムは、自分のデータを Backup サーバーから復旧できる状態になっています。

   復旧のために Backup バイナリファイルにアクセスするには、次に示す方法もあります。現在ネットワーク上で復旧されたシステムと同じような、Backup を稼動しているシステムがほかにもある場合は、Backup バイナリファイルを、損傷したシステム上で NFS マウントすることができます。

   Backup バイナリファイルにアクセスする例を次に示します。

   # mount venus:/usr/etc /mnt # /mnt/recover -s server -q recover> add / recover> force recover> recover

8. SCSI コントローラとテープデバイスドライバをインストールし、構成します。

9. システムをリブートし、スーパーユーザーとしてログインします。

オペレーティングシステムの復旧

まず、すべてのファイルシステムを交換用ディスク上に作成して、マウントします。次に、nwadmin プログラムのセーブセット復旧機能を使ってオペレーティングシステムを復旧するか、または nwrecover プログラムの通常の復旧手順によって必要なデータを復旧します。

Backup ソフトウェアの復旧

次に、Backup バイナリファイルを復旧する例を説明します。この例では、Backup ソフトウェアを持つディスクが損傷しているか、完全に破壊されているものと想定します。また、オペレーティングシステムはインストール済みであり、正常に動作しているものと想定します。

この節に示す手順のうち、どのような手順を組み合わせて使うかは、サーバー、クライアント、ストレージノードのどれが消失されたかと、それがどの程度損傷されたかによって決まります。次に示す障害復旧方法を読んだうえで、状況に合った手順の組み合わせを決めてください。

• Backup クライアントとストレージノードを復旧する場合は、次の節の手順に従います。

  • 「Backup ソフトウェア復旧の準備方法」

  • 「Backup クライアントとストレージノードの復旧方法」

• インデックスと構成ファイルを消失した Backup サーバーを復旧する場合は、次の節の手順に従います。

  • 「Backup ソフトウェア復旧の準備方法」

  • 「Backup インデックスと構成ファイルの復旧方法 」

  • 「構成ファイルディレクトリの名前の変更方法」

  • 「Backup サーバーデータ復旧の完了方法」

• Backup サーバーをクローンボリュームから復旧する場合は、次の節の手順に従います。

  • 「Backup ソフトウェア復旧の準備方法」

  • 「クローンボリュームからの復旧 」

  • 「構成ファイルディレクトリの名前の変更方法」

  • 「Backup サーバーデータ復旧の完了方法」

• Backup を新しいサーバー上に復旧する場合は、次の節の手順に従います。

  • 「新しいサーバー上への復旧」

Backup ソフトウェア復旧の準備方法

Backup 構成ファイルまたはインデックス、あるいはその両方を復旧する場合は、その前に、損傷したシステム上の元のメディアから Backup ソフトウェアをインストールし直さなければなりません。

Backup ソフトウェアをインストールし直すには、次の手順に従います。

1. 必要に応じて、損傷したディスクを取り替えます。交換用ディスクのサイズは、元のディスクと同じか、それより大きくします。

2. 保存されているディスクパーティション情報を使って、元のディスクと同じ構造のディスクパーティションを作成し直します。

   詳細は、「ディスク情報」を参照してください。

3. ディスク情報コマンドで得られた出力を使って、復旧対象のパーティションごとにファイルシステムを作成してから、プロックパーティションをマウントします。 Backup では、ファイルシステムの初期化や作成はしないで、データを既存のファイルシステム内に復旧します。

4. 適切なコマンドを使って、交換用ディスクをフォーマットします。

   SunOS の場合も Solaris システムの場合も、newfs コマンドまたは mkfs コマンドを使います。

5. オリジナルのソフトウェアと付属のマニュアルを使って、Backup ソフトウェアをインストールし直します。

   Backup クライアント上では、Backup バイナリファイルにアクセスするだけです。Backup は、/usr/sbin/nsr ディレクトリから実行することもでき、Backup を実行している別のシステムから Backup バイナリファイルを NFS マウントすることもできます。手順の詳細は、『Solstice Backup 5.1 ご使用にあたって』を参照してください。障害発生前にインストールしていた Backup パッチがあれば、それらも再インストールします。

   Backup サーバーの場合のみ - /nsr/res ディレクトリ (構成ファイル) がまだ残っていれば、ライセンスイネーブラをロードし直す必要はありません。/nsr/res ディレクトリが破壊されている場合は、構成ファイルを復旧すると、ライセンスイネーブラも復旧されます。

6. Backup インデックスと構成ファイル (/nsr) が入っている別のディスクにリンクを設定している場合、または別のディスクに格納されているほかの Backup ディレクトリにリンクを設定している場合は、この時点でリンクを設定し直します。

   Backup サーバーの場合のみ - オートチェンジャ上にバックアップして、あとの障害復旧作業でオートチェンジャを使いたい場合は、Backup をインストールしたあと、jb_config コマンドを使ってオートチェンジャを追加し、構成します。詳細は、「オートチェンジャ (ジュークボックス) による復旧」を参照してください。

   復旧のために Backup バイナリファイルにアクセスするには、次に示す例のような方法もあります。現在ネットワーク上で復旧されたシステムと同じような、Backup を稼動しているシステムがほかにもある場合は、Backup バイナリファイルを、損傷したシステム上で NFS マウントすることができます。

   バイナリファイルにアクセスする例を次に示します。

   # mount venus:/usr/etc /mnt # /mnt/recover -s server -q recover> add / recover> force recover> recover

   システムがサーバーである場合は、Backup インデックスと構成ファイルを復旧して障害復旧を続けます。手順の詳細は、「Backup インデックスと構成ファイルの復旧方法 」を参照してください。

   システムが Backup クライアントまたはストレージノードである場合は、手順の詳細は、「Backup クライアントとストレージノードの復旧方法」を参照してください。

Backup クライアントとストレージノードの復旧方法

クライアントまたはストレージノードを復旧するには、Backup クライアントとストレージノードのソフトウェアを再インストールし、次に nwrecover プログラムを使って構成ファイルを復旧するだけです。

Backup サーバーの場合と同様、どの Backup クライアントとストレージノードにも、最初のインストールで作成された特殊な構成を格納した /nsr ディレクトリがあります。障害復旧作業では、/nsr ディレクトリを復旧して、クライアントとストレージノードを障害発生前の状態に復旧する必要があります。

Backup クライアントまたはストレージノードを復旧する手順は、次のとおりです。

1. スーパーユーザーとしてログインします。

2. nwrecover プログラムを起動します。

3. 「Recover」スピードバーボタンをクリックして「Recover」ウィンドウを開きます。

   「Recover」ウィンドウに、システムのディレクトリ構造が表示されます。

4. 復旧する Backup ディレクトリを選択してマークします。

5. 「Start」スピードバーボタンをクリックして復旧を開始します。

6. nsrexecd プログラムを再起動します。

   これで、Backup クライアントまたはストレージノードは、ディスククラッシュ発生前の状態に復旧されます。

Backup インデックスと構成ファイルの復旧方法

次に説明する手順は、Backup サーバーだけにあてはまるものです。その理由は、インデックスと構成ファイルを格納し保守するのはサーバーだけであるからです。/nsr ディレクトリに格納されている Backup インデックスと構成ファイルを復旧するには、mmrecov コマンドを使います。

オペレーティングシステムも Backup ソフトウェアも破壊されている場合は、/nsr ディレクトリの内容を復旧する前に、それらをインストールし直さなければなりません。「システムと Backup ソフトウェアの復旧」を参照してください。

mmrecov コマンドを使って /nsr ディレクトリを復旧する際は、次の 3 つの重要なディレクトリの内容を復旧します。

• /nsr/mm (メディアマネージャ) ディレクトリ - すべての Backup バックアップボリュームとそのセーブセットを追跡するための Backup メディアインデックスが格納されています。

• /nsr/index/server-name ディレクトリ - サーバーインデックスが格納されており、その中に、障害発生前にバックアップされていたすべてのサーバーファイルのリストが記載されています。

  サーバーインデックスには、クライアントインデックスの場所、復旧方法などの、クライアントインデックスについての情報が記載されています。サーバーインデックスを復旧し終わったら、nwrecover プログラムを使ってクライアントインデックスを復旧することができます。

• /nsr/resディレクトリ - 特殊な Backup 構成ファイルが格納されています。

  nsr.res ファイルには、そのサーバーに属するクライアントのリスト、カスタマイズされたクライアントの構成または選択内容、デバイス情報、登録情報が記載されています。nsrjb.res ファイルには、ジュークボックス内のバックアップボリュームの位置と、ラベルテンプレートについての情報が記載されています。インデックスと違って、このディレクトリの内容は、Backup の稼動中は正確に上書きされません。したがって、mmrecov コマンドによって、/nsr/res ディレクトリは、あとで名前の変更を行う /nsr/res.R ディレクトリとして復旧されます。

mmrecov コマンドの使用

mmrecov コマンドは、/nsr ディレクトリにある Backup のサーバーインデックスと構成ファイルを復旧するのに使います。この節の説明は、Backup サーバーだけにあてはまります。

mmrecov コマンドを入力すると、ブートストラップのセーブセット識別番号 (ssid またはセーブセット ID) をユーザーに尋ねてきます。重要なデータの消失に備えて推奨された方法に従っていれば、必要なバックアップメディアの名前とブートストラップの ssid を示したブートストラップファイルのコピーが、ハードコピーまたは電子的ファイルのどちらかで保存されています。mmrecov コマンドは、ルートディレクトリ (/) ではなく、ほかのディレクトリで実行してください。

次の例では、17851237 という ssid が、前回のバックアップ処理でのブートストラップのセーブセット識別番号です。

Jun 17  22:21 1997 mars's Backup bootstrap information
date    time    level   ssid    file    record                  volume
6/14/92 23:46:13        full    17826163        48      0       mars.1
6/15/92 22:45:15        9       17836325        87      0       mars.2
6/16/92 22:50:34        9       17846505        134     0       mars.2
6/17/92 22:20:25        9       17851237        52      0       mars.3

この情報がない場合は、scanner -B コマンドを使って ssid を探し、インデックスを復旧できます。「ブートストラップのセーブセット ID」を参照してください。

オペレーティングシステムと Backup ソフトウェアを正常にインストールしたら、次の手順で、バックアップメディアからインデックスと構成ファイルを復旧します。

1. ブートストラップ情報を探します。

   この情報は、次の手順で必要です。

2. bootstrap という名前の付いた前回のバックアップが格納されたバックアップメディアを、ストレージデバイスに装着します。

3. mmrecov コマンドを使って、ブートストラップバックアップの内容を抽出します。mmrecov コマンドは、ルートディレクトリ (/) ではなく、ほかのディレクトリで実行してください。

   次に例を示します。

   # mmrecov mmrecov: Using mars.sun.com as server NOTICE: mmrecov is used to recover the Backup server's on-line file and media indexes from media (backup tapes or disks) when either of the server's on-line file or media index has been lost or damaged. Note that this command will OVERWRITE the server's existing on- line file and media indexes. mmrecov is not used to recover Backup clients' on-line indexes; normal recover procedures may be used for this purpose. See the mmrecov(8) and nsr_crash(8) man pages for more details. Enter the latest bootstrap save set id []: 17851237 Enter starting file number (if known) [0]: 52 Enter starting record number (if known) [0]: 0 Please insert the volume on which save set id 17851237 started into /disk1/file.tape. When you have done this, press <RETURN>: Scanning /disk1/file.tape for save set 17851237; this may take a while... scanner: scanning file disk file.tape on /disk1/file.tape scanner: ssid 17851237: scan complete scanner: ssid 17851237: 28 KB, 11 file(s) /nsr/res/nsr.res /nsr/res/nsr.res: file exists, overwriting /nsr/res/nsrjb.res /nsr/res/nsrjb.res: file exists, overwriting /nsr/res/nsrla.res /nsr/res/nsrla.res: file exists, overwriting /nsr/res/ /nsr/mm/ /nsr/index/mars.sun.com/ /nsr/index/ /nsr/ / # nsrmmdbasm -r /nsr/mm/mmvolume/ nsrindexasm -r /nsr/index/mars.sun.com/db/ /disk1/file.tape: mount operation in progress mars.sun.com: 7 records recovered, 0 discarded. /disk1/file.tape: mounted file disk file.tape The bootstrap entry in the on-line index for mars.sun.com has been recovered. The complete index is now being reconstructed from the various partial indexes which were saved during the normal save for this server.

   If your resource files were lost, they are now recovered in the 'res.R' directory. Copy or move them to the 'res' directory, after the index has been reconstructed and you have shut down the daemons. Then restart the daemons. Otherwise, just restart the daemons after the index has been reconstructed. nsrindexasm: Pursuing index pieces of /nsr/index/mars.sun.com/db from mars.sun.com. Recovering files into their original locations. nsrindexasm -r ./mars.sun.com/db/ merging with existing mars.sun.com index mars.sun.com: 753 records recovered, 0 discarded. Received 1 matching file(s) from NSR server `mars.sun.com' Recover completion time: Wed Jan 28 08:37:38 1998 The index for `mars.sun.com' is now fully recovered.

   インデックスと構成ファイルの復旧中に、たとえば nsrwatch または nwadmin といった Backup のコマンドを使って、サーバーでの復旧の進行状況を監視できます。mmrecov コマンドの出力が nsrwatch コマンドの出力の先頭に出力されないように、新しいウィンドウ (シェルツール) を開き、このウィンドウ上で復旧処理を監視します。次に例を示します。

   mars# nsrwatch Server: mars.sun.com Wed Jan 28 08:53:54 1998 Up since: Wed Jan 28 08:35:15 1998 Version: Backup 5.1.Build.63 Eval Saves: 0 session(s) Recovers: 1 session(s), 131 KB total Device type volume Disk1/file.tape file file.tape reading, done Sessions: Messages: Wed 08:35:11 server notice: started Wed 08:35:22 index notice: completed checking 1 client(s) Wed 08:36:44 /disk1/file.tape mount operation in progress Wed 08:36:48 /disk1/file.tape mounted file disk file.tape Wed 08:37:36 /disk1/file.tape mounted file disk file.tape Wed 08:37:36 mars.sun.com:/nsr/index/mars.sun.com (1/28/98) starting read from file.tape of 131 KB Wed 08:37:37 mars.sun.com:/nsr/index/mars.sun.com (1/28/98) done reading 1 31 KB Pending:

クローンボリュームからの復旧

クローンボリュームから復旧するには、mmrecov プログラムを使います。使用法については、「mmrecov コマンドの使用 」を参照してください。

クローンのセーブセットに関連する情報を持っているブートストラップのセーブセット ID を選択します。最新のブートストラップは、ブートストラップ出力の最後に表示されています。

次に示す例では、最新のブートストラップのセーブセットは 17851237 です。ブートストラップセーブセットのクローンは、mars_c.3 にあります。ファイル位置の値は 6、レコード位置の値は 0 です。

Jun 17  22:21 1996  mars's Backup bootstrap information Page 1
date    time       level  ssid       file  record   volume 
6/14/96 23:46:13   full   17826163    48       0   mars.1 
6/14/96 23:46:13   full   17826163    12       0   mars_c.1
6/15/96 22:45:15      9   17836325    87       0   mars.2 
6/15/96 22:45:15      9   17836325    24       0   mars_c.2
6/17/96 22:20:25      9   17851237    52       0   mars.3
6/17/96 22:20:25      9   17851237     6       0   mars_c.3

mmrecov コマンドがブートストラップのセーブセットを復旧すると、このコマンドは、さらにサーバーが持つクライアントインデックスが入っている残りの部分を復旧して、復旧を完了させます。クローンのブートストラップには、元のボリュームとクローンのボリュームについての情報が記載されています。

クローンボリュームからもっとも容易に復旧するには、mmrecov コマンドを実行する時点で、必ず、すべての必要なクローンボリュームを接続するデバイスに装着します。クローンボリュームの中にオンラインになっていないものがあれば、mmrecov コマンドは、クローンボリュームではなく元のボリュームから、サーバーが持つクライアントインデックスを復旧させようと試みます。

前述したブートストラップ出力の例では、mars_c.1 ボリュームと mars_c.3 ボリュームの両方がオンラインになっていなければなりません。mars_c.3 ボリュームしかオンラインになっていないと、mmrecov コマンドによって、mars.1 ボリュームもオンラインにするよう要求されます。

構成ファイルディレクトリの名前の変更方法

この節の説明は、Backup サーバーだけにあてはまります。

/nsr/index ディレクトリと異なり、構成ファイルが入っている /nsr/res ディレクトリは、Backup の稼働中は正確には上書きされません。したがって、 mmrecov コマンドによって、/nsr/res ディレクトリは /nsr/res.R ディレクトリとして復旧されます。構成ファイルの復旧を完了するには、Backup を停止して、復旧した /nsr/res.R ディレクトリの名前を /nsr/res に変更します。そのあと、Backup を再起動します。

mmrecov プログラムの実行が終わると、次のメッセージが表示されます。

The index for `server_name' is now fully recovered.

Backup 構成ファイルの復旧を完了するには、次の手順に従います。

1. 次に示す nsr_shutdown コマンドを使って、Backup サーバーを停止します。

   # nsr_shutdown

2. 次に示すように、元の /res ディレクトリを /res.orig として保存し、復旧されたファイル (res.R) を res という名前に変更します。

   # mv res res.orig # mv res.R res

3. Backup を再起動します。

   Backup が再起動すると、サーバーは、復旧された /res ディレクトリにある復旧された構成データを使います。次に Backup 再起動の例を示します。

   # nsrd # nsrexecd

4. Backup の構成が正しいことを検証できたら、次のようにして res.orig ディレクトリを削除します。

   # rm -r /nsr/res.orig

Backup サーバーデータ復旧の完了方法

この節の説明は、Backup サーバーだけにあてはまります。

サーバーが持っているインデックスと構成ファイルを復旧したら、nwrecover プログラムを使って、残りのサーバーデータを復旧できます。そのデータには、クライアントインデックスが入っています。

残りの Backup データを復旧するには、次の手順に従います。

1. スーパーユーザーとしてログインします。

2. nwrecover プログラムをオープンします。

3. 「Recover」スピードバーボタンをクリックして「Recover」ウィンドウを開きます。

   システムのディレクトリ構造が表示されます。

4. 復旧する Backup ディレクトリを選択してマークします。

5. 残りのサーバーデータを復旧する前に、次のディレクトリとファイルの選択を解除します。

   • /nsr/index/server-name ファイル - mmrecov コマンドの実行時に復旧される

   • /nsr/res ディレクトリと /nsr/mm ディレクトリ - mmrecov コマンドの実行時に復旧される

     障害復旧にオートチェンジャを使っていた場合に /nsr/res ディレクトリを復旧すると、復旧の目的で、オートチェンジャを追加して構成した際に作成した固有の構成は、すべて失われます。

6. 「Start」スピードボタンをクリックして復旧を開始します。

7. nsrd プログラムと nsrexecd プログラムを再起動します。

   サーバーデータを復旧したら、オートチェンジャのインベントリを作成して、どのスロットにどのボリュームがあるかを Backup がわかるようにしておきます。

   これで、システムはディスククラッシュ発生前の状態に復元されます。