NDMP backup from snapvault secondary where the relationship is managed by Protection Manager

[abond]

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:

• The snapshot name will always be the same, so the backup configuration will be simple.
  
• Since it’s a snapvault schedule it will wait for any PM-managed transfers to the volume to complete before creating the snapshot.
  
• Since the data in the most recent transfer will be application-consistent, the tape backup will be of app-consistent data too.
  

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

[adaikkap]

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.
pmCustomNameUsePrefix                 Yes
pmCustomNameUseQtreeList              Yes-------------Remove qtree name from snapshot when disabled.
pmCustomNameUseRetentionType          Yes-----------Removes Retention-Type from snapshot when disabled

pmCustomNameUseType                   Yes
pmCustomNameUseVolumeName             Yes----------Removes volume name from snapshot when disabled.
[root@lnx ~]#

The format is as follows.

<timestamp><retention-type>_<host>_<volume>.[<qtree>....];

Timestamp cant be disabled but all others can be.

Regards

adai

[rmharwood]

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...

Richard

[hadrian]

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?

- Hadrian