How to keep yearly snapshots, on a snapvault destination, in CDOT

[mdotten]

Hi All,

Was hoping I could get some help with this. I have a customer who needs to keep data in snapshots, on a snapvault destination, for greater than 1 year, and in some cases multiple years.

Now in 7-mode this was easy, you would schedule a snapshot to be taken of the destination volume whenever you wanted, and script it that way. NOW, in CDOT, you aren't able to take snapshots of a snapvault destination volume independent of the snapvault process.

I'm currently exploring the idea of snapshotting the source side, and sending a snapshot along via snapvault, but it's getting VERY complicated. My thought is , with such a big push to CDOT, there must be a fix or a solution that someone can think of for those customers that don't want to push their backups to tape, and have upwards of 7 year retentions. If such a solution exists already that someone can think of I would be incredibly grateful.

Any help would be MUCH MUCH appreciated!

Thanks very much!!!

Matt

[ekashpureff]

Matt -

It shouldn't be that complicated, or am I missing something in your question ?

SnapVault has always been about being able to retain Snapshot Copies on the destination for much longer than you retain them on the source.

I'd do this the same in Cluster Mode as in 7-Mode.

For an example:

Create an update policy on the secondary with '-name monthly' using the 'job schedule create' command.

On the source create a monthly snapshot policy with 'volume snapshot policy create' and use the 'snapmirror-label' parameter to specify a named label (monthly) for snapvault to use.

Use 'snapmirror policy create' on secondary to make a monthly vaulting policy.

Add a rule on the secondary to  retain the monthly snapshots with 'snapmirror policy add-rule' and 'snapmirror-label monthly -keep 120'.

See also the Data Protection Guide documentation:

https://library.netapp.com/ecmdocs/ECMP1366833/html/frameset.html

This would retain the monthly snapshots on the secondary for 10 years.

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff, Sr.

Independent NetApp Consultant, K&H Research http://www.linkedin.com/in/eugenekashpureff

Senior NetApp Instructor, IT Learning Solutions http://sg.itls.asia/netapp

(P.S. I appreciate points for helpful or correct answers.)

[aborzenkov]

I think it would be heplful if you explained why standard snapvault configuration is not suitable. So far it appears to do everything you need; the only downside is extra snapshot on source, but you need just one of them and can create as often as needed so it does not grow much.

[mdotten]

It may be just this simple Eugene, let me try this out and I'll get back to you. I was used to the 7-mode world perhaps, where I would just take an independent snapshot of the destination yearly via a cron job, and boom i had a yearly snapshot schedule. This seems like it would work though! Let me test it and get back to you! Thanks for the quick reply!

[mdotten]

So supposedly this option was given to the customer and they rejected it since they claim it to still be too limiting. I guess they want to have a 0 retention on the source.

[ekashpureff]

Matt -

I think it can still be done, using '-snapmirror-label' on a snapshot on the source.

See 'Preserving a Snapshot copy on the primary source volume' in the Data Protection Guide documentation.

Example:

clust1::> volume snapshot modify -volume vol1 -snapshot snapappa  -snapmirror-label exp1

Remove the label after the transfer and delete the source snap on the primary.

It's the mechanism for vaulting application consistent snapshot copies.

I hope this response has been helpful to you.

At your service,

Eugene E. Kashpureff, Sr.

Independent NetApp Consultant, K&H Research http://www.linkedin.com/in/eugenekashpureff

Senior NetApp Instructor, IT Learning Solutions http://sg.itls.asia/netapp

(P.S. I appreciate points for helpful or correct answers.)

[aborzenkov]

OK, I apologize - I apparently misunderstood how cDOT SnapVault works. As there is just a single schedule which transfers everything since last base snapshot, my idea won’t really work. I was a bit confused by example in documentation that suggests, that somehow it is possible to transfer only some of snapshots. I do not see how it is possible.

[aborzenkov]

You do not even need to set label - you can simply do “snapmirror update -source-snapshot”. Downside is, it makes scripts more complicated - create snapshot, start transfer, monitor for successful transfer, delete snapshot.

[jont]

Here is one solution to the problem:

Suppose the goal is to create an archive of ten yearly Snapshots in a SnapVault archive.

1. Create a yearly schedule and assign it to the (pre-existing) Snapshot policy for the primary volume:

primary:: > job schedule cron create -name 1Jan -minute 0 -month January -hour 0 -day 1

primary:: > snapshot policy add-schedule -vserver svm_prod -policy snap_policy_1 -schedule 1Jan -count 1 -snapmirror-label yearly

2. Create a rule to archive the yearly snapshot to the (pre-existing) SnapVault destination and keep 10 copies:

secondary:: > snapmirror policy add-rule -vserver svm_vault -policy snapmirror_policy_1 -snapmirror-label yearly -keep 10

However, this will leave the yearly Snapshot on the source for the entire coming year, which might not be what you want. The solution is to have a second Snapshot schedule (such as daily) with its own snapmirror-label (such as daily), which would also be archived to SnapVault. This way, first the yearly-label Snapshot will be archived and become the baseline for the next SnapVault update - which occurs the very next day when a daily-label Snapshot is archived. Once that happens, the yearly Snapshot can be deleted via script (or be left to grow until it is deleted by a snapshot autodelete policy).

[DataOntaper]

you can also add a new "custom rule" to the snapmirror poliy to do that(Form 9.5+ I belive)

secondary:: > job schedule cron create -name 1Jan -minute 0 -month January -hour 0 -day 1

secondary:: > snapmirror policy add-rule -vserver svm_vault -policy snapmirror_policy_1 -snapmirror-label yearly -keep 10 -schedule 1Jan

[-schedule <text>] - Snapshot Copy Creation ScheduleThis optional parameter specifies the name of the schedule associated with a rule. This parameter is allowed only for rules associated with SnapMirror policies of type vaultor mirror-vault. When this parameter is specified, Snapshot copies are directly created on the SnapMirror destination. The Snapshot copies created will have the same content as the latest Snapshot copy already present on the SnapMirror destination. Snapshot copies on the source that have a SnapMirror label matching this rule will not be selected for transfer. The default value is -.

Note: You define and name a schedule using the job schedule cron create command.