Subscribe

SMSQL SnapVault Fanout configuration

[ Edited ]

Hi there

 

I'm trying to get SMSQL 7.2 with SD 7.1.1 on cDot ontap 8.3GA to work in a configuration where we want to have two snapvault relationships from one primary source.

I have setup the XDP and Protection Policy to catch "Daily" and "Weekly" snapmirror-labels, but I have not setup any schedules on the VSM snapvaut relation, as it should of cause be pushed by SMSQL.

Sadly I cannot get both SV relations to update after a successful backup, and I am unsure is it is officially supported?

I have ofcause configured SD so it can use all 3 VSM's on the 3 different clusteres, and I have done the baselines.

No apparent errors in SMSQL's logs, and it does also update the first relation I created, but never the other one...  I have can manually do an update of the relation, and it transferes the updates ok...

One simple workaround could be to just setup a schedule on one or maybe even both the protection policies... 

Another workaround could be to execute a little powershell script at the end of the backu jobs, to make sure both relations update...

 

But I would like to know if it should infact be possible with two snapvault relations ?

 

Kind regards,

Heino

Re: SMSQL SnapVault Fanout configuration

Hi Heino,

 

I am also running SMSQL 7.2 with SD 7.1.1 on cDOT 8.2.3.  I have two clusters and have two SnapVault relationships running from one source.  I intend on using the first SnapVault relationship for SMVI backups and the second relationship for SMSQL backups.  I intend on using this configuration in order to split the number of snapshots being acumulated (SMVI SnapShots and SMSQL SnapShots).

 

My concern now is however that when I run an SMSQL job it updates both SnapVault relationships.  Additionally it also adds the SMSQL snapshots to the first relationship which completely goes against what I am trying to achieve in terms of spreading the snapshot burden across more volumes.

 

I hope that somebody sees this post and can answer both your question and also mine.