NetVault Bare Metal Recovery 12.0 - Plug-ins ユーザー・ガイド

Plug-in Live Client for Linux でのジョブ進行状況の監視とリカバリのファイナライズ

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アドミニストレーターズ・ガイド』を参照してください。

リカバリ・ジョブが実行されているときに、［ナビゲーション］パネルの［ジョブ監視］をクリックします。

表示されたジョブのリストで、進行中のLinux DRリカバリ・ジョブを見つけます。


	重要：ジョブを停止する必要がある場合は、同じ方法で［中断］コマンドにアクセスすることもできます。このコマンドを使ってリカバリ・ジョブを停止すると、NetVault Backupはデータ転送を停止します。ただし、Linux NetVault Bare Metal Recovery Client上で実行中の［System Installation for Linux］アプリケーションは機能停止状態になります。そのため、コマンドにはアクセスできますが、使用できなくなります。アプリケーションを使用できる状態へ再起動するには、ドライブへCDを挿入し、Linux NetVault Bare Metal Recovery Clientの再起動を行う必要があります。

使用中のプラグインやデータ転送速度の値などを含む、選択したジョブに関するさまざまな情報が表示されます。［実行ステータス］フィールドにはジョブのステータスが表示されます（［メディア待機中］または［メディア読み取り中］など）。リカバリが完了すると、データ転送の値が停止し、このフィールドが更新されて［リストア完了］になります。

リカバリ・プロセスを完了するには、Linux NetVault Bare Metal Recovery Client マシンにローカルでアクセスし、System Installation for Linuxアプリケーションの［システムの再起動］コマンドを使用して、Linux NVBMR Clientマシンを再起動します。メンテナンス・シェル・プロンプトで「exit」と入力するか、システムを手動でシャットダウンします。

Linux NetVault Bare Metal Recovery Clientが起動し、ファイル・システムは、DRイメージの作成時点の状態にリカバリされます。

fsckプロセス中に「Superblock last…」メッセージが表示される

リストアすると、クロックの不整合に関するfsckエラーや、UTC（Universal Time Coordinated：協定世界時）を使用しないシステムに対する強制チェックなどを引き起こす問題が発生することがあります。リストア後に最小にシステムを起動したとき、それらのエラーは、「Superblock last mount time is in the future」メッセージとして表示されますが、このメッセージは無視することができます。この問題に対処するには、以下の手順に従います。

Storixメディアを使用して、ターゲット・クライアントを起動します。

Storix内のメンテナンス・シェルを開き、以下のコマンドを実行します。

hwclock --hctosys --localtime

リストアを実行します。

Plug-in Live Client for Linuxで使用するためのリストア後要件の完了

対象となる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ファイル・エントリを暗黙的に変更します。

例：

たとえば、リストア前には、「fstab」にはスワップ・デバイス用に以下のエントリが含まれます。

LABEL=SWAP-sda2 swap swap defaults 0 0

しかし、リストア後には、元のスワップ･エントリはコメント・アウトされ、新規エントリが追加されます。

# Updated by Storix System Installation

#LABEL=SWAP-sda2 swap swap defaults 0 0

/dev/sda2 swap swap defaults 0 0

スワップ・パーティションは自動的に使用可能になりますが、スワップ・パーティション用のラベルは削除されます。

•

ファイル・システム・チェックの有効化：リストアにより、［Maximum mount count］パラメータと［Check interval］パラメータが変更され、これによりファイル・システム・チェックが有効になります。マウント数または指定期間に基づいてパラメータを有効にすべきではないシステムの場合は、以下のコマンドを使用して手動でオプションを無効にします。

# tune2fs -c -1 <deviceName>

# tune2fs -i 0 <deviceName>

手動によるUUID情報の更新

Plug-in Live Client for Linuxを使用してデータをリストアすると、各ファイル・システムのUUIDが再作成されます。/boot/grub/grub.confファイルと/etc/fstabファイル内でUUIDが使用されており、これらがPlug-in for FileSystemを使用して前回のバックアップからリストアされた場合、システムは起動に失敗します。これはUUIDが実際のファイル・システム上の値と一致しないためです。この問題を回避するには、ファイルを手動で更新します。

以下の手順では、「dev」や「sda」などのコマンドの使用例を示します。ただし、これらのコマンドを実行する際には、該当する情報をご使用の環境に適した情報で置き換える必要があります。

rootでログインし、作業ディレクトリに移動します。

Plug-in for FileSystemと前回のバックアップを使用して/boot/grub/grub.confファイルと/etc/fstabファイルを作業ディレクトリにリストアします。

デバイス・ファイル名とそのマウント・ポイントを識別してメモするには、以下のコマンドを実行します。

# mount | grep ^/dev

/dev/sda3 on / type ext4 (rw)

/dev/sda1 on /boot type ext4 (rw)

スワップ・デバイス情報を識別して記録するには、次のコマンドを実行します。

# swapon -s

Filename Type Size Used Priority

/dev/sda2 partition 2097144 0 -1

スワップ情報を含むデバイス・パーティションのUUIDをエクスポートしてファイルを保存するには、以下のコマンドを実行します。

各デバイスについて、コマンドライン上で「in」ステートメントの後に「sda1」、「sda2」および「sda3」などの名前を指定します。各デバイス・パーティションについて、@デバイス_パーティション_名前@の形式で名付けられたファイルが作業ディレクトリに作成されます。このファイルには、関連付けられているUUIDが含まれています。

# export LANG=C; export LC_ALL=C

# for dev in sda1 sda2 sda3

> do

> ls -l /dev/disk/by-uuid/ | awk "/$dev\$/

{print \$9}" > @$dev@

> done

パーティションについてファイルが作成され、各ファイル内でパーティションごとにUUIDが正しく記録されているか確認します。

任意のテキスト・エディタを使用してgrub.confファイルを開きます。

root=UUID=x-x-x-x-xを含むエントリについて、x-x-x-x-x-xをパーティション名に一致させ、UUIDをパーティション名で置き換えます。

変更前の例

kernel /vmlinuz-2.6.32-131.0.15.el6.x86_64 ro

root=UUID=dc8ee87c-1ac3-4ece-ab53-f19cd1ebaf7e rd_NO_LUKS …

変更後の例

kernel /vmlinuz-2.6.32-131.0.15.el6.x86_64 ro

root=UUID=@sda3@ rd_NO_LUKS …

任意のテキスト・エディタを使用してfstabファイルを開きます。

Step 3とStep 4でメモした情報を使用して、UUIDをすべてのマウントとスワップ・パーティションのデバイス・パーティション名に変更します。

変更前の例

UID=dc8ee87c-1ac3-4ece-ab53-f19cd1ebaf7e

/ ext4 defaults 1 1

UUID=6c285d5c-9669-4791-a214-2ed007a7e454

/boot ext4 defaults 1 2

UUID=84fd7dad-f9a8-4102-9102-fa62c8def671

swap swap defaults 0 0

変更後の例

UUID=@sda3@ / ext4 defaults 1 1

UUID=@sda1@ /boot ext4 defaults 1 2

UUID=@sda2@ swap swap defaults 0 0

grub.confおよびfstabファイル内のデバイス名をUUIDに変更するには、以下のコマンドを実行します。

# for dev in @*@

> do

> sed -i "s/$dev/$(cat $dev)/g" grub.conf fstab

> done

任意のテキスト・エディタを使用してgrub.confファイルとfstabファイルを開き、デバイス名が対応するUUIDに正しく置き換えられたか確認します。

/boot/grub/grub.confと/etc/fstabのバックアップ・コピーを作成します。

# cp -a /boot/grub/grub.conf /boot/grub/grub.conf.org

# cp -a /etc/fstab /etc/fstab.org

grub.confファイルとfstabファイルを作業ディレクトリから元の場所へとコピーし、grub.confからmenu.lstへのシンボリック・リンクを再作成します。

# cp -a grub.conf /boot/grub/grub.conf

# cp -a fstab /etc/fstab

## cd /boot/grub

# rm menu.lst

# ln -s ./grub.conf menu.lst

サーバを再起動し、正しく起動したことを確認します。

システムが起動に失敗した場合、レスキュー・ディスクを使用してシステムをレスキュー・モードで起動し、Step 13で作成したバックアップ・ファイルを元の場所にコピーしなおしてから再度サーバを起動してください。新規に作成されたgrub.confファイルとfstabファイルを再度確認し、必要な修正を加えてからStep 13からStep 15を再実行します。

请选择您的产品：

为向您提供更好的服务，请填写'Purpose of your Chat'（联系目的）：

针对您的问题建议的解决方案

NetVault Bare Metal Recovery 12.0 - Plug-ins ユーザー・ガイド

Plug-in Live Client for Linux でのジョブ進行状況の監視とリカバリのファイナライズ

fsckプロセス中に「Superblock last…」メッセージが表示される

Plug-in Live Client for Linuxで使用するためのリストア後要件の完了

手動によるUUID情報の更新