SnapVault Monthly Replication

[EDWIN_LAGUNI]

Hi Seniors,

I hope someone could assist a newbie like me. Basically what we are trying to do is schedule a monthly snapvault, have the monthly snapshot replicated from primary to the secondary filer, and have an actual copy of the monthly snapshot in the secondary filer - all of these outside Protection Manager. I know there are a few posts about this, notably:

https://communities.netapp.com/thread/17188

Have tried this, it creates a monthly snapshot on the primary filer, but on the secondary it updates the base snapshot instead of replicating the monthly snapshot from primary filer to the secondary filer. On the secondary filer, I don't see any monthly snapshot, but the base snapshot got updated in time the script was ran.

https://communities.netapp.com/thread/7868

Admittedly, I haven't tried this option but it looks too manual for me.

Helpful suggestions would be very much appreciated!

[mwalters]

Seniors eh.....now you're aging me 🙂

I assume you are talking ONTAP in 7-mode.   You have spotted the trick suggested by RMHarwood to get the monthly snapshots on the primary:

1. On filer: snapvault snap sched <srcvol> sv_monthly 6@-
2. On management host: ssh filer "snapvault snap create <srcvol> sv_monthly"
3. Schedule the ssh to run once a month.

What you need to do is have a transfer schedule on the secondary to pull those specific snapshots across.   

I think the following should work (others may correct me!)

On the secondary, you could check at 6am every Saturday  for them with something like:

1. snapvault snap sched -x <dest-vol> sv_monthly 52@sat@6

Then do your snapvault start (eg "snapvault start -S srcfiler:/vol/<srcvol>/<srcqtree> /vol/<dstvol>/<dstqtree>") and get things chugging along 🙂

(I *think* you would put 52 simply to ensure you would get 12 monthly snapshots - if there was no change (which would be the case for all but the first week in the month) then there would be no data pulled across.....which is why I put I *think* - it may be that 12 would work, don't have a system - & 12 months - to check....right now!!)

Or you may be able to remove the -x option (which implies "transfer" and simply use your management host to also trigger a transfer by triggering a "snapvault update /vol/<sourcevol>/<srcqtree>" from the *secondary* filer to grab the monthly.....

Hope this helps (& indeed works....scraping some ancient knowledge here!!)

Mike

[EDWIN_LAGUNI]

Hi Mike,

Thank you for taking the time to reply to my post/question.

However, your suggestion is exactly what I have in a simple script that a server runs monthly (via task scheduler). Like what you mentioned above, we have:

1. filerA: snapvault snap sched <srcvol> sv_monthly 3@-

2. filerB: snapvault snap sched -x <dstvol> sv_monthly 3@-

Script:

1. filerA: snapvault snap create <srcvol> sv_monthly

2: filerB: snapvault update /vol/<dstvol>/<dstqtree>

It only updates the base snapshot in filerB:

Out of curiosity, I tried to start another SV  snapvault start -S vsim1:/vol/VolOne/q1 /vol/sv_VolOne/q2 <-------- used q1 initially; didn't copy over sv_monthly to <dstvol>/<dstqtree>

Please help -_-

[mwalters]

Hmmm....looks like you spotted my error there - yes, you should be able to run "snapvault update /vol/<destvol>/<destqtree>" from the *secondary* filer to grab the monthly.....which looks like what you tried.  

This is all VSIM's ?

What ONTAP version ?

There were some changes in how it behaved - pre 7.3.2 was a bit different to post, and I *think* changed again to a choice post 7.3.5.  TR3487 explains this a bit around preserving ACS snapshots: it mentions the need to set:

6.2.2 Update from a named snapshot copy

Starting with Data ONTAP 7.3.5 (with the exception of Data ONTAP 8.0 7-Mode) the following option can be set on system_B such that the update will fail if the named Snapshot copy does not exist on the VSM destination.

options snapvault.snapshot_for_dr_backup named_snapshot_only

Not sure if this is the answer, or just a distraction......beyond this, I would recommend a call to support for some more experienced eyes!

cheers

Mike