2009-10-06 04:35 AM
I have filer1 as source and filer2 as destination. I'm using Protection Manager to mirror the data from filer1 to filer2.
I want to move the volumes from filer2 (filer2 is being decommissioned) to filer3 but keep the existing snapmirror relationships so that I do not have to rebaseline them (I don't want to do a level 0 backup).
How can I move the volumes so that I keep the snapmirror relationships and also keep Protection Manager managing the volumes and relationships.
2009-10-06 04:57 AM
Currenlty( untill DFM 3.8) this is not possible,Migrate from filer2----->filer3
with out rebaselining the relationship from filer1.
But soon you would be able to do.
We are working on to automate moving secondary volumes. If all goes well, it will be in the next release.
2009-10-06 08:25 AM
This is an interesting situation.. Will it be possible to completely mirror data from filer2 to filer3 and then rename[modify IP] filer3 as filer2? Will this work?
2009-10-06 08:47 AM
No, it won't work since the new volume will get a new "SID" and Protection Manager will recognize it.
I did a secondary volume migration in another aggreagte the following way:
- Manually VSM the destination volume to the new aggregate
- SM quiesce and break
- Manually resync the SM relationship with the primary controller
- remove the old seconfdary volumes/qtrees from the dataset
- import the manually resynced SM relationships as external relationship into the dataset
- remove old SnapMirror snapshots on primary and secondary
- try a "protect now"
In my case I had SnapVault relationships between the primary and the secondary controller. But it should also work with QSM or VSM.
If you have QSM or VSM Protection Manager is no longer aware of the backup history on the secondary volumes. So you have to delete the old snapshots manually until they are out-of-date. The new snapshots will be managed again from Protection Manager.
Hope this helps
2009-10-06 10:43 AM
But you would loose your backup version, on protection manger even though those snapshots exits on the volume.
As protection manger does not recognize or import older snapshots of a imported relationships as backup versions.
2009-10-06 01:26 PM
Thorsten's procedure should work fine.
Every time Protection Manager mirrors the volume from filer1 to filer3, we copy all the backup versions present on the source volume to the destination volume (now on filer3). When we detect that the volume on filer2 is deleted, we'll also delete all notion of backup versions on that volume. This works because we know the VSM destination is a carbon copy of the source volume.
This does not work for SnapVault and Qtree SnapMirror destinations, so if you move a backup destination, you need to manually manage the snapshots. We intend to fix that in an upcoming release.
So, we should retain and delete snapshots and backup versions properly. If it doesn't work, let us know (prefereably through NGS) and we'll fix it as a bug.
2009-10-06 10:46 PM
Is protection manager really worth all this trouble?
I have been using VSM/QSM/Snapvault for years using the CLI and I am happy with it. But moving to PM seems like giving away control and lost of freedom and will cause a lot of trouble in the short term.
2009-10-07 12:36 AM
PM is good because you have a centralized configuration, monitoring and alerting, which you don't have with cli commands.
But I agree with your question because PM still has a lot of "features" that don't make life easier. One of those is the base question of this thread. Hopefully there will be much improvement in a short time frame. I was in contact with Product Management and there will be some improvement with 4.0 which should come at the end of this year.