Skip to main content
BlueXP backup and recovery
すべてのクラウドプロバイダ
  • Amazon Web Services の
  • Google Cloud
  • Microsoft Azure
  • すべてのクラウドプロバイダ
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

SnapMirrorを使用してボリュームをBlueXPバックアップとリカバリによるクラウド再同期に移行します

共同作成者 amgrissino
PDF

BlueXP バックアップおよびリカバリの SnapMirror to Cloud Resync 機能は、NetApp 環境でのボリューム移行中のデータ保護と継続性を効率化します。SnapMirror論理レプリケーション（LRSE）を使用して、オンプレミスのNetApp環境から別の環境、またはCloud Volumes ONTAPやCloud Volumes Serviceなどのクラウドベースのソリューションにボリュームを移行する場合、SnapMirrorからクラウドへの再同期により、既存のクラウドバックアップに影響を与えずに運用できます。

この機能により、時間とリソースを大量に消費するベースライン再処理が不要になり、移行後もバックアップ処理を継続できます。この機能は、FlexVolとFlexGroupの両方をサポートするワークロードマイグレーションシナリオで役立ちます。ONTAPバージョン9.16.1以降で使用できます。

メモ この機能は、2025 年 5 月にリリースされたBlueXP backup and recoveryバージョン 4.0.3 以降で利用できます。

SnapMirrorからクラウドへの再同期は、環境全体でバックアップの継続性を維持することで運用効率を高め、ハイブリッドクラウドやマルチクラウドのデータ管理の複雑さを軽減します。

注意 BlueXP backup and recoveryのワークロードを切り替えるには、 "さまざまなBlueXP backup and recoveryワークロードに切り替える" 。

作業を開始する前に

次の前提条件が満たされていることを確認してください。

  • デスティネーションONTAPクラスタでONTAPバージョン9.16.1以降が実行されている必要があります。

  • 古いソースONTAPクラスターは、BlueXP backup and recoveryを使用して保護する必要があります。

  • SnapMirror to Cloud Resync 機能は、2025 年 5 月にリリースされたBlueXP backup and recoveryバージョン 4.0.3 以降で利用できます。

  • オブジェクト ストレージ内の最新のバックアップは、古いソース、新しいソース、およびオブジェクト ストア全体の共通スナップショットである必要があります。共通スナップショットは、オブジェクト ストアにバックアップされた最新のスナップショットよりも古いものにすることはできません。

  • 再同期操作を開始する前に、古いONTAPで使用されていたスナップショット ポリシーとSnapMirrorポリシーの両方を新しいONTAPクラスタに作成する必要があります。再同期プロセスでポリシーを使用する場合は、そのポリシーも作成する必要があります。再同期操作ではポリシーは作成されません。

  • 移行ボリュームのSnapMirror関係に適用されるSnapMirrorポリシーに、クラウド関係で使用されるものと同じラベルが含まれていることを確認します。問題を回避するには、ボリュームとすべてのスナップショットの正確なミラーを管理するポリシーを使用します。

メモ SVM-Migrate、SVM-DR、またはヘッドスワップ方式を使用した移行後のSnapMirrorからクラウドへの再同期は、現在サポートされていません。

BlueXP backup and recoverySnapMirror to Cloud Resyncの仕組み

機器更改を完了したり、ONTAPクラスタ間でボリュームを移行したりする際には、バックアップが中断されずに継続的に機能することが重要です。BlueXP  のバックアップとリカバリSnapMirrorからクラウドへの再同期は、ボリューム移行後もクラウドバックアップの一貫性を維持することで、これを支援します。

次に例を示します。

Vol1aという名前のオンプレミスボリュームがあるとします。このボリュームには、S1、S2、S3の3つのSnapshotがあります。これらのスナップショットは、リストアポイントのようなものです。vol1は、SnapMirror to Cloud（SM-C）を使用してクラウドオブジェクトストアエンドポイントにすでにバックアップされています。ただし、これまでのところ、オブジェクトストアにバックアップされているのはS1とS2のみです。

次に、vol1を別のONTAPクラスタに移行します。これを行うには、Vol1bという新しいクラウドボリュームに対するSnapMirror論理レプリケーション（LRSE）関係を作成します。これにより、S1、S2、S3の3つのSnapshotすべてがVol1aからVol1bに転送されます。

移行が完了したら、次のセットアップを完了します。

  • 元のSM-C関係（Vol1a→オブジェクトストア）が削除されます。

  • LRSE関係（Vol1a→Vol1b）も削除されます。

  • これでVol1bがアクティブボリュームになります。

この時点で、同じクラウドエンドポイントにVol1bのバックアップを続行します。ただし、フルバックアップを（時間とリソースをかけて）ゼロから開始する代わりに、SnapMirrorからクラウドへの再同期を使用します。

再同期の仕組みは次のとおりです。

  • システムは、Vol1aとオブジェクトストアの間に共通のSnapshotがあるかどうかをチェックします。この場合、両方ともS2を持ちます。

  • この共有スナップショットのため、システムはS2とS3間の差分変更のみを転送する必要があります。

つまり、ボリューム全体ではなく、S2の送信後に追加された新しいデータのみがオブジェクトストアに送信されます。

このプロセスにより、すでにバックアップされているデータの再送信を回避し、帯域幅を節約し、移行後もバックアップチェーンをスムーズに継続できます。

BlueXP  バックアップとリカバリSnapMirrorからクラウドへの再同期

手順に関する注意事項

  • BlueXP  のバックアップとリカバリを使用して移行や機器更改を実行することはありません。担当者は、プロフェッショナルサービスチームまたは認定ストレージ管理者に依頼してください。

  • NetApp移行チームは、ボリュームの移行を容易にするために、ソースとデスティネーションのONTAPクラスタ間のSnapMirror関係を作成します。

  • 機器更改時の移行がSnapMirrorベースの移行に基づいていることを確認

SnapMirrorを使用したボリュームのクラウド再同期への移行方法

SnapMirrorからクラウドへの再同期を使用してボリュームを移行するには、次の主要な手順を実行します。それぞれについて詳しくは、以下で説明します。

  • 移行前のチェックリストに従う：移行を開始する前に、NetApp機器更改チームが次の前提条件を満たしていることを確認し、データ損失を防ぎ、スムーズな移行プロセスを実現します。

  • 移行後のチェックリストに従う：移行後、NetApp機器更改チームは次の手順を実行して保護を確立し、再同期の準備を行います。

  • * SnapMirrorからクラウドへの再同期を実行*：移行後、NetApp機器更改チームがSnapMirrorからクラウドへの再同期処理を実行し、新しく移行したボリュームからクラウドへのバックアップを再開します。

SnapMirrorを使用したボリュームのクラウド再同期への移行手順

移行前のチェックリストに従う

NetApp機器更改チームは、移行を開始する前に、データ損失を回避し、スムーズな移行プロセスを実現するために、次の前提条件を満たしていることを確認します。

  1. マイグレートするすべてのボリュームがBlueXP  のバックアップとリカバリを使用して保護されていることを確認します。

  2. ボリュームインスタンスUUIDを記録します。移行を開始する前に、すべてのボリュームのインスタンスUUIDを書き留めます。これらの識別子は、あとでマッピングおよび再同期処理を実行する際に非常に重要です。

  3. SnapMirror関係を削除する前に、各ボリュームの最後のSnapshotを作成して最新の状態を維持します。

  4. SnapMirrorポリシーを文書化する。各ボリュームの関係に現在適用されているSnapMirrorポリシーを記録します。この設定は、あとでSnapMirrorからクラウドへの再同期プロセスで必要になります。

  5. オブジェクトストアとのSnapMirror Cloud関係を削除します。

  6. 新しいONTAPクラスタとの標準のSnapMirror関係を作成して、新しいターゲットONTAPクラスタにボリュームを移行します。

移行後のチェックリストに従う

移行後、NetApp機器更改チームは次の手順を実行して保護を確立し、再同期の準備を行います。

  1. デスティネーションONTAPクラスタに移行されたすべてのボリュームの新しいボリュームインスタンスUUIDを記録します。

  2. 古いONTAPクラスタで使用可能であった必要なすべてのSnapMirrorポリシーが、新しいONTAPクラスタで正しく設定されていることを確認します。

  3. BlueXP  キャンバスで、新しいONTAPクラスタを作業環境として追加します。

    メモ ボリューム ID ではなく、ボリューム インスタンス UUID を使用する必要があります。ボリューム インスタンス UUID は移行全体で一貫性が保たれる一意の識別子ですが、ボリューム ID は移行後に変更される可能性があります。

SnapMirrorからクラウドへの再同期

移行後、NetApp機器更改チームがSnapMirrorからクラウドへの再同期処理を実行し、新たにマイグレートしたボリュームからクラウドのバックアップを再開します。

  1. BlueXP  キャンバスで、新しいONTAPクラスタを作業環境として追加します。

  2. BlueXP  の[Backup and Recovery Volumes]ページで、古いソースの作業環境の詳細が表示されていることを確認します。

  3. BlueXP  の[ボリュームのバックアップとリカバリ]ページで、*[バックアップ設定]*を選択します。

    • バックアップ設定ページで、[すべて表示] を選択します。

    • 新しいソースの右側にある [アクション…​] メニューから、バックアップの再同期 を選択します。

  4. [Resync Working Environment]ページで、次の手順を実行します。

    1. 新しいソース作業環境：ボリュームが移動された新しいONTAPクラスタを入力します。

    2. 既存のターゲットオブジェクトストア：古いソース作業環境のバックアップを格納するターゲットオブジェクトストアを選択します。

  5. [CSVテンプレートのダウンロード]*を選択して、[再同期の詳細] Excelシートをダウンロードします。このシートを使用して、マイグレートするボリュームの詳細を入力します。CSVファイルで、次の詳細を入力します。

    • ソースクラスタの古いボリュームインスタンスUUID

    • デスティネーションクラスタの新しいボリュームインスタンスUUID

    • 新しい関係に適用するSnapMirrorポリシーを指定します。

  6. [Upload Volume Mapping Details]*で[Upload]*を選択し、完成したCSVシートをBlueXP  バックアップ/リカバリUIにアップロードします。

    メモ ボリューム ID ではなく、ボリューム インスタンス UUID を使用する必要があります。ボリューム インスタンス UUID は移行全体で一貫性が保たれる一意の識別子ですが、ボリューム ID は移行後に変更される可能性があります。

  7. 再同期処理に必要なプロバイダとネットワークの設定情報を入力します。

  8. [送信]*を選択して検証プロセスを開始します。

    BlueXP backup and recoveryでは、再同期対象として選択された各ボリュームが最新のスナップショットであり、少なくとも 1 つの共通スナップショットがあることが検証されます。これにより、ボリュームがSnapMirrorから Cloud Resync 操作の準備が整っていることが保証されます。

  9. 新しいソースボリュームの名前や各ボリュームの再同期ステータスなど、検証結果を確認します。

  10. ボリュームの適格性を確認します。システムはボリュームが再同期の対象となるかどうかを確認します。ボリュームが不適格な場合は、最新のスナップショットではないか、共通のスナップショットが見つからなかったことを意味します。

    重要 ボリュームがSnapMirrorからクラウドへの再同期処理の対象となるようにするには、移行前のフェーズでSnapMirror関係を削除する前に、各ボリュームの最終Snapshotを作成します。これにより、データの最新の状態が保持されます。

  11. 再同期操作を開始するには、「再同期」を選択します。システムは最新の共通スナップショットを使用して増分変更のみを転送し、バックアップの継続性を保証します。

  12. ジョブ モニター ページで再同期プロセスを監視します。