2011-04-21 06:17 AM
The snapshot names created by PM are complex and contain spaces. A typical snapshot name created by PM on the secondary might be:
“2011-03-19 20:02:52 daily_netapp03_SnapMgr_Exchange_EXMB01_backup_5.-.exch_sg1log_qt.exch_sg2log_qt.exch_sg3log_qt”
It would be possible to run a script similar to http://communities.netapp.com/message/33081#33081 to pass the paths to backup to your backup program.
However, if you prefer to avoid scripting, here's an alternative suggestion: you can instead apply a “snapvault snap sched” on the secondary volume and use those snapshots for tape backup:
Tape backups should be scheduled to run some time after the snapvault snap sched creation (since active transfers might delay snap creation); or you could run a simple pre-backup script to check the date of the expected snapshot name.
For instance, if your PM schedule vaults at 8pm every day, you could set “snapvault snap sched <vol> sv_ndmp 2@21” on the secondary volume.
This will create a snapshot sv_ndmp.0 at 9pm (or later if the vault takes more than one hour to update).
Then you can schedule your backup program to backup /vol/<vol>/sv_ndmp.0 to tape at some later time (say 10pm, but schedule this based on your expected vault duration).
2011-04-22 03:23 AM
The snapshot names has a format and can be controlled using the following options in Protection Manager.
[root@lnx ~]# dfm options list | grep -i pmcus
pmCustomNameUseHostName Yes----------Removes Host name from snapshot when disabled.
pmCustomNameUseQtreeList Yes-------------Remove qtree name from snapshot when disabled.
pmCustomNameUseRetentionType Yes-----------Removes Retention-Type from snapshot when disabled
pmCustomNameUseVolumeName Yes----------Removes volume name from snapshot when disabled.
The format is as follows.
Timestamp cant be disabled but all others can be.
2011-04-26 07:22 AM
I have found that altering these dfm options also affects the name of the qtree that is created, which may or may not be to your liking.
Regarding NDMP backups of Snapvault secondary volumes, I have found that it is not necessary to specify a particular snapshot to backup because the "active file system" always contains the most recent backup anyway. You just point your backup software at the entire volume. I guess an added complication could be if a Snapvault transfer is currently in progress when your dump is running...
2011-06-28 09:46 AM
I happen to think the snapvault snap sched workaround is elegant when compared to some of the other solutions which require scripting to pass the snapshot name to the backup application.
Backing up a snapshot is preferred by some administrators because it guarantees a specific point in time when the backup was created. Because NDMP backups typically take a long time, scheduling tape backups means they don't all kick off at the same time, with this method the admin can say "All my tape backups are from Sunday at 5pm".
I'm just wondering if this is really crucial when compared to simply pointing the backup application to the secondary volume. If an existing NDMP connection is going against the secondary volume, then a snapshot would be created for this process. What is the impact if a snapvault update occurs at this time? Will it retry or create a busy snapshot, or?