Skip to main content
BlueXP backup and recovery
All cloud providers
  • Amazon Web Services
  • Google Cloud
  • Microsoft Azure
  • All cloud providers

Migrate volumes using SnapMirror to Cloud Resync with BlueXP backup and recovery

Contributors amgrissino
PDFs

The SnapMirror to Cloud Resync feature in BlueXP backup and recovery streamlines data protection and continuity during volume migrations in NetApp environments. When a volume is migrated using SnapMirror Logical Replication (LRSE), from one on-premises NetApp deployment to another, or to a cloud-based solution such as Cloud Volumes ONTAP or Cloud Volumes Service, SnapMirror to Cloud Resync ensures that existing cloud backups remain intact and operational.

This feature eliminates the need for a time-consuming and resource-intensive re-baseline operation, enabling backup operations to continue post-migration. This feature is valuable in workload migration scenarios, supporting both FlexVols and FlexGroups, and is available starting with ONTAP version 9.16.1.

Note This feature is available starting with BlueXP backup and recovery version 4.0.3 released May 2025.

By maintaining backup continuity across environments, SnapMirror to Cloud Resync enhances operational efficiency and reduces the complexity of hybrid and multi-cloud data management.

NOTE To switch to and from BlueXP backup and recovery workloads, refer to Switch to different BlueXP backup and recovery workloads.

Before you begin

Ensure that these prerequisites have been met:

  • The destination ONTAP cluster must be running ONTAP version 9.16.1 or later.

  • The old source ONTAP cluster must be protected using BlueXP backup and recovery.

  • The SnapMirror to Cloud Resync feature is available starting with BlueXP backup and recovery version 4.0.3 released May 2025.

  • The latest backup in the object storage must be the common snapshot across the old source, the new source, and the object store. The common snapshot cannot be older than the latest snapshot that is backed up to the object store.

  • Both the snapshot and SnapMirror policies, which were used on the older ONTAP must be created on the new ONTAP cluster before starting the resync operation. If any policy is going to be used in the resync process, then that policy must also be created. The Resync operation does not create the policies.

  • Ensure that the SnapMirror policy that is applied to the migration volume SnapMirror relationship includes the same label that the cloud relationship uses. To avoid issues, use the policy that governs an exact mirror of the volume and all snapshots.

Note SnapMirror to Cloud Resync after migrations using SVM-Migrate, SVM-DR, or Head Swap methods are not currently supported.

How BlueXP backup and recovery SnapMirror to Cloud Resync works

If you complete a technical refresh or migrate volumes from one ONTAP cluster to another, it's important that your backups continue to work without interruption. BlueXP backup and recovery SnapMirror to Cloud Resync helps with this by ensuring that your cloud backups stay consistent even after a volume migration.

Here's an example:

Imagine you have an on-premises volume called Vol1a. This volume has three snapshots: S1, S2, and S3. These snapshots are like restore points. Vol1 is already being backed up to a cloud object store endpoint using SnapMirror to Cloud (SM-C). However, only S1 and S2 have been backed up to object store so far.

Now, you want to migrate Vol1 to another ONTAP cluster. To do this, you create a SnapMirror Logical Replication (LRSE) relationship to a new cloud volume called Vol1b. This transfers all three snapshots—S1, S2, and S3—from Vol1a to Vol1b.

After the migration is complete, you have the following setup:

  • The original SM-C relationship (Vol1a → Object store) is deleted.

  • The LRSE relationship (Vol1a → Vol1b) is also deleted.

  • Vol1b is now your active volume.

At this point, you want to continue backing up Vol1b to the same cloud endpoint. But instead of starting a full backup from scratch (which would take time and resources), you use SnapMirror to Cloud Resync.

Here's how the resync works:

  • The system checks for a common snapshot between Vol1a and Object store. In this case, both have S2.

  • Because of this shared snapshot, the system needs to transfer only the incremental changes between S2 and S3.

This means only the new data added after S2 is sent to object store, not the entire volume.

This process avoids re-sending data that's already backed up, saves bandwidth, and ensures that your backup chain continues smoothly after migration.

BlueXP backup and recovery SnapMirror to Cloud Resync

Procedure notes

  • Migrations and tech refreshes are not performed using BlueXP backup and recovery. They should be carried out by a professional services team or a qualified storage administrator.

  • A NetApp migration team is responsible for creating the SnapMirror relationship between the source and destination ONTAP clusters to facilitate volume migration.

  • Ensure that the migration during a tech refresh is based on SnapMirror-based migration.

How to migrate volumes using SnapMirror to Cloud Resync

Migrating volumes using SnapMirror to Cloud Resync involves the following major steps, each described in more detail below:

  • Follow a pre-migration checklist: Before starting the migration, a NetApp Tech Refresh team ensures the following prerequisites are met to avoid data loss and ensure a smooth migration process.

  • Follow a post-migration checklist: After the migration, a NetApp Tech Refresh team ensures the following steps are completed to establish protection and prepare for the resync.

  • Perform a SnapMirror to Cloud Resync: After the migration, a NetApp Tech Refresh team performs a SnapMirror to Cloud Resync operation to resume cloud backups from the newly migrated volumes.

Steps to migrate volumes using SnapMirror to Cloud Resync

Follow a pre-migration checklist

Before starting the migration, a NetApp Tech Refresh team ensures the following prerequisites are met to avoid data loss and ensure a smooth migration process.

  1. Ensure all volumes that are to be migrated are protected using BlueXP backup and recovery.

  2. Record volume instance UUIDs. Write down the Instance UUIDs of all volumes before starting the migration. These identifiers are crucial for mapping and resync operations later.

  3. Take a final snapshot of each volume to preserve the latest state, before deleting any SnapMirror relationships.

  4. Document SnapMirror policies. Record the SnapMirror policy currently attached to each volume's relationship. This will be needed later during the SnapMirror to Cloud Resync process.

  5. Delete the SnapMirror Cloud relationships with the object store.

  6. Create a standard SnapMirror relationship with the new ONTAP cluster to migrate the volume to the new target ONTAP cluster.

Follow a post-migration checklist

After the migration, a NetApp Tech Refresh team ensures the following steps are completed to establish protection and prepare for the resync.

  1. Record new volume instance UUIDs of all migrated volumes in the destination ONTAP cluster.

  2. Confirm that all required SnapMirror policies that were available in the old ONTAP cluster are correctly configured in the new ONTAP cluster.

  3. Add the new ONTAP cluster as a working environment in the BlueXP canvas.

    Note The volume instance UUID should be used, not the volume ID. The volume instance UUID is a unique identifier that remains consistent across migrations, while the volume ID may change after migration.

Perform a SnapMirror to Cloud Resync

After the migration, a NetApp Tech Refresh team performs a SnapMirror to Cloud Resync operation to resume cloud backups from the newly migrated volumes.

  1. Add the new ONTAP cluster as a working environment in the BlueXP canvas.

  2. Look at the BlueXP backup and recovery Volumes page to ensure that the old source working environment details are available.

  3. From the BlueXP backup and recovery Volumes page, select Backup Settings.

    • Within the Backup Settings page, select View all.

    • From the Actions …​ menu to the right of the new source, select Resync backup.

  4. In the Resync Working Environment page, do the following:

    1. New source working environment: Enter the new ONTAP cluster where the volumes have been migrated.

    2. Existing Target Object Store: Select the target object store that contains the backups from the old source working environment.

  5. Select Download CSV Template to download the Resync Details Excel sheet. Use this sheet to enter the details of the volumes to be migrated. In the CSV file, enter the following details:

    • The old volume instance UUID from the source cluster

    • The new volume instance UUID from the destination cluster

    • The SnapMirror policy to be applied to the new relationship.

  6. Select Upload under the Upload Volume Mapping Details to upload the completed CSV sheet into the BlueXP backup and recovery UI.

    Note The volume instance UUID should be used, not the volume ID. The volume instance UUID is a unique identifier that remains consistent across migrations, while the volume ID may change after migration.

  7. Enter provider and network configuration information required for the resync operation.

  8. Select Submit to start the validation process.

    BlueXP backup and recovery validates that each volume selected for resync is the latest snapshot and has at least one common snapshot. This ensures that the volumes are ready for the SnapMirror to Cloud Resync operation.

  9. Review validation results including the new source volume names and the resync status for each volume.

  10. Check volume eligibility. The system checks if the volumes are eligible for resync. If a volume is not eligible, it means that it isn't the latest snapshot or no common snapshot was found.

    Important To ensure that volumes remain eligible for the SnapMirror to Cloud Resync operation, take a final snapshot of each volume before deleting any SnapMirror relationships during the pre-migration phase. This preserves the latest state of the data.

  11. Select Resync to start the resync operation. The system uses the latest and common snapshot to transfer only the incremental changes, ensuring backup continuity.

  12. Monitor the resync process in the Job Monitor page.