Bill> With the NAS iData Agent you should be able to drill down to the Bill> named snapshot as your data source Bill> (e.g. /vol/myvol/.snapshot/mysnapshot). You could recycle the Bill> named snapshot to rename or delete the previous snapshot then Bill> create a new one with the same name.
Bill> snap rename myvol mysnapshot mysnapshot.1 Bill> snap create myvol mysnapshot
Bill> DOH!!! While I was typing this I remembered that I was thinking Bill> of in terms of NDMP backup performance was QTree vs Volume, not Bill> Volume vs named snapshot. Your named snapshot is essentially a Bill> volume level backup so it should not be signifcantly different Bill> in performance. QTree backups are much slower because it has to Bill> determine which files belong to the QTree then which blocks Bill> those files use.
Ah... that explains it. I couldn't figure out why it would be a problem using named snapshots... so I decided to test it out. Performance looks to be just fine so far... we'll see how it ends up being.
Thanks for the hints, I've ended up doing the following:
1. create new snapshots for each volume in the set that are to be backed up. I used a consistent name for the snapshots to make life easier.
2. I then setup a new sub-client, added in the volumes I wanted, and drilled down to the named snapshot and added that.
3. I wrote a pair of simple pre/post scripts which run on a CommVault Media Agent. The pre- script just deletes any existing snapshots with the same name, and them re-creates a new one.
The post- script goes through and deletes the named snapshot as well.
Now to test out the process for restores. Part of the issue is that one or more of the volumes will actually be an FC lun that needs to be restored, then mounted somewhere else and data copied out. Not ideal, but should work for what we need.
Thanks, John