Veeam v13 S3 Object StorageからProxmoxへVMをリストアする方法

18

オブジェクトロック(WORM)した AWS S3 バケットに保存されたバックアップデータを、オンプレミスの仮想化基盤(Proxmox)に VM 単位でリストアを行いました。当たり前ですが、問題なくリストアできるのですが、段取りと結果を共有します。

本記事の検証構成

オンプレミスのローカルリポジトリを一次バックアップ(イミュータブル)、AWS S3 バケットを二次バックアップ(イミュータブル)として構成しています。二次バックアップのバックアップデータをオンプレミスにリストアします。

リストアの流れ

最初にざっくりと段取りと注意点を説明します。

1.リストア先のネットワーク環境の検討と準備

重要な点は IP アドレスと MAC アドレスが同一セグメントで重複させないことです。VM 単位でのリストアですので、十分に注意します。

本来の VM 単位のリストアは、バックアップソースの VM が何らかの問題で消滅している状態に対して、元と同じネットワークセグメントに復元することにあります。そのため、IP アドレスと MAC アドレスは同一であることが望ましいため、リストア時の手順で考慮することはありません。

ただし、バックアップソースの VM が正常稼働中にリストアをテストする場合、バックアップソースの VM とは別の独立させた仮想ネットワークセグメントにリストアします。この場合、リストア後の VM がネットワーク的にスタンドアローンとなりますので、リストア後の動作確認に制限が出ます。

本記事の場合、バックアップソースが本番サービスを提供中の VM ではないため、バックアップソースの VM の Proxmox のハードウェアオプションで仮想スイッチから切断してバックアップソースの VM がネットワーク的に存在しない状態にしてから、同セグメントにリストアしています。そのため、リストア後の VM の動作確認もネットワークに全て繋がっている状態でテストできました。

2.Veeam コンソールからリストア操作

後述で説明します。

3.リストア後の動作確認

ネットワークから切り離された状態で確認を行う場合、Proxmox 管理画面のコンソール機能で行います。VM 単位でのリストアの場合、特殊な条件下でなければ、確認はデータサイズやログなどの確認程度で十分なはずだからです。

もし、リストアする VM が外部 DB と連携していたり、DNS との連携が必須などの理由があって、正常動作の確認のためにどうしても他システムとの接続が必要な場合、リストアテスト用に本番環境とは別に必要なネットワークサービスや DB などの連携システム一式を予め構築しておくことになります。繰り返しになりますが、そこまでの必要性があるのかどうかは、コストメリットの観点含めて考慮が必要です。

リストア対象の VM の諸元

Proxmox 管理画面から見た VM のハードウェア情報です。ネットデバイスは「切断」済みです。

ゲスト OS についても容量と DB の正常性程度を確認しておきます。

# cat /etc/os-release | grep PRETTY_NAME
PRETTY_NAME="Rocky Linux 9.6 (Blue Onyx)"

# df -h -x tmpfs -x devtmpfs
/dev/mapper/rl-root    44G   11G   34G   24% /
/dev/sda1             960M  485M  476M   51% /boot

# mysqlcheck -u root -p --all-databases
Enter password:
mysql.columns_priv                                 OK
mysql.component                                    OK
mysql.db                                           OK
省略
wordpress1db.wp1_users                             OK
wordpress1db.wp1_wpo_404_detector                  OK

リストアの実行

リストアウィザードの起動

Veeam(以降VBR)のコンソールから “Backups” ⇒ “Object Storage(Copy)” でリストア対象のバックアップファイルを選択して右クリックし、”Restore entire VM” ⇒ “Proxmox VE…” をクリックすると、リストアウィザードが起動します。

1.Virtual Machines
リストアするバックアップイメージを選択します。

.Restore Mode
以下のどちらかを選択します。
・Restore to the original location
⇒単純に元の環境にリストアするだけではなく、バックアップソースの VM を VBR が削除してからリストアします。
・Restore to a new location, or with different settings
⇒バックアップソースの VM とは別の VM としてリストアしたければこれを選択。今回はこちらを選択しました。

3.Host
Proxmox VE のどのノードにVMを復元するかを指定します。また、オプション “Restore resource pools” を有効にした場合、バックアップソースの VM が所属していた時と同じリソースプールにリストアします。なお、リソースプールは Proxmox においては VM の管理単位ですので、IP アドレスとの競合問題の原因にはなりません。

4.Storage
Proxmox VE のどのストレージにリストアするか選択します。

5.Name
リストア時の VM ネームを指定します。今回はバックアップソースの VM と同じノードにリストアしますので、見分けやすいように “-test” を付与しました。

6.Network
リストア時の仮想スイッチ(仮想ブリッジ)を指定します。
今回、切断状態でリストアしたいので、”Disconnect” して、”Not Connected” にします。ただし、ここで「切断(Disconnect)」に設定すると、リストア時に MAC アドレスが自動的に「ランダムな新しい値」に書き換わるロジックになっていますので、MACアドレスを変更したくない場合は、”Not Connected” にしてはいけません。

今回はバックアップソースの VM の仮想スイッチを予め切断していますので、”Not Connected” にしなくても IP アドレスと MAC アドレスの重複は発生しないのですが、MAC アドレスが変化するのか確認をしたかったため、敢えて “Not Connected” にしました。

7.Reason
メモの記録の必要性がなければ空欄で “Next” をクリックします。

8.Summary
“Power on target VM after restoring” をチェックすると、リストア後に VM が自動的に起動します。ネットワーク周りの制御をしたい場合は、チェックを外します。最終確認をして “Finish” をクリックします。その直後からリストアプロセスが開始されます。

リストアプロセスを見守ります。本検証環境では、S3 バケットに約9.72GBのバックアップデータがあり、リストアプレセス開始から完了(Proxmox 上の VM 作成完了)まで、経過時間は約13分13秒でした。総合スループットで約12.5MB/sとなります。

動作確認

Proxmox 管理コンソールからリストアによって生成された VM を選択し、ハードウェア設定でネットデバイスを追加し、VM を起動します。

起動後のネットワーク周りの状態を確認します。

・IP アドレス
⇒変化ありませんでした。

・MAC アドレス
⇒変更されました。これはリストアウィザードのネットワークプロパティで “Not Connected” にした結果です。

ゲストOSの状態も確認します。

まず、ファイルシステム上の使用容量。変化なしでした。

# df -h -x tmpfs -x devtmpfs
/dev/mapper/rl-root    44G   11G   34G   24% /
/dev/sda1             960M  485M  476M   51% /boot

次に、DB のチェックです。こちらも問題なしでした。

# mysqlcheck -u root -p --all-databases
Enter password:
mysql.columns_priv                                 OK
mysql.component                                    OK
mysql.db                                           OK
省略
wordpress1db.wp1_users                             OK
wordpress1db.wp1_wpo_404_detector                  OK

以上となります。

次回は、AWS EC2 上に対して、S3 バケット上のバックアップデータをリストアしてみたいと思います。

makorin
  • makorin
  • AI を使用して情報を得ることが普通の時代になりました。その AI もウェブ上に公開されている情報を元にして動作しています。その情報の一つになればいいなという、極々ささやかな思いで気ままに更新しています。

コメントする

メールアドレスが公開されることはありません。 が付いている欄は必須項目です

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください