ONTAP Discussions
ONTAP Discussions
Hello here,
i'm trying to migrate a few snapvaulted volumes from one aggregate to another (32-b aggregate each) in order to gain some space, all that being on the same filer (Data onTAP 8.1.2 7-mode).
Here's what i tried with a test volume :
1 - Snapvault relation stop : snapvault stop -f vault_filer:vol_path
2 - Volume move : vol move start srv_vol destination_aggr
3 - Snapvault relation start : snapvault start -S src_filer:/vol/vol_name/q.xxx /vol/vol_name/q.xxx
My problem here was that right after i restarted my snapvault relation, i lost all my snapshot history (which was here when i did the vol move). All i had left was a "ndvm_final_xxxxxx" snapshot once i started back the SV relation.
Obviously my concern here would be to be able to do that without loosing any snapshot.
After some research i saw that i could be using snapmirror instead, but that might require to create a new volume... ? I'm a bit confused and could need some light here.
Thank you guys.
Regards
Solved! See The Solution
"snapvault stop" deletes the qtree on the destination, don't do this if you don't want to re-baseline.
try the method Paul suggested, i.e. snapmirror you SV secondary volume into another volume. The only thing you need to do afterwards is snapmirror break and "snapvault start -r" (which updates the snapvault database and resyncs with the source). Simply renaming the volumes will not work as the SV database stores the volume ID (which changes after snapmirror)
So:
snapvault quiesce ...
snapmirror initialize... update...
snapmirror break
snapvault start -r ....
-Michael
Try this instead:
1) SnapMirror the SnapVault target to a new volume on the target aggregate, once that completes:
2) Stop the SnapVault relationship
3) Update the SnapMirror relationship
4) Quiesce and then break the SnapMirror
5) Rename the orginal SnapVault target volume (add a '_old' at the end perhaps)
6) Rename the SnapMirror target volume to the same name as the original SnapVault target volume
7) Start the Snapvault relationship
Let me know if this works better for you.
See answer below, problem here was the part about stopping the snapvault relationship.
Anyway thank for your help!
Gald to see there's some devoted people here ready to help
"snapvault stop" deletes the qtree on the destination, don't do this if you don't want to re-baseline.
try the method Paul suggested, i.e. snapmirror you SV secondary volume into another volume. The only thing you need to do afterwards is snapmirror break and "snapvault start -r" (which updates the snapvault database and resyncs with the source). Simply renaming the volumes will not work as the SV database stores the volume ID (which changes after snapmirror)
So:
snapvault quiesce ...
snapmirror initialize... update...
snapmirror break
snapvault start -r ....
-Michael
Thank you for your feedback.
After further research that's what i figured...
I was missing the part about this snapvault stop / quiesce thing.
Many thanks!
Regards