Odd behavior with Snapdrive SMSQL and SMVI concerning snapshot names

[chadharter]

I've got something really odd going on and I'm hoping someone has seen the same behavior.  I have a client using SMSQL.  Backups are running fine.  I have selected "Use Generic Snapshot Name" in the configuration and when you look at the snapshots in Snapdrive and in SMSQL, it shows the snapshot name as a generic name but when you login to Systems Manager and look at the actual snapshot on the Netapp Filer, it has a generic name with the timestamp concatenated on the end.  This is causing me issues as I need to write the most recent snapshot to tape via NDMP each night.  If I don't have a generic snapshot name on the Filer, I have to manually select the snapshot each night before it is written to tape.  I'm using Backup Exec and I can't use wildcards in the selection criteria for NDMP.

In Snapdrive, the snapshot name is shown as sqlsnap_servername_recent but when you look at the snapshot name in Systems Manager on the Filer, it says smvi_sqlsnap_servername_recent_timestamp

Anyone else seen this type of behavior?

Thanks,
Chad

[abhisek]

Hi Chad ,

SnapManager offers two conventions for naming backup Snapshot copies:

Unique backup naming: The most recent Snapshot copy name contains the Snapshot copy creation

date and time (indicated by the variable date_time) instead of the string

recent. The most recent backup is identified by the Snapshot copy name

with the most recent date and time. This removes the need for the rename of

the Snapshot copy when the next backup is created. This is the default

naming convention for SnapManager 5.1.

Generic backup naming: The most recent Snapshot copy name contains the string recent instead of a

date and time stamp. The most recent backup is identified by the Snapshot

copy name that includes the string recent. This is the Snapshot copy naming

convention used by older versions of SnapManager and is the default setting.

When you have dataset configured in your system, you can either choose to apply

the unique backup naming convention with the archival process enabled, or to

keep the generic backup naming convention. If you choose to keep the naming

convention as generic, If you choose to keep the naming

convention as generic, no archives of the database to be backed up at the remote

location are created.

If you archive the backups using PowerShell, the generic backup naming

convention is automatically changed to the unique backup naming convention.

Regards,

Abhishek

[chadharter]

I have selected the generic naming convention and the problem I'm having is that it is NOT naming the snapshot with the generic name on the Netapp Filer. It is putting the keyword recent in the name but then appending the timestamp to that. If you look at the same snapshot in snapdrive or SMSQL, it shows the generic name. Bottom line is that the snapshot name created on the Filer is not the same as what is shown in Snapdrive or SMSQL. That's the problem I'm trying to get figured out.  It's causing me issues when trying to write the most recent snapshot to tape via NDMP.

Thanks,

Chad

[jasonnash]

Hi Chad,

I am seeing this same issue here, it does not make sense to offer the '_recent' naming convention with a unique time stamp. For example the snapshot name is 'smvi__sqlinfo__servername__recent_20110524210300'.

We are running SMSQL version 5.1 as we needed support for NFS datastores with SnapDrive 6.3. As you are we are looking to use NDMP to dump the snapshot to tape. Did you get a resolution to this?

Jason

[chadharter]

Client was using Backup Exec to control the NDMP job.  I had to use the pre and post script options on the backup job.  I had to write two scripts, a pre-script that logs into the Filer and renames the snapshot by stripping off the time stamp before the NDMP dump and and a post-script that logs into the Filer after the NDMP dump and renames it back to what it was called before.  The snapshot has to be renamed back in order for the subsequent backup jobs to run in Snap Manager because the snapshot name is stored in the snapmanager database and it expects that name to be there when it does it's next backup.  I used powershell to write the scripts.  I had never used powershell before and it was still pretty simple.

The kicker is that you have to rename the snapshot manually first in order to create the backup job in backup exec and drill down to the snapshot you are using for the NDMP dump, otherwise, you can't select a snapshot that doesn't exist.  Also, Backup Exec WILL NOT allow you to use wild cards in the selection critieria of an NDMP job when used with Netapp.  If that piece worked, it would have saved me a lot of time.

Important thing to remember is that as part of the pre-script, you need to write out the timestamp to a file so that you can read it back in when you have to rename the snapshot back. As part of my scripting, I never delete the file that I create that holds the unique time stamp.  This way, if the job fails for some reason and the snapshot doesn't get renamed back, I can always go back and look at the last time it ran and what the snapshot name should be.  That way, I can login and change the name manually if need be, even if the job fails for a couple days before it is caught.

I verfied with Netapp that this process doesn't affect Snapmanager's ability to restore.  A bug was also created, even though there is no detail in it.  It can be found at the link below.  Hope this helps.

http://now.netapp.com/NOW/cgi-bin/bol?Type=Detail&Display=498506

[jasonnash]

Thanks Chad, thought this may have been the case. We are in the same position running Backup Exec, I have not attempted wildcards but I think I also read else where that this does not work. If you still have any copies of the scripts and would be willing to share could you drop me a message.

[john_higgins]

any chnace of a copy of your script to rename snapshots and restore name after backup.

Obvoously will be taken "as is", will save me creating one from scratch

john@xorps.com

[jerimiah303]

It's a known issue with VSC. Basically, VSC treats the snap as a manual job and appends the snap name with a time stamp.

Should be fixed in the next release of VSC last I heard.

[cahaynes86]

FYI: VSC 2.1 just released and this "feature" is still NOT "changed".  I say changed, because I called Netapp and the engineer I spoke to insisted this was not a "bug" that needed fixed, but simply a design change request that a few folks are asking for.  I don't think he realized the significance of the issue.  Too bad thousands of us are suffering in the mean time, forced to write scripts to rename snapshots just so we can do NDMP backups of SMSQL-SMVI snapshots.  Until something better comes along, back to scripting (mumble, mumble, mumble....)

[jerimiah303]

I had to convince them it was indeed a bug as the documentation is clear regarding how the naming convention should work. SMSQL 5.1 docs do not mention any additional snap name changes in a virtual environment. Any chance you could send me a copy of the script you're using?

jcox303 at gmail dot com.

Thanks!

[jasonnash]

What is the current update from Netapp on this, have they given an idea of when this will be fixed? As Chad states there seems to be a bug but it does not show any details. I have yet to log a call but I guess you guys already have open calls on this issue?

[deannamcneil]

The bug id is 498506 and in the email I have from support dated 6/27/2011 there is no current fix or workaround. I too would love to have a copy of any scripts that have helped address this issue for Backup Exec NDMP jobs.

[abhisek]

This is still being worked by engineering.

[deannamcneil]

One simple workaround we have found here that seems to work is to create the job literally on the server you want to have the "_recent" folder. Whatever gap exists in the SMSQL code is bypassed by creating the job this way. We consistently see the "_recent" folder when jobs are created this way.

[cahaynes86]

There have been several versions of VSC released and now a new SnapDrive version and this is still an issue.  Anyone from Netapp know when this is going to be fixed?

[abhisek]

We are yet not supporting Generic naming convention due to limitation with VSC. The fix is coming in next release of VSC.IAG has documentation on this

“Using the generic backup naming convention in VMDK configuration is not supported”, Pg 233.Please have a look in the IAG.

The next release of VSC has the fix and it will be there in next release of SMSQL. The current versions SMSQL 5.2  will still not support it.

Regards,

Abhishek

[cahaynes86]

SMSQL 6.0 was released today (Oct. 4, 2012) and this bug is FINALLY listed as a "Fixed Issue":

Bug ID 498506

Generic SnapShot copy naming convention is not generic on VMDK based configurations

If a database resides on VMDK disk, and is backed up with the generic naming convention, the

SnapShot created on storage system does not have the generic names. Instead of having SnapShot

copies named as "sqlsnap__<server>__recent", created on the storage system, the SnapShot is named

as: "smvi__sqlsnap__<server>__recent__<timestamp>", which is not generic.

I haven't had a chance to test it yet, but I can't wait to get rid of all those PS scripts that we've had to keep manually updating for the past year and a half.

- Chris