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

Plug-in Live Client for Linuxでのジョブ進行状況の監視とリカバリの終了

NetVault Backup Serverから、［ジョブ・ステータス］ページを使用してジョブの進行状況を監視できます。ジョブの進行状況を監視する必要はありませんが、NetVault Bare Metal Recovery Clientのリカバリを実行する場合は進行状況を監視することをお勧めします。Linux NetVault Bare Metal Recovery Clientのリカバリが完了したら、オンラインに戻すための最後のタスクを実行する必要があります。リカバリ・ジョブを監視することにより、ジョブの完了通知を受け取り、この最後のタスクを実行できます。


	メモ：このトピックでは、NetVault Backup WebUIの［ジョブ・ステータス］ページを使用して、Linux DRリカバリ操作の進行状況を監視し、ジョブを終了する例を説明します。このダイアログ・ボックスで使用できるツールはPlug-in Live Client for Linux専用ではありません。使用法についての詳細は、『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アプリケーションのReboot the Systemコマンドを使用して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）を使用するシステムの場合、正しいデバイスUUIDで/boot/grub/grub.confおよび/etc/fstabを確認し編集します。詳細は、「手動による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.4 - Plug-ins ユーザー・ガイド

Plug-in Live Client for Linuxでのジョブ進行状況の監視とリカバリの終了

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

Plug-in Live Client for Linuxで使用する復元後要件の完了

手動によるUUID情報の更新