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.
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.
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!
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.
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.
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).
[-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 -.