Subscribe

Migrating snapvault source.

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

Re: Migrating snapvault source.

hi

 

i believe that's the article you are after?

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

 

Gidi

Re: Migrating snapvault source.

My Problem is, that the Scenario is:

 

Current      A SRC->B DST (Old Enviroment)


Desired     C SRC->D DST

 

 

Re: Migrating snapvault source.

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

Re: Migrating snapvault source.

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?

Re: Migrating snapvault source.

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