Importing Existing SnapMirror Relationship into Protection Manager

[bachman]

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:

• Controllers running DOT 8.0.2P1.
• OnCommand Unified Manager 5.0.2

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.

Dataset Policy

Primary  (SnapMirror)--->  DR Mirror  (SnapVault)---> Vault

• DR Mirror has a dedicated resource pool, 2 aggrs, 1 64-bit, 1-32 bit
• SnapVault  has dedicated resource pool, 1 aggr, 64-bit

Existing Relationship

Primary  (SnapMirror)--->  DR Mirror     (SnapMirror created via command line)

Questions:

1. Will Protection Manager even attempt the import?
2. If it does, will it:
   1. take the existing relationship and add the Vault?
   2. Rebuild the entire relationship end-to-end, including new volumes and rebaselining?

What can we expect?

Phil

[francoisbnc]

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.

francois

[hondasuschi]

Generall:
===========
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.

Your Case
=========
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.

[adaikkap]

Hi Phil,

      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.

Regards

adai