Protection Manager SnapVault source and destination member in same aggregate

[awells]

Hello.  Is it possible configure Protection Manager (NMC v 3.1) to manage SnapVault relationship where the source and destination member are in the same aggregate?  If yes, how? 

I am attempting to perform a Primary Data -> Mirror -> Backup protection policy on a dataset at a DR location where storage is constrained and there is only one aggregate (currently a storing destination SnapMirror volumes) .  I thought this might be accomplished by changing a dfm option like dpMaxFanInRatio but even after increasing this value Protection Manager is still reporting an error and will not proceed.

Thank you,

-Adrian

[awells]

Still working on this... from an ONTAP perspective this is supported - having a SV relationship where the source and destination are in the same aggregate.  PM does not seem to work the same and does not permit creating two different Data Resource Pools to the same aggregate.

[adaikkap]

Hi,

     In true sense its not protecting any data. As the aggr hosting the source and destination volumes fail all data is lost. Also it gives false impression to customer so we prevent SV relationship within the same aggr to avoid giving users a false impression that their data is protected from an aggr failure.

But I can argue as follow.s

True from a physical perspective but a separate copy also protects from logical corruption, so there is value in this, albeit not optimal.The customers view is they have limited resources and would rather ace some protection than none at

all,also they are able to set this up from the CLI so would like our management tools not to place restrictions on how they use our products"

BTW why do you want to do this ?

Regards

adai

[awells]

Thank you for the reply.  Based on your reply, I understand SnapVault within the same aggregate is not supported and there is no way to override this?

Your argument for SnapVault within the same aggregate is the point of view that the customer is coming from - they want to:  1) provide logical corruption - either system or human error - as it is better than nothing, and 2) this is supported from the CLI so why not support it from the management tool.

In this case the the destination system's aggregate was spanned over all the disks and there is no easy way (no free storage space) to resize aggregate and create a second aggregate (as I gather it is necessary to backup, destroy, and rebuild the aggregate).

Thank you,

-Adrian

[mdvillanueva]

Hi Adai,

Thanks for that reply, how about this scenario?

1. For Snapvault, can I have primary on AggrA and the secondary on AggrB, but on the same filer?

2. For SnapMirror, can the source and destination be on the same aggregate?

3. For SnapMirror, can the source be in AggrA and destination in AggrB, but on the same filer?

Thanks,

Maico