#Data migration strategy for Cloud-backed volumes

1 messages · Page 1 of 1 (latest)

hot star
#

Currently: a 2-node per site A400 MetroclusterIP, which each using Storage GERD as a cloud tier (second site GERD serves the site1 mirrors). There are a couple volumes using ~6TB, and one volume using 78TB in the cloud tier.

Working on plan to relocate a 4-node per-site MCIP (each site 2x A800+2xC800) from a location cust is shutting down to replace the A400's. And sending the A400's with their empty disks to a 3rd site to be used.

I was thinking about just joining the 800's to the existing A400 clusters, and using vol move to migrate the data off the A400 drives, move lifs etc.. and then remove the 400's from the cluster. But won't have an aggr big enough to hold a fully inflated 79TB vol.

Is there a way to move that vol to a different aggr without inflating the cloud tier? Is there a doc I should be reading? 😁

frosty pivot
#

There's something called "optimized move": If both source and destination aggrs are attached to the same cloud tier bucket it will only move the blocks locally in the performance tier and not the ones in the cloud tier. You also need to make sure you're not changing the tiering policy with your vol move. There are also other requirements.

https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/Why_does_volume_move_copy_cloud_tiered_data_on_releases_9.6_and_above

https://kb.netapp.com/on-prem/ontap/Ontap_OS/OS-KBs/How_to_determine_if_a_volume_move_is_optimized

hot star
#

Thanks, Oggy! Client might just move that data somewhere else (just an archive), and remove the SG altogether. But I wanted to be prepared for any direction they choose.

tulip birch
#

make sure you're on a reasonably-recent verision of ONTAP though (9.14.1 or 9.15.1, latest P release) as there were a few nasty bugs with optimized volume move in the past