2013-03-01 01:22 AM
I was using a policy "Remote Backup"only to do backup of OSSV clients, but then I wanted to add a mirror to a DR site.
I followed the solution proposed in a discussion to modify the policy "Backup then Mirror" to remove the Primary Backup.
I've applied the new Protection Policy to the backup, but the Conformance fails as PM only provisions a volume of 10 GB on the mirror.
The relationship creation fails because the destination doesn't meet the required size.
Did I miss something?
2013-03-01 01:45 AM
Couple of questions before I can give you some solutions.
Are you running OCUM 5.1 ?
Is the option dpDynamicSecondarySizing turned on/enabled ?
Do you have Other relationship like SV/QSM or VSM in your Environment ?
2013-03-01 02:56 AM
Thanks for helping on this.
- It is OCUM 5.1
- dpDynamicSecondarySizing is turned on:
[root@oncommand ~]# dfm options list | grep dpDynamicSecondarySizing
- Yes, I already use other SV/QSM or VCM relations. I use always "Back then Mirror" for CIFS, SnapManager for Exchange, etc...
Thank you again,
2013-05-17 03:54 AM
The reason is in case of dynamic Secondary sizing it looks like we are using the projected size(the value of the options pmOSSVDirSecondaryVolSizeMb) and not the actual size of thesnapvault destination volume for Volume SnapMirror Destination volumes.
For OSSV destination volume we always create aggr size volume if we have free space as per the value of the option pmOSSVDirSecondaryVolSizeMb.
Can you set the value of this options to the size of the secondary volume created for OSSV destination volume ?
BTW I have created bug711018 for the same can you create a case and add to it ?
2013-05-21 01:33 AM
Thanks for your reply.
I have opened case 2004149517 regarding this issue.
Dror, the escalation engineer has replied:
As we saw, we are hitting bug 677951 which causes DSS to provision Volume SnapMirror volumes in a wrong size.
This bug does not yet have a fix, you can read some more about it here - https://communities.netapp.com/message/105168#105168
While we work on a fix in next version, we have tried implementing a workaround to get backups working in your environment.
We have created the VSM volume manually from Data OnTap, and then told Protection Manager to use the volume we created for the backup.
So what we have here is a bug in OnCommand 5.1 that is causing OSSV Mirror part to choose wrong size for the destination, which later on fails as the volume was created too small.
What I did to workaround is to create the SnapMirror destination volume manually, with 16tb (space reservation is off so only occupied space will really be allocated).
Then I changed the resource pool config in the mirror node of the backup (on the dataset edit window) to the physical volume that I created.
Then I conform the Dataset so it will create the Volume SnapMirror relationship.
For now the issue has been solved for the customer.
Does your bug # also link to the same problem ?