Bill> For the LUNs you have to make sure the data is quiesced before Bill> you take the snapshot or the data inside the LUN may get Bill> corrupted during a restore.
Yup, ideally. But my Oracle Admin swears that things will be ok. We'll be doing testing of restores to see if we need to quiesce things in the pre- script to make sure things are ok. So far, it's been ok. I know... famous last words!
Bill> If a database is hosted on the LUN you have to put the database Bill> into hot backup mode. Snapdrive can be very helpful for this as Bill> well as it will ensure all the buffers get flushed to disk prior Bill> to taking the snapshot.
We don't have snapdrive at all, the DBs are all on Solaris 10 boxes, mounting FC LUNs or NFS volumes from the netapp. Ideally, I'd like for us to move to the Oracle DBs on NFS volumes as well sometime, since the LUNs are just a pain in the ass to deal with.
Bill> If you're going to do a file based backup from the LUNs, why not Bill> mount a clone of the LUNs, possibly on a different server, and Bill> just use the regular File System iData Agent?
Speed, we have lots of data to backup and we want to make these backups run as quickly as we can. We figure restores are going to be urgent if we ever have to do one, so minimizing restore time is key. We're also (possibly) going to have to make sure these backups (really, the snapshots of the volumes) happen at a good time. We'll see how it goes.
Bill> On Wed, May 9, 2012 at 4:04 PM, John Stoffel Bill> john.stoffel@taec.toshiba.comwrote:
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:
- 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.
- I then setup a new sub-client, added in the volumes I wanted, and
drilled down to the named snapshot and added that.
- 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