test

Solstice Backup 5.1 障害復旧ガイド

第 2 章 障害復旧

この章の説明に従って、Backup のサーバーとクライアントに対してとるべき障害復旧の手順を決めてください。それには、先に第 1 章「概要」を読んでおく必要があります。第 1 章「概要」では、障害復旧に備える方法と、このマニュアル全体で使われる基本的な用語、手順、コンセプトを説明してあります。

この章では、次に示す障害からの復旧手順を説明します。

状況はすべて同じではないので、特定の状況の障害復旧だけにあてはまるような手順を 1 つずつ説明するのは困難です。この章に示す例は、障害からの復旧についての一般的な原則であり、各手順の理解を助けるためのものです。

要件

この章で説明する障害復旧手順を進める場合は、この節に示した要件を考慮します。障害復旧手順に応じた要件を順守してください。

ハードウェア交換の要件

ハードウェアが損傷または破壊された場合は、次のことを守って新しいシステムハードウェアを正しくインストールし、構成します。

オペレーティングシステムの再インストールの要件

オペレーティングシステムが損傷または破壊された場合は、次のことを守ってインストールし直します。

Backup の再インストールの要件

Backup を確実にインストールし直すには、次のことを守ります。インストール方法の詳細は、『Solstice Backup 5.1 ご使用にあたって』を参照してください。

重要なデータの復旧

次に示す例は、オペレーティングシステムと Backup ソフトウェアを格納したディスクは動作しているが、重要なデータを格納したもう １ つのディスクが失われていると想定しています。この例は、Backup サーバーにも、Backup クライアントにもあてはまります。

ディスクが修復できないほど損傷している場合は、元のディスクより大きいサイズの新しいディスクと交換します。その場合は、復旧対象のデータをすべて収められるサイズのディスクが必要です。

重要なデータの復旧方法

重要なデータを復旧するには、次の手順に従います。

  1. 交換用ディスクをインストールします。

    オペレーティングシステムとカーネルが、必ずその新しいディスクを認識できるようにします。

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

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

    ディスク情報を保存していなくても、ディスク情報は主ディスクにあり、この例では主ディスクは動作しているので、取得することができます。元のディスクパーティション情報を探すには、Solaris システムの場合は /etc/vfstab ファイル、SunOS システムの場合は /etc/fstab ファイルを調べます。ただし、各パーティションをどれだけのサイズにするかは、ユーザーが決めなければなりません。

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

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

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

    注意 - 注意 -

    newfs コマンドまたは mkfs コマンドを使うとディスク内容は完全に破壊されるので、このディスクが必要ないことを確認します。

    SunOS システムの場合は、newfs コマンドを次の例のように実行します。


    # newfs /dev/rsd1g
...
# mount /dev/sd1g /export
# newfs /dev/rsd1h
# mount /dev/sd1h /home

    Solaris システムの場合は、newfs コマンドを次の例のように実行します。


    # newfs /dev/rdsk/c0t1d0s5
# mount /dev/dsk/c0t1d0s5
# newfs /dev/rdsk/c0t1d0s7
# mount /dev/dsk/c0t1d0s7

  5. すべてのファイルシステムを交換用ディスク上に作成してマウントしたら、nwadmin プログラムにあるセーブセット復旧機能、または nwrecover プログラムにある標準復旧手順を使って、ファイルを復旧します。

    消失したデータを復旧する最善の方法については、『Solstice Backup 5.1 管理者ガイド』を参照してください。

システムと 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 ソフトウェアをインストールし直すには、次の手順に従います。

  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 つの重要なディレクトリの内容を復旧します。

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 がわかるようにしておきます。

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

新しいサーバー上への復旧

この節では、元の Backup サーバーが破壊されて修復できないために、Backup を新しいサーバーに移す必要がある場合について説明します。この手順では、オペレーティングシステムまたは Backup ソフトウェアは更新しないものとします。

注意 - 注意 -

サーバーを変更するときには、同時に、オペレーティングシステムまたは Backup ソフトウェアには、大きな変更を加えないでください。

変更したければ、現在と同じバージョンのオペレーティングシステムと Backup ソフトウェアを使って、新しいサーバーを元のサーバーとまったく同じように構成します。新しいサーバーを構成したら、システムが動作するかどうかを確認し、失敗のないバックアップ操作をいくつか実行して、一度に 1 つずつ、オペレーティングシステムと Backup ソフトウェアを更新またはアップグレードします。

Backup を新しいサーバーに移すには、インデックスと構成ファイルも含めてオペレーティングシステムと Backup ソフトウェアを復旧する場合と同じ手順に従います。手順の詳細は、次の各節を参照してください。

ただし、ソフトウェアを構成して登録するには、次の要件に注意しなければなりません。

Backup サーバーを別のマシンに移したら、リソースデータベース (nsr.res ファイル) を復旧して、新しいサーバーに同じリソースの設定と属性の設定にする必要があります。

新しいサーバーのホスト ID が元のサーバーのホスト ID と異なる場合は、Backup ソフトウェアを Sun に登録し直すまでには、15 日間の猶予があります。『Solstice Backup 5.1 ご使用にあたって』を参照してください。

Sun から、「Sun Backup Host Transfer Affidavit」がユーザーに送られるので、それに記入して返送する必要があります。署名のあるこの証書を受領後、Sun からユーザーに新しい認証コードが送られるので、そのコードを「Registration」ウィンドウの「Auth Code」フィールドに入力してください。

サーバーを別のサーバーに移し替えたら、次のことを確認してください。