CIFS monthly snapshots

[mg]

Hello,

I'm looking to have a customer use SC to manage his CIFS snapshots and snapvaults.

I've been investigating the following concern but couldn't find a proper answer: is there a nice way to have monthly snapshots on Snapvault destination side without requiring to keep a monthly snapshot on the source?

Thanking you in advance,

Kind regards,

Michel

[peter_lehmann]

One of the "advantages" of SnapVault is, that the snapshots on the source and the destination can be "unrelated"...

In this case you can have the SnapShots on the source, like this:

source-filer> snapvault snap sched volname sv_nightly 7@mon-sat@23

source-filer> snapvault snap sched volname sv_weekly 5@sun@1

and then on the destination:

dest-filer> snapvault snap sched -x sv_volname sv_nightly 7@mon-sat@0

dest-filer> snapvault snap sched sv_volname sv_weekly 13@sun@2

For the monthly SnapShots you can use SC, or PM or PS or whatever the customer prefers...

Peter

[ktenzer]

Sure you can either use snapvault scheduler built into ONTAP, SC, or Protection Manager...take your pick!

Keith

[mg]

Sorry, I was not clear in my question.

The backup rules customer requires:

- From Mon to Fri, perform daily backups

- On Sat:

* if 1st Sat of the month, perform monthly backup

* if not 1st Sat of the month, perform weekly backup

In my SC config:

- I specify a retention for the SV source Filer based on daily and weekly policy

- I specify a retention for the SV destination Filer based on daily, weekly and monthly policy

When I run the config:

- if I choose daily or weekly policy, SC creates the proper snapshot on the SV source, perform the update and creates the proper snapshot on the SV destination

- if I choose monthly policy, SC fails because there is no "monthly" retention for SV source defined

@Peter: I know very well this setup but I don't want to have the SV schedule defined on the Filer. Also, I was looking for a way to update Snapvault destination prior to creating the monthly snapshot on the destination.

Update: after further thinking with my colleague Pierre, the idea would be the following:

- define daily and weekly in one config (config1); this config will create snapshot on primary, update SV and create snapshot on secondary

- define monthly in another config (config2); this config will create snapshot on secondary (kind of "snapvault snap sched") AND will call config1 with weekly policy as PRECMD

- Schedule config1 with policy daily from Mon to Fri

- Schedule config1 with policy weekly on every Sat except the first of the month (I will use x#y syntax in cron format to specify 2nd Sat of month, 3rd Sat of month, etc.)

- Schedule config2 with policy monthly on 1st Sat of the month

With that setup, when requesting monthly backup, a weekly backup will be performed as preamble, thus updating my snapvault relationship using weekly snapshots. Then immediately after, a monthly snapshot will be created that will capture the very recent update that has occured.

Do you think this is a valid setup?

Thanks,

Michel

[peter_lehmann]

Yep, sounds good.

[mg]

Hello,

I have a problem calling snapcreator with another profile/config. If I specify as PRE_NTAP_CMD something like "snapcreator.exe -config <something> ...", some parameters from the parent config and the child config conflict. For example, the command specified in PRE_NTAP_CMD in parent config seems to be called also when child config runs. This leads to some kind of infinite fork until execution timeout is reached.

If I run the 2 configs completly independently, there is no problem.

Is someone aware of that behavior please?

Thanks,

Michel

[ktenzer · Accepted solution]

Yes we dont recommend running SC from within SC for --action snap, lun_clon, vol_clone

The reason is SC sets all parameters in config to ENV and what happens is that gets inherited by PRE_NTAP_CMD which is SC running as action snap so you can get into looping issues.

If you are going to do this then use SC 3.6 since we fixed some issues with looping and in second config one run form within SC set all pre or post commands set in master config but not in child config to "echo test". This will then write over them so that the wrong commands arent run and just a harmless echo runs.

This is a bit complex though so again our recommendation is not to do this and run configs separate or create a wrapper script to chain things.

Regards,

Keith

[mg]

Thank you very much Keith, this is really the kind of answer I love to read: it gives more insight on what happens under the hood and comes with a solution as well 🙂

My setup is already based on 3.6 (I've upgraded to 3.6P1 yesterday due to internal scheduler issues fixed in P1), and I indeed faced this "infinite loop" behavior (tested with a script that does "start /wait" and I got DOS boxes popping again and again). The error message I got was unfortunately not listed in the documentation, so it would interesting adding it (it was error code scf-00103, and exit code from calling SC was 256).

Kind regards,

Michel

[ktenzer]

Ok yeah sorry about the infinite loop we did fix one that was known in 3.6 around ASUP messages so if you ran configs within configs it would loop if you hit error condition but this is definitely a bug we have not yet addressed or found.

QA doesn't test all the possibilities with the PRE/POST commands so that is how some of this got missed, we need to do a better job of covering those test cases which threads like this help us understand.

I will bring this up to engineering but this chould be fixed in SC 4.0 (when it comes out) which has a improved server architecture that provides much better insulation, we arent setting all config params to ENV variables.

I am glad you appreciate my candid response, I definitely dont try and sugar coat anything and my point is always inform user and understand what we could be doing better.

If you wouldnt mind sharing your config, just the stuff where you are calling SC within SC which causes infinite loop this would help. Again I wouldnt expect fix for this in SC 3.6 since we arent planning another patch unless we hit a critical issue without workaround. But this should work in 4.0 as I mentioned, we will test and ensure.

Keith

[mg]

Hello Keith,

In fact, there's no "infinite" loop as the agent timeout value seems to be taken into account to stop the process forking. So there is a safeguard...but before it triggers, snapcreator.exe processes keep on spawning.

I will provide you the configs in the coming days.

BTW, when is SC 4.0 due?

Kind regards,

Michel

[ktenzer]

March 2013 is when SC 4.0 is planned to release but there will be a community version available in next month or two

Keith