日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

NetApp Backup and RecoveryでSnapMirrorを使用してボリュームを Cloud Resync に移行する

11/04/2025 共同作成者

NetApp Backup and RecoveryのSnapMirror to Cloud Resync 機能は、 NetApp環境でのボリューム移行中のデータ保護と継続性を効率化します。SnapMirror Logical Replication (LRSE) を使用してボリュームをオンプレミスのNetApp展開から別の展開へ、またはCloud Volumes ONTAPなどのクラウドベースのソリューションに移行した場合、 SnapMirror to Cloud Resync により、既存のクラウドバックアップがそのままの状態で動作し続けることが保証されます。

この機能により、再ベースラインプロセスが不要になり、移行後もバックアップを続行できるようになります。この機能は、FlexVol と FlexGroup の両方をサポートし、ワークロード移行シナリオで役立ち、 ONTAPバージョン 9.16.1 以降で利用できます。

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

SnapMirror to Cloud Resync は、環境間でバックアップの継続性を維持し、ハイブリッドおよびマルチクラウド設定でのデータ管理を容易にします。

NetApp Backup and Recoveryのワークロードを切り替えるには、"さまざまなNetApp Backup and Recoveryワークロードに切り替える" 。

開始する前に

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

宛先ONTAPクラスタでは、 ONTAPバージョン 9.16.1 以降が実行されている必要があります。
古いソースONTAPクラスターは、NetApp Backup and Recoveryを使用して保護する必要があります。
SnapMirror to Cloud Resync 機能は、2025 年 5 月にリリースされたNetApp Backup and Recoveryバージョン 4.0.3 以降で利用できます。
オブジェクトストレージ内の最新のバックアップが、古いソース、新しいソース、およびオブジェクトストア全体の共通スナップショットであることを確認します。オブジェクトストアにバックアップされた最新のスナップショットよりも古い共通スナップショットを使用しないでください。
再同期操作を開始する前に、古いONTAPクラスタで使用されていたスナップショットポリシーとSnapMirrorポリシーの両方を、新しいONTAPクラスタに作成する必要があります。再同期プロセスでポリシーを使用する場合は、そのポリシーも作成する必要があります。再同期操作ではポリシーは作成されません。
移行ボリュームのSnapMirror関係に適用されるSnapMirrorポリシーに、クラウド関係で使用されるものと同じラベルが含まれていることを確認します。問題を回避するには、ボリュームとすべてのスナップショットの正確なミラーを管理するポリシーを使用します。

SVM-Migrate、SVM-DR、またはヘッドスワップ方式を使用した移行後のSnapMirrorから Cloud Resync への転送は現在サポートされていません。

NetApp Backup and RecoverySnapMirrorからクラウド再同期への仕組み

技術的な更新を完了したり、ボリュームを 1 つのONTAPクラスターから別のクラスターに移行したりする場合には、バックアップが中断されることなく継続して機能することが重要です。 NetApp Backup and Recovery SnapMirror to Cloud Resync は、ボリュームの移行後もクラウドバックアップの一貫性が維持されるようにすることで、この問題を解決します。

次に例を示します。

Vol1a というオンプレミスのボリュームがあるとします。このボリュームには、S1、S2、S3 の 3 つのスナップショットがあります。これらのスナップショットは復元ポイントです。 Vol1 はSnapMirror to Cloud (SM-C) を使用してクラウドにバックアップされていますが、オブジェクトストアには S1 と S2 のみが存在します。

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

移行が完了すると、次の設定になります。

元の SM-C 関係 (Vol1a → オブジェクトストア) は削除されます。
LRSE関係（Vol1a → Vol1b）も削除されます。
Vol1b がアクティブボリュームになりました。

この時点で、Vol1b を同じクラウドエンドポイントにバックアップし続ける必要があります。ただし、最初から完全なバックアップを開始する代わりに (時間とリソースがかかります)、 SnapMirrorを使用して Cloud Resync を実行します。

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

システムは、Vol1a とオブジェクトストア間の共通スナップショットをチェックします。この場合、両方とも S2 を持ちます。
この共有スナップショットにより、システムは S2 と S3 間の増分変更のみを転送する必要があります。

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

このプロセスにより、重複したバックアップが防止され、帯域幅が節約され、移行後もバックアップが継続されます。

NetApp Backup and RecoverySnapMirrorからクラウドへの再同期

手順に関する注意事項

移行と技術更新は、NetApp Backup and Recoveryを使用して実行されません。これらは、専門のサービスチームまたは資格のあるストレージ管理者が実行する必要があります。
NetApp移行チームは、ボリュームの移動を容易にするために、ソース ONTAP クラスターと宛先ONTAPクラスターの間にSnapMirror関係を作成します。
技術更新中の移行がSnapMirrorベースの移行に基づいていることを確認します。

SnapMirrorを使用してボリュームをCloud Resyncに移行する方法

SnapMirrorを使用してボリュームを Cloud Resync に移行するには、次の主要な手順が必要です。各手順については以下で詳しく説明します。

移行前のチェックリストに従う: 移行を開始する前に、 NetApp Tech Refresh チームは、データの損失を回避し、スムーズな移行プロセスを確実に実行するために、次の前提条件が満たされていることを確認します。
移行後のチェックリストに従う: 移行後、 NetApp Tech Refresh チームは、保護を確立し、再同期の準備を整えるために次の手順が完了していることを確認します。
* SnapMirrorからクラウドへの再同期を実行する*: 移行後、 NetApp Tech Refresh チームはSnapMirrorからクラウドへの再同期操作を実行し、新しく移行されたボリュームからクラウドバックアップを再開します。

SnapMirrorを使用してボリュームをCloud Resyncに移行する手順

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

移行前に、 NetApp Tech Refresh チームはこれらの前提条件をチェックして、データの損失を防ぎ、スムーズなプロセスを確保します。

移行するすべてのボリュームがNetApp Backup and Recoveryを使用して保護されていることを確認します。
ボリュームインスタンスの UUID を記録します。移行を開始する前に、すべてのボリュームのインスタンス UUID を書き留めておきます。これらの識別子は、後のマッピングおよび再同期操作にとって重要です。
SnapMirror関係を削除する前に、各ボリュームの最終スナップショットを取得して最新の状態を保存します。
SnapMirrorポリシーを文書化します。各ボリュームの関係に現在添付されているSnapMirrorポリシーを記録します。これは、後でSnapMirrorからクラウドへの再同期プロセス中に必要になります。
オブジェクトストアとのSnapMirror Cloud 関係を削除します。
新しいONTAPクラスタとの標準のSnapMirror関係を作成し、ボリュームを新しいターゲットONTAPクラスタに移行します。

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

移行後、 NetApp Tech Refresh チームは、保護を確立し、再同期の準備を整えるために次の手順が完了していることを確認します。

移行先のONTAPクラスタ内のすべての移行されたボリュームの新しいボリュームインスタンス UUID を記録します。
古いONTAPクラスタで使用可能だったすべての必要なSnapMirrorポリシーが、新しいONTAPクラスタで正しく設定されていることを確認します。

コンソールの システム ページで、新しいONTAPクラスタをシステムとして追加します。

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

SnapMirrorを実行してクラウドを再同期する

移行後、 NetApp Tech Refresh チームはSnapMirror to Cloud Resync 操作を実行し、新しく移行されたボリュームからクラウドバックアップを再開します。

コンソールの システム ページで、新しいONTAPクラスタをシステムとして追加します。
NetApp Backup and Recoveryボリュームページを参照して、古いソースシステムの詳細が利用可能であることを確認します。
NetApp Backup and Recoveryボリュームページから、バックアップ設定 を選択します。
- バックアップ設定ページで、[すべて表示] を選択します。
- 新しいソースの右側にある [アクション…] メニューから、バックアップの再同期 を選択します。
「システムの再同期」ページで、次の操作を行います。
1. 新しいソースシステム: ボリュームが移行された新しいONTAPクラスターを入力します。
2. 既存のターゲットオブジェクトストア: 古いソースシステムからのバックアップが含まれているターゲットオブジェクトストアを選択します。
再同期の詳細 Excel シートをダウンロードするには、[CSV テンプレートのダウンロード] を選択します。このシートを使用して、移行するボリュームの詳細を入力します。 CSV ファイルに次の詳細を入力します。
- ソースクラスターの古いボリュームインスタンスUUID
- 宛先クラスターからの新しいボリュームインスタンスUUID
- 新しい関係に適用されるSnapMirrorポリシー。

ボリュームマッピングの詳細のアップロード の下の アップロード を選択して、完了した CSV シートをNetApp Backup and Recovery UI にアップロードします。

再同期操作に必要なプロバイダーとネットワーク構成情報を入力します。
検証プロセスを開始するには、[送信] を選択します。

NetApp Backup and Recovery は、再同期対象として選択された各ボリュームが最新のスナップショットであり、少なくとも 1 つの共通スナップショットがあることを検証します。これにより、ボリュームがSnapMirrorから Cloud Resync 操作の準備が整っていることが保証されます。
新しいソースボリューム名や各ボリュームの再同期ステータスなどの検証結果を確認します。

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

ボリュームがSnapMirrorから Cloud Resync への操作の対象であり続けるようにするには、移行前のフェーズでSnapMirror関係を削除する前に、各ボリュームの最終スナップショットを作成します。これにより、データの最新の状態が保持されます。

再同期操作を開始するには、「再同期」を選択します。システムは最新の共通スナップショットを使用して増分変更のみを転送し、バックアップの継続性を保証します。
ジョブモニターページで再同期プロセスを監視します。