NetVault Backup Serverから、[ジョブ・ステータス]ページを使用してジョブの進行状況を監視できます。ジョブの進行状況を監視する必要はありませんが、Questでは、NetVault Bare Metal Recovery Clientのリカバリを実行する際に進行状況を監視することをお勧めしています。Linux NetVault Bare Metal Recovery Clientのリカバリが完了したら、オンラインに戻すための最後のタスクを実行する必要があります。リカバリ・ジョブを監視すると、ジョブの完了を知ることができ、この最後のタスクを実行できます。
メモ: このトピックでは、NetVault Backup WebUIの[ジョブ・ステータス]ページを使用して、Linux DRリカバリ操作の進行状況を監視し、ジョブをファイナライズする例を説明します。このダイアログで使用できるツールはPlug-in Live Client専用ではありません。使用方法の詳細については、『Quest NetVault Backupアドミニストレーターズ・ガイド』を参照してください。 |
1 |
リカバリ・ジョブが実行されているときに、[ナビゲーション]パネルの[ジョブ監視]をクリックします。 |
重要: ジョブを停止する必要がある場合は、同じ方法で[中断]コマンドにアクセスすることもできます。このコマンドを使ってリカバリ・ジョブを停止すると、NetVault Backupはデータ転送を停止します。ただし、Linux NetVault Bare Metal Recovery Client上で実行中の[System Installation for Linux]アプリケーションは機能停止状態になります。そのため、コマンドにはアクセスできますが、使用できなくなります。アプリケーションを使用できる状態へ再起動するには、ドライブへCDを挿入し、Linux NetVault Bare Metal Recovery Clientの再起動を行う必要があります。 |
3 |
リカバリ・プロセスを完了するには、Linux NetVault Bare Metal Recovery Client マシンにローカルでアクセスし、System Installation for Linuxアプリケーションの[システムの再起動]コマンドを使用して、Linux NVBMR Clientマシンを再起動します。メンテナンス・シェル・プロンプトで「exit」と入力するか、システムを手動でシャットダウンします。 |
対象となるLinux Clientでリストア・プロセスを完了すると、そのマシンには以下の事項が適用されます。
• |
ターゲットの「hosts」ファイルが修正される:リストアでは、「.../etc/hosts」ファイル内の対象となるNetVault Bare Metal Recovery Clientマシンのエントリが変更されます。たとえば、リカバリ後に、「.../etc/hosts」ファイル内にこのクライアントのIPアドレスやエイリアスは表示されますが、ホスト名は表示されなくなります。IPアドレスを使用すればマシンにアクセスできますが、ホスト名を使用してマシンにアクセスするには、このファイルを編集して適切なホスト名情報をファイルに含める必要があります。この「hosts」ファイルに関する情報、および対象となるLinuxマシンの適切なホスト名が含まれるようファイルを編集する方法については、該当するLinuxのマニュアルを参照してください。 |
• |
修正されたファイル・バックアップのリストアを実行する(該当する場合):リカバリの完了後、「Plug-in Live Client for Linuxで使用するDRイメージのリカバリ」で説明した、Plug-in for FileSystemでバックアップしたファイルをリストアできます。このプロセスにより、これらのファイルはDRリカバリ前の状態にリストアされます。 |
• |
ブート・ローダ・アプリケーションへの変更:GRUB以外のLinuxブート・ローダ・ユーティリティを実行している場合、対象となるLinuxクライアントでDRイメージをリカバリした後に、アプリケーションのGRUBバージョンでブート・ローダ・ユーティリティが置き換えられます。 |
• |
GRUBエントリ:Storixでは、同一の物理ハードウェア上に再インストールするのか、同一のストレージ設定にリストアするのかは判断されません。そのため、これまでのGRUBエントリが有効かどうかは保証されません。リストア後も有効性が保証されるGRUBエントリは、Storixが作成するエントリのみです。 |
• |
ボリューム・ラベルおよびボリュームUUID:起動やマウントにユニバーサル固有識別子(UUID)を使用するシステムの場合は、/boot/grub/grub.confおよび/etc/fstabで正しいデバイスUUIDが使用されているかどうかを確認して編集します。詳細は、「手動によるUUID情報の更新」を参照してください。 |
• |
DRリストアのStart-endセクタ・ロケーションの変更:DRイメージのリカバリ後、リストアされたパーティションのStart-endセクタは元のバックアップ・ロケーションと異なることがあります。パーティション・サイズはそのままですが、マスター・ブート・レコードの後に未使用領域が作成されません。そのため、この未使用領域を必要とする一部のブート・ローダ(GRUBなど)は使用できません。これは、リカバリ後に自動的に設定され、使用可能になるブート・ローダ・ユーティリティのLILOバージョンが、前に説明したように、この未使用領域を必要としないことが理由です。 |
• |
スワップ・パーティションの変更:リカバリ中は、NetVault Bare Metal Recovery for Linuxモジュールはスワップ・パーティション用に/etc/fstabファイル・エントリを暗黙的に変更します。 |
• |
ファイル・システム・チェックの有効化:リストアにより、[Maximum mount count]パラメータと[Check interval]パラメータが変更され、これによりファイル・システム・チェックが有効になります。マウント数または指定期間に基づいてパラメータを有効にすべきではないシステムの場合は、以下のコマンドを使用して手動でオプションを無効にします。 |
Plug-in Live Client for Linuxを使用してデータをリストアすると、各ファイル・システムのUUIDが再作成されます。/boot/grub/grub.confファイルと/etc/fstabファイル内でUUIDが使用されており、これらがPlug-in for FileSystemを使用して前回のバックアップからリストアされた場合、システムは起動に失敗します。これはUUIDが実際のファイル・システム上の値と一致しないためです。この問題を回避するには、ファイルを手動で更新します。
以下の手順では、「dev」や「sda」などのコマンドの使用例を示します。ただし、これらのコマンドを実行する際には、該当する情報をご使用の環境に適した情報で置き換える必要があります。
2 |
7 |
任意のテキスト・エディタを使用してgrub.confファイルを開きます。 |
8 |
root=UUID=x-x-x-x-xを含むエントリについて、x-x-x-x-x-xをパーティション名に一致させ、UUIDをパーティション名で置き換えます。 |
9 |
任意のテキスト・エディタを使用してfstabファイルを開きます。 |
11 |
grub.confおよびfstabファイル内のデバイス名をUUIDに変更するには、以下のコマンドを実行します。 |
12 |
13 |
/boot/grub/grub.confと/etc/fstabのバックアップ・コピーを作成します。 |
14 |
© ALL RIGHTS RESERVED. Feedback Termini di utilizzo Privacy Cookie Preference Center