ONTAP Discussions

OnCommand Host Package Snapshot Naming

pd
3,079 Views

Hello...

SMVI/VSC have this nice behaviour, where the most recent snapshot has a static name like "mySMVI_Snapshot_recent" which then gets renamed at the next backup into a name with the timestamp. Using OnCommand HostPackage I can actually define a snapshot naming policy but alas the %T (Timestamp) is required in the snapshot name.

We have the requirement to actually pick up the snapshot from a backup software (currently no snapvault or NearStore available), but this is defeated by the fact, that thesnapshot names change with every backup. This results in the backup software not being able to find the correct path. With SMVI we just told the backup software to pick up a certain snapshot via NDMP and store that to tapes, but this requires a static name for those snapshots.

Is it possible to replicate this behaviour using OnCommand? If not, this would be a regression compared to SMVI. Most of our customers require a tape backup...

regards,

Patrick

1 ACCEPTED SOLUTION

smoot
3,079 Views

I was thinking more along the lines of scripting something to find the name of the snapshot copy you want to use as your backup source and sending that to your backup software.

ONTAP doesn't have a way to copy a snapshot. Renaming snapshots is the issue: when you do that, we don't have a reliable way for OnCommand to figure out that's what happened (as opposed to the original snapshot being deleted and a new one being created).

If the snapshot you're trying to back up really and truly is always the most recent snapshot on the volume and you're trying to do D2D2T, you could try just creating a new snapshot on the fly (with some fixed name), dumping that to tape, then deleting the snapshot. For that matter, you could implement this as a post-backup script and configure it as part of your protection policy. Since the only changes to the volume are because of SnapVault transfers, you're guaranteed the two snapshots have identical contents.

View solution in original post

3 REPLIES 3

smoot
3,079 Views

No, you cannot replicate this behavior. We understand this is a loss of functionality. If this is really a requirement that can't be worked around using our CLI or APIs, contact us and we can enter an enhancement request.

pd
3,079 Views

As any scripting solution would require renaming the OnCommand Snapshot to some constant name and then reverting that afterwards, when the next OnCommand Backup triggers it would be very difficult and involved to get that behaviour without confusing the hell out of OnCommand, or am I missing some obvious method? If the storage system would be able to "copy" a snapshot (make a snapshot available under another name) I could see the immediate solution. Using FlexClone one could do something like that, but then again not everyone has a flexclone license...

If you could file this as an RFE I would be very grateful. A quick survey of our customers using SMVI about three quarters of them rely on that behaviour for tape backups. The same problem also exists, when trying to create a tape backup from a SnapVault secondary.

I somehow cannot imagine that we are the first to have this requirement... o.O How do others solve that "Disk-to-Disk-to-Tape" Problem?

regards,

Patrick

smoot
3,080 Views

I was thinking more along the lines of scripting something to find the name of the snapshot copy you want to use as your backup source and sending that to your backup software.

ONTAP doesn't have a way to copy a snapshot. Renaming snapshots is the issue: when you do that, we don't have a reliable way for OnCommand to figure out that's what happened (as opposed to the original snapshot being deleted and a new one being created).

If the snapshot you're trying to back up really and truly is always the most recent snapshot on the volume and you're trying to do D2D2T, you could try just creating a new snapshot on the fly (with some fixed name), dumping that to tape, then deleting the snapshot. For that matter, you could implement this as a post-backup script and configure it as part of your protection policy. Since the only changes to the volume are because of SnapVault transfers, you're guaranteed the two snapshots have identical contents.

Public