ONTAP Discussions

Migrating snapvault source.

Fabian1993
8,628 Views

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

1 ACCEPTED SOLUTION

GidonMarcus
8,500 Views

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 Robot LOL . 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

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

View solution in original post

9 REPLIES 9

GidonMarcus
8,582 Views

Fabian1993
8,563 Views

My Problem is, that the Scenario is:

 

Current      A SRC->B DST (Old Enviroment)


Desired     C SRC->D DST

 

 

GidonMarcus
8,551 Views

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

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

Fabian1993
8,540 Views

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
8,501 Views

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 Robot LOL . 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

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

GidonMarcus
8,286 Views

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

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK

MattS-NA
7,156 Views

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
7,110 Views

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
7,014 Views

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..

Gidi Marcus (Linkedin) - Storage and Microsoft technologies consultant - Hydro IT LTD - UK
Public