4.7 EValutで異なるサーバーに戻す方法は？

（2016年時点での内容をアーカイブとして掲載しているため、一部の掲載内容が最新情報とは異なる場合がありますので、ご了承ください。最新のIBM Cloudのアップデート情報は[IBM Cloud アップデート情報](https://www.ibm.com/cloud-computing/jp/ja/cloud-update/) や [柔らか層本](https://ibm.ent.box.com/v/ibmcloud-yawaraka)をご参照ください。）

概要
ここでは、EVaultでバックアップを取得していたサーバーとディスクが同時に失われてしまったというシナリオで、EVaultバックアップを異なるサーバー上にリストアする方法をご紹介します。
 

サーバーとディスクが消えてしまった！
実際の運用上でサーバーとディスクが同時に失われることはめったにないかもしれません。 しかし、オペレーション・ミスによって消えてしまう可能性はゼロでは無いかもしれません。 ここでは想定のシナリオを再現するために、問答無用で該当サーバーをディスクごとキャンセルします。

この時点で、サーバーの状況は、次のとおりです。

対象のサーバーとディスクは完全に消えている
    lhk-server-1.example.com(10.110.71.101)

OS領域のイメージ・テンプレートは存在している
    OSのイメージのバックアップが存在しなくても、新しいサーバーを注文してデータのリストアは可能ですが、失われたサーバーと同等な環境を構築する必要がある場合、イメージ・テンプレートを利用すると、最短の道になります。

EVaultバックアップの運用状況は、次のとおりです。
 

バックアップ先は、ローカルである
バックアップ対象は、特定のフォルダー(/var/www)を含む、拡張ディスク上にあるデータ・ファイルを対象にしている
バックアップ・ジョブは、毎日0時30分にEVaultによって自動実行されている。
前日までのバックアップは成功している。
 

新しいサーバーへのリストア・シナリオ
今回のリストアは、バックアップを取得していたサーバーと異なるサーバーへのリストアです。 下の図のようにリストアするためには、次のような手順を踏んでいく必要があります。
 

失われたサーバーの代わりに新しいサーバーを起動
今回は、失われたサーバーと同じ環境を構築するということで、イメージ・テンプレートから新しいサーバーを起動し、ホスト名も同じにします(lhk-server-1.example.com)。 かならず、イメージ・テンプレートからサーバーを起動しなくてもよく、ホスト名も失われたサーバーと同じである必要はありません。
 

拡張ディスクを注文し、マウント・ポイントにマウント
 マウント・ポイントは、なるべく失われたサーバーと同じようにしておいたほうが、後々の作業としては簡便です。 しかし、何も特定できないような場合は、適切な容量のディスクを用意しておくだけでもリストアは可能です。 詳細なディレクトリ構造まで再現しておく必要はありません。
 

EVaultバックアップの環境を再設定
新しいサーバーにEVaultのエージェントをインストールし、管理コンソールからEVaultの環境を新しいサーバー向けに再設定します。 追加のEVaultを購入する必要はありません。
 

新しいサーバーへのリストアを実行
リストア手順は、通常のリストアと同じです。

これから、「Evaultバックアップ環境の再設定」から説明を始めます。 サーバーの起動やディスクの追加については、カスタマーポータルをご利用お願いします。 あるいは「4.9 コマンドラインからサーバーを起動／削除するには？」と「3.6 サーバーのストレージを増減するには？」を参照してください。

Evaultバックアップの環境を再設定するには
EVault管理コンソールの状態確認

エージェントが入っていたサーバーが失われた場合のEVault管理コンソールの状態を確認してみましょう。 EVault管理コンソールへの接続は、VPN接続をしてから可能になります。 VPN接続については、2.7 パブリックIPからのログインを禁止して、保守するには？を参照してください。

カスタマーポータルから、「Storage」->「Backup」をクリックすると、「EVault Backup」画面が表示されます。 対象EVaultユーザー名をクリックし、EVaultユーザーの詳細情報から管理コンソールへログインするために「WebCC」というリンクをクリックします。 この「EVault Backup」画面のユーザー名とパスワードを控えておきましょう。 あとで、EVaultエージェントのインストール時に必要です。 特にログイン画面は表示されません。

下の図は、エージェントが入っているサーバーが失われた後のEVault管理コンソールの状態です。 画面上段のエージェントおよび画面下段のジョブ一覧は正常に見えますが、マウス・カーソルを持っていても、何も操作することはできません。 それでも、失われたサーバーのEVaultバックアップが残っていることは確認できます。


新しいサーバーへEVaultエージェントのインストール

次は、新しいサーバーへログインし、EVaultエージェントをインストールし、EVaultバックアップ上のエージェント登録を新しいサーバー情報に更新します。 イメージ・テンプレートから構築したサーバーの場合は、EVaultエージェントのインストール・パッケージのダウンロードは必要ないかもしれません。

Linuxの場合

対象のサーバー上で、次のように実行します。 途中で先ほど控えたEVaultのユーザー名とパスワードの入力が必要です。
 
```
# wget -N http://downloads.service.softlayer.com/evault/evault_manual.sh
# sh ./evault_manual.sh

RedHat based distribution detected.

Please supply the WebCC username for this server: SL289550-1
Please supply the WebCC password for this server: ********

RHEL based installation
・・・中略
```

Windowsの場合

対象のサーバー上でインストール・パッケージをダウンロードして実行します。 必要な情報は、Linuxと同じです。http://downloads.service.softlayer.com/evault/EvaultInstall.exe

これでEVaultバックアップの環境を再設定する準備が整いました。 これからEVaultの管理コンソールからEVaultバックアップの環境を再設定します。

EVaultのバックアップの再設定

この設定のポイントは、失われたサーバーのEVaultバックアップを新しいサーバーと紐付けることです。 新しいサーバーにEVaultエージェントをインストールしてから、EVaultの管理コンソールに接続してみると、エージェント登録は警告になっており、バックジョブ・ジョブは見えない状態になっています。 これは、EVaultバックアップのエージェント登録だけが更新され、その新しいエージェントに対するバックアップ・ジョブが不明な状態だからです。

これは正常な範囲です。 この状態から赤枠の「This is a replacement for a computer that was previously protected」クリックし、EVaultバックアップの環境を新しいサーバー向けに再設定します。

次の「Re-register Vault」画面にある「User a Vault Profile」、「Vault Name」、「Vault Address」、「Credentials」のデフォルト設定はそのまま使います。

ここで「Load Computers」ボタンをクリックします。 下の図は、「Load Computers」ボタンをクリックした後の状態です。 「Load Computers」に上がって来たサーバー名とIPアドレスは、失われたサーバーのホスト名とIPアドレスです。 これは、異常ではありません。 ここで、失われたサーバーのEVaultバックアップを新しいサーバーのエージェントに紐付けるように指定するわけです。

「lhk-server-1(10.110.71.101)」を選択してから「Save Changes」ボタンをクリックし、先に進みます。 これで異なるサーバーへリストアするためのEVaultバックアップ環境の再設定は完了です。

EVaultバックアップ環境の再設定が完了すると、次のようにエージェントの警告が消え、バックアップ・ジョブも新しい環境の下に復帰しています。


異なるサーバー上にリストアするには
リストア対象は、すべてのジョブ

今回は、複数の箇所からのバックアップ・ジョブがリストアの対象になります。 このように複数バックアップ・ジョブからリストアを行う場合は、繰り返して操作を行います。 ここでは、「/var/www」を含むバックアップ・ジョブから、リストアを実行するとします。 ジョブを選択し、「Run Restore」をクリックします。

リストア対象のジョブが決まったら、バックアップ・データの正常性を確認します。 その方法としては、バックアップのデータのサイズ確認をおすすめします。 EVaultバックアップ側で、サーバー側のファイルの増減を正確に把握することは困難です。 最新のバックアップを含め、数日間の間のバックアップ・データのオリジナル・サイズを管理コンソールのヒストリ情報とバックアップ・ジョブの通知メールとの間で比較し、一致するかどうか確認を行います。

バックアップのヒストリの確認は、バックアップ・ジョブ一覧の右端の「History」アイコンをクリックすると表示されます。

最新の状態に戻す

データの正常性に問題がなければ、バックアップのバージョンは、最新版を選びます。 「Select a backup version」から「Restore from a single safest」をクリックし、「Restore from this backup version」から最新のバックアップを選択します。

すべてのファイルを戻す

今回は、すべてのファイルがリストア対象になりますので、バックアップ対象のフォルダー(www)を選択します。 リストアは、選択したフォルダーの配下にあるサブフォルダーやファイルが対象になります。 下の図のように「www」を選択した場合、サーバー上に「/var/www」ディレクトリが、存在すべきであることに要注意です。 「/var/www」ディレクトリが存在しないと、リストアは失敗します。


リストア先およびファイル書き込みのオプション指定
特別な理由がなければ、リストア先は元の場所にします。 「Restore to an alternate location」でリストア先を変えることもできます。 そして、リストアの実行時に同名のファイルが存在する場合の動作に関するオプションは「Overwrite existing files」にします。


リストア終了の確認
リストアが終了すると、次ようにレポートが表示されます。 リストアが成功したかどうかは、このレポートとバックアップ・ジョブの通知メールに記されているデータ容量、ファイルおよびフォルダー数が一致するかどうかで確認できます。