VMwareからIBM Cloud VPC VSIへ（パート4）：バックアップとリストア

本記事は、原著者の許可を得て以下のリンクを翻訳したものです。翻訳内容に誤りがある場合、その責任は翻訳者にあります。また記事によっては、訳語を適宜Qiitaで読みやすいように段落分け、カテゴライズ分けをして記述しているものもありますのでご了承ください。

https://fullvalence.com/2025/11/20/from-vmware-to-ibm-cloud-vpc-vsi-part-4-backup-and-restore/

このシリーズの全てのブログ記事はこちらです：

• VMwareからIBM Cloud VPC VSIへ（パート1）：導入
• VMwareからIBM Cloud VPC VSIへ（パート2）：VPCネットワーク設計
• VMwareからIBM Cloud VPC VSIへ（パート3）：仮想マシンの移行
• VMwareからIBM Cloud VPC VSIへ（パート4）：バックアップとリストア

IBM Cloud には、IBM Cloud VSI 上で稼働するアプリケーションのバックアップに関係する 2 つのバックアップサービスが用意されています。

重大な VM 障害に対しては、IBM Cloud Backup for VPC を利用し、仮想マシン全体のクラッシュ整合性を持つボリュームバックアップとリカバリーを実行します。

特定のファイルやフォルダーの復旧が必要な場合は、IBM Cloud Backup and Recovery のエージェントベースの「物理サーバー」バックアップ機能を利用し、VSI のファイルシステムの一部または全体をバックアップし、選択したファイルまたはフォルダーを元の場所または新しい場所へ復元します。

これら 2 つのサービスは、ボリュームバックアップとファイルバックアップという補完的な焦点を持っているため、あらゆる障害シナリオをカバーするには両方を組み合わせて利用する必要があります。以下では、それぞれの機能と制限について説明します。

Backup for VPC ― ボリュームスナップショット

IBM Cloud の「ハンバーガーメニュー」から Infrastructure -> Storage -> Backup policies に移動すると、バックアップポリシーを作成できます。これらのバックアップポリシーでは、ボリュームのタグ付け条件に基づいて 1 つ以上のボリューム（ブロックまたはファイル）を選択したり、VSI のタグ付け条件に基づいて 1 つ以上の VSI に紐づくボリュームを選択したりできます。スナップショットのスケジュールは最大 4 つまで定義でき、たとえば「保持期間 7 日の毎日スケジュール」と「保持期間 90 日の毎週スケジュール」を併用するといった設定も可能です。IBM Cloud は、スナップショットをスペース効率の良いチェーンとして保持します。VMware のスナップショットとは異なり、IBM Cloud のブロックストレージスナップショットは VSI のボリュームおよび VSI のブートイメージとは別のチェーンとして存在します。IBM Cloud のスナップショットは、VSI を削除しても保持されます。注意すべき重要な点がいくつかあります。

1. 個々のボリュームのポイントインタイムスナップショットや、個々の VSI について複数ボリュームの一貫性を保ったスナップショットを作成するために、あなた自身で自動化の仕組みを作り、スケジュールを設定することもできます。たとえば、スナップショットの取得前にデータベースやファイルシステムをquiesce（静止）させたい場合は、この方法が有効です。
2. VSI ボリュームのスナップショット（スタンドアロンスナップショット、バックアップポリシーによるスナップショットのどちらでも）は、VSI に紐づくすべてのボリューム間で書き込み順序の一貫性があります。しかし、複数の VSI にまたがって書き込み順序の一貫性を保証することは現在のところできません。そのため、スナップショット取得中にデータベースやファイルシステムの書き込みを独自にアウトオブバンド（訳注：ストレージ側の自動処理に頼らず、アプリケーションや OS レベルで制御することを指しています）でquiesce（静止）させる方法が必要になります。
3. コンシステンシーグループ（訳注：複数のボリュームにまたがって整合性の取れた一貫したスナップショットを取得する機能です）は、第 2 世代 sdp ボリュームプロファイルでは現在サポートされていません。この点が時間とともに改善されることを期待していますが、現時点では使用を推奨しません。
4. スナップショットを自身で直接実行するのではなく、Backup for VPC サービスを利用してバックアップポリシーを作成する場合、VPC 内の複数のリソースとの間に 4 種類のサービス間認可を作成する必要があります。これら 4 種類のリソースに対して個別に詳細な認可を作成することが重要です。私の経験では、VPC Infrastructure Services 全体を Backup for VPC に管理させる包括的な認可を作成しても正しく動作しません。
5. 実行中の VSI のリージョン外に耐障害性のあるバックアップを確保する必要がある場合、個々のスナップショットを（コンシステンシーグループ全体ではなく）1 つずつ別リージョンにコピーすることができます。このプロセスを自動化し、一部のバックアップがリージョン外に確実に存在するようにすることも可能です。
6. VSI やボリュームの数が増え、さらにバックアップポリシーによって掛け算的にスナップショットが増えると、IBM Cloud UI 上でコンシステンシーグループやスナップショットを可視化・管理することが困難になります。これらを可視化・管理するための独自の自動化を構築する必要が出てくるでしょう。
7. ここで説明しているプロセスは VSI のボリュームのみをバックアップします。VSI の名前、インスタンスプロファイル、VNI および IP アドレス、セキュリティグループ、Floating IP などの追加設定は、この方法ではバックアップされません。データを復元するには、ボリュームまたは各コンシステンシーグループから新しい VSI を作成し、VSI の追加設定を再構成する必要があります。大規模に VSI を復元する可能性がある場合、これらの情報を記録し復元を自動化する仕組みを構築する必要があるでしょう。
8. 一部のスナップショットをリージョナルバックアップストレージからゾーン内ブロックストレージにコピーしておき、高速にプロビジョニングする高速リストアの概念があります。しかし、高速リストアは個別ボリュームのスナップショットのみに利用でき、VSI のコンシステンシーグループには利用できません。
9. バックアップポリシーのその他の制限事項については IBM Cloud のドキュメントを参照してください。

ボリューム全体や VSI 全体のバックアップとリストアは、削除されたファイルの復元など特定のバックアップシナリオに対しては過剰となる場合があります。利便性のために、Backup for VPC の機能に加えて Backup and Recovery を併用することを検討してもよいでしょう。

Backup and Recovery― ファイルおよびフォルダー

Backup and Recovery は、VSI 上で稼働するエージェント（サービス上では「物理サーバー」と呼ばれています）を利用して、ファイル、フォルダー、および特定のデータベースをバックアップします。IBM は現在サポートされているオペレーティングシステムとデータベースのバージョン一覧を公開しています。

このサービスを利用するための手順は以下のとおりです。

1. IBM Cloud の「ハンバーガーメニュー」を開き、Backup and Recovery -> Backup service instances に移動します。

2. 任意のリージョンでインスタンスを作成します。Backup and Recovery は現在 HPCS の暗号鍵と統合されていますが、Key Protect の暗号鍵サポートも近く追加される予定です。独自の鍵を設定しない場合、バックアップストレージは IBM 管理の鍵で暗号化されます。

3. 作成したインスタンスの詳細画面を開き、Launch dashboard をクリックしてインスタンスのダッシュボードにログインします。ダッシュボードは IBM Cloud と同じ認証情報を使用しますが、動的な SSO 統合は行われていないため、再度ログインする必要があります。

4. System -> Data Source Connections に移動し、VPC を表す論理接続を作成します。複数の VPC がある場合は、それぞれに接続を作成すべきです。

5. 次に、IBM Cloud VPC 内でいくつかの準備を行います

   • VPC内に、VPC と同じリージョンにある Cloud Object Storage（COS）向けの VPE（Virtual Private Endpoint）ゲートウェイ を作成します。VPC 内に IBM Cloud Kubernetes インスタンスを作成済みの場合、このゲートウェイがすでに存在していることがあります。
   • Backup and Recovery インスタンス向けの VPE ゲートウェイも作成します。
   • 先程の手順で作成した論理接続のデータ転送を担うため、VPC 内に 1 つ以上のコネクター VSIを作成します。高可用性を確保するため、IBM では少なくとも 2 つの VSI コネクタを作成することを推奨しています。さらに目安として、同時にバックアップする VSI が 10 台ごとに 1 つのコネクタを追加することをおすすめします。
   • セキュリティグループが、これらのコネクター VSI と 2 つの VPE、そしてワークロード VSI との通信を許可していることを確認する必要があります。通常はデフォルトで問題ありませんが、私の場合、IBM Cloud Kubernetes サービスによって以前作成されていた COS VPE が、コネクター VSI と同じセキュリティグループを共有していませんでした。そのためバックアップが成功せず、この設定を修正するまで失敗し続けました。

6. 次に、バックアップ対象のワークロード VSI を準備します。これは Backup and Restore ダッシュボード内の Data Protection -> Sources ビューで管理します。このビューから VSI 用のエージェントをダウンロードし、それぞれの VSI を「物理サーバー」として登録します。この登録の過程で、前のステップで作成した論理接続に関連付けます。これにより、コネクターが VSI 上のエージェントへ接続し始めます。VSI 上のファイアウォールを厳密に管理している場合、コネクターとワークロード VSI 間で開放すべきポートを確認しておく必要があります。

7. 次に、Data Protection -> Policies ビューでバックアップスケジュールを管理し、Data Protection -> Protection ビューで保護グループを作成してこれらのポリシーを利用するバックアップジョブをスケジュールします。デフォルトでは VSI 上のすべてのファイルがバックアップされますが、特定のフォルダーを含める／除外するリストを指定することもできます。

8. 最後に、Data Protection -> Recoveries ビューを使用してファイルおよびフォルダーを復元できます。ブラウザー経由でダウンロードすることも、元のシステム（元の場所または一時フォルダー）に復元することも、またはバックアップエージェントを実行し Data Protection -> Sources に登録されている別のシステムへ復元することも可能です。

常に、アラートなどの追加の考慮事項を理解するためにドキュメントを十分に確認するようにしてください。