Migrating snapvault source.

[Fabian1993]

Dear Community,

does somebody know a usefull Process to migrate existing Snapvault realationships from a old enviroment to a new enivroment, is it possible to bypass a new intial Copy?

Old:

9.1 4 Node + 2 Node Backup

NEW

9.3 4 Node + 2 Node Backup

Regards

Fabian

[GidonMarcus]

hi

i believe that's the article you are after?

https://kb.netapp.com/app/answers/answer_view/a_id/1029919

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe... - updated link OCT 2020

Gidi

[Fabian1993]

My Problem is, that the Scenario is:

Current      A SRC->B DST (Old Enviroment)

Desired     C SRC->D DST

[GidonMarcus]

UPDATE 6/9/18 NetApp updated the KB:

https://kb.netapp.com/app/answers/answer_view/a_id/1029919

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe... - updated link OCT 2020

The KB now support the mechanism that is described here with MirrorAllSnapshots, confirm you can also migrate the sources, and added another workaround to re-enable the deprecated DP.

hi.

Actually. you can't do that KB either. as you can't use DP between these two versions (maybe XDP with MirrorAllSnapshots would also work):

https://library.netapp.com/ecmdocs/ECMLP2492508/html/GUID-A8F2BEFF-9A84-4C75-B8ED-93DD6098C799.html

 i think that if you did had compatible version you could have also move the source in the same way. as long as the two platform has common snapshot it should work (that's why i assume XDP with MirrorAllSnapshots may work).

Gidi

[Fabian1993]

Hi Gidi,

after I do that, what is about my Releationship, I have to resume it on the new Systems without any new Baseline copy, there is no way right?

[GidonMarcus · Accepted solution]

UPDATE 6/9/18 NetApp updated the KB:

https://kb.netapp.com/app/answers/answer_view/a_id/1029919

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe... - updated link OCT 2020.

The KB now support the mechanism that is described here with MirrorAllSnapshots, confirm you can also migrate the sources, and added another workaround to re-enable the deprecated DP.

Hi

i had a free evening so i tried to do something similar to this KB but using XDP with MirrorAllSnapshots instead of DP as the KB suggest.

and i have a good news IT WORKED . is it supported? does it have limitation? would it break on version difference?  i have no idea - and suggest you to try it on your system before moving the workload and perhaps have NetApp verifying it as supported.

i will send a link to this post as comment to the KB. and as DP going to be deprecated in the next release. this seems to be a good replacement.

Attaching the output. i did it all on a single 9.1P6 cluster and a single SVM with two nodes (node1 as the source for the old and new SV's and Node2 as the Destination for the old and new SV's).

All the objects are technically independent..  so yes - in your environment each volume would be on dedicated cluster. and i assume different versions (i only have one cluster to test on)

in short: (you can also find these comments in the attachment):

#Creating the "existing scenario", SRC and DST volumes, a file in the SRC volume and few snapshots that are snapvaulted across

#Creating the Volumes on the "new" SV's SRC and DST clusters, And mirror in each "site" from it's old to new cluster using MirrorAllSnapshots and XDP(not DP as in the KB)
#Once users ready to move to the new clusters - release/break all 3 relationships to make the new source writable (you can start only with that one if you wish)

#Take the old clusters volumes offline to make sure no one writes to them
#Create and resync the actual SV relationship (yes, without running baseline on the WAN)

#Verify that all the snaps exists and the test file is intact 

Good luck

Gidi

[GidonMarcus]

FYI.

Following my comments for the KB, i got an email saying that NetApp updated the KB: https://kb.netapp.com/app/answers/answer_view/a_id/1029919

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe... - updated link OCT 2020

The KB now support the mechanism that is described here with MirrorAllSnapshots including the support of migration to more recent Ontap versions, confirms you can also migrate the source volume, and added another workaround to re-enable the deprecated DP option.

Gidi

[MattS-NA]

Old post, but still one of the first to show up in google results.  Took me a while to find this so here is the current link: 

https://kb.netapp.com/Advice_and_Troubleshooting/Data_Protection_and_Security/SnapMirror/How_to_migrate_a_SnapMirror_XDP_destination_volume_to_a_diffe...

[renton]

All links for KB articles mentioned except the recent link added by MattS-NA are dead.

Still no information found for migrating a SnapMirror source Volume to a different Cluster.

[GidonMarcus]

In the test I did at the time you can see I moved both the SRC and DST and the KB at the time was still talking only about the DST - so I reckon it's a document issue rather a technical limitation..

I'll update the links on this thread now..