For the LUNs you have to make sure the data is quiesced before you take the snapshot or the data inside the LUN may get corrupted during a restore.  If a database is hosted on the LUN you have to put the database into hot backup mode.  Snapdrive can be very helpful for this as well as it will ensure all the buffers get flushed to disk prior to taking the snapshot.

If you're going to do a file based backup from the LUNs, why not mount a clone of the LUNs, possibly on a different server, and just use the regular File System iData Agent?

On Wed, May 9, 2012 at 4:04 PM, John Stoffel <john.stoffel@taec.toshiba.com> wrote:

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