2012-09-26 08:37 PM
I have a customer that needs to implement a multi-step protection policy. He doesn't have a lab to test this. Here's the scenario:
We made a small test volume to verify that the policy would properly set up the relationships and it did. His existing relationships are too large to test.
Primary (SnapMirror)---> DR Mirror (SnapVault)---> Vault
Primary (SnapMirror)---> DR Mirror (SnapMirror created via command line)
What can we expect?
2012-09-26 10:58 PM
Define your dataset with storage service assigned (DR Mirror then backup), import SM relation via data/external relations/import and choose SM as protection policy.
During next conformance, the SV relation will be create, so it will take the existing relationship and add the Vault.
2012-10-02 09:32 AM
Be aware of multiple limits which are not written in the fat client code of dfpm. All limits like different aggr- types, netapp OS types etc. are not checked and no exception handling. Your case source Ontap 8.0x 64bit aggr > 32 bit ist not supported (see DPG/Admin Guide). You did chose DR Mirror in dfpm. This will produce a volume snap mirror async mirror on command line therefore the mirroring between 64/32 bit is not supported. Qtree SM would be supported as logical replication.
In your case you need to select a DR Backup Policy where is creating on command-line Netapp a qtree snap-mirror replication async. The difference to a DR Mirror (Volume Snap Mirror) the Backup DR Mirror Policy is creating Qtree Snap- Mirror like sourcefiler:> /vol/source/- in case of whole volume SM. I know this is absolutely not clear if you are going to select different policies. Be aware if you are using
Policies in dfpm and effective creating Snap's on Filer
DR Mirror = Volume Snap Mirror like sourcefiler:vol1 > targetfiler:vol1
DR Backup = Qtree Snap Mirror like sourcefiler:/vol/vol1/- (whole volume) or source filer:/vol/vol1/q1 > targetfiler:/vol/vol1/q1
Backup = Qtree Snapvault basically same as DR Backup but Snap Mirror can be writable this would never possible with snapvault therfore there is no "DR Capable" flag in dfpm but if you change in dfm option set pmQSMBackupPreferred=No then QSM is used everytime.
You need to configure a empty dataset (no source, no target included)
You add then a protection policy Policy = DR Mirror & DR Backup or just Backup (but you need to be secure that both aggr types source/dest are same bit 32/32 64/64
Only after you added to the emptyDataset desired backup Policy DR Mirror/Backup you can import external relationship. (But again need same bit #nr)
Be aware all existing snapshots are not imported and even there still exist on vol’s there are not shown in dfpm. Only dfpm backups are shown. dfpm creates as well own additional snapshots (at least 2 x ) and you need to purge/delete older snapshots manually.
2012-10-05 06:43 AM
This import will work fine, as during import we don't check for the volume block types. Pls find my response inline to your questions.
1.Will Protection Manager even attempt the import?
Yes, as during import we don’t check for block types.
- If it does, will it:
- take the existing relationship and add the Vault?
Yes, it will accept the mirror and create the vault if it’s already not created
- Rebuild the entire relationship end-to-end, including new volumes and rebaselining?
It will not rebuild the entire relationship.