SnapManager for SQL and SMVI “Recent” Snapshot Naming Bug

NetApp pushes its SnapManager software as the answer for backing up Exchange (SME), SQL (SMSQL), Oracle, SharePoint, and VMware virtual infrastructure (SMVI). It’s not without its faults, however, and I came across a pretty nasty one when first implementing SMSQL with the objective of eventually sending these backups off to tape.

Coupled with the bug that I will get to soon, NetApp’s support team seems to have a communications problem. I’ve talked to various engineers on this, only to be told that this was the first they’ve heard of it. Anyway, here’s how the problem manifests itself:

When creating a backup using SMSQL, one of the backup options is naming convention. You can choose between generic (which appends a “_recent” suffix to the backup name) and a timestamp, which gives each backup a unique name based on the time it was taken. The logic in the generic choice is that you always know what your most recent backup’s name will be. Which is an absolute necessity when it comes to using NDMP as a means for backup; you need to know the exact path name in order to back it up to tape.

The problem exhibits itself when you run SMSQL in conjunction with SMVI – SMVI actually wraps the snapshot name in its own container. So while a SMSQL snapshot name *should* be something like “sqlsnap__servername__recent”, it ends up with this: “smvi__sqlsnap__servername__recent_20120213022637”. You can see that SMVI is prepending the SMSQL job with its own name, and appending the unique timestamp to the end, completely eliminating the purpose of the recent naming convention.

To work around this, I had to create a PowerShell script that NetBackup called when the backup job for that volume executes. The script greps the snapshot list for the “recent” string (since there is only one with that in there), renames it to it’s proper name, and then runs the NDMP backup. Once the backup is complete, it renames the backup back to its “improper” form. If you don’t rename it back, SMSQL will break as it loses track of its most recent backup.

All in all, a bit of a kludge, but the official word (?) out of NetApp is that this bug requires a re-write of the SMVI framework, so the current plan is to see that sometime after Q2-2012. We’ll see about that. For now, this solution works wonderfully.