>> >
>> > I thought Oracle's hot_backup was specifically designed to work with
>> > snapshots.
>> >
>> > I.e. freeze Oracle --> xfs_freeze --> create snapshot --> unfreeze
>> > xfs --> unfreeze Oracle
>> >
>> So the operation described above can be done in a relatively short
>> period of time yes? If so, then xfs_freeze won't have to be on long as
>> the snapshot would appear as though it were still frozen.
In my tests, it takes a minute or less. This is with pure Sept. 3 cvs code as
I remember. In my opinion, xfs_freeze is broken with pre-Sept. 3 code.
If you want to evaluate my test procedure, look at the xfs QA test 068.
That may also be a good source of shell script pieces you can borrow. Note
that it does not perform the actual backup, but it does mount the snapshot
readonly, before it simply unmounts and goes thru the cycle again.
In my tests, I was using, LVM 1.03 userland tools and whatever LVM kernel
components that are standard in the 2.4.19 kernel.
I have run over 2000 iterations of the 068 test with no glitches.
I tested under the heaviest loads I knew how to generate. If you want to run
your own tests, it should be relatively easy to modify it to use an Oracle
based load, instead of the one I used.
>> > Even worse, if you go into hot_backup for an hour or so, and you have
>> > a machine crash during this time, your new data is lost!!!!
>> I assume you're speaking to the snapshot? I think this is the part that
>> confuses me the most.
Reading the other response to your question, if you setup Oracle's transaction
log on another FS, then the xfs_freeze of the data FS will not be as horrible
as I described.
I still think the snapshot mechanism is the way to go.
>> > If you do want to try to go disk to disk extremely rapidly, you will
>> > need to either not use xfs_freeze, on mount your drive with -noatime.
>> We already mount with noatime, IOzone tests show it's much faster and
>> more consistent to do so. Disk-Disk backup would be ideal in our
>> situation, then it preserves the BCV like operation, which is really
>> what I'm trying to find out how to do, if I can, with XFS utilities.
BCV is not fundamentally a xfs feature. It does require xfs_freeze to be bug
free. It is a LVM or EVMS feature, or it can be built into a hardware RAID
controller. I have only used LVM with Linux.
There are 2 basic ways to do BCVs: snapshots and clones. Unfortunately these
terms are not consistently used, but I mean:
clone - Create a 3-way mirror, freeze the FS, split off one of the mirrors,
unfreeze orig FS, mount split off FS read-only, back it up, unmount it, re-sync
the mirror into a 3-way mirror again.
snapshot - Instead of using a 3-way mirror, Copy On Write (COW) technology is
used, but the high level process is the same.
Clones require RAID 1 or RAID 1 + 0. Snapshots can be anything (i.e. JBOD,
RAID 0, RAID 1, RAID 1+0, RAID 5).
FYI:
WIth COW, the snapshot process at the LVM level, causes a LVM data structure to
be created with a flag for each LVM block. Initially all flags are set to
_original_.
Then when a write to FS is performed, LVM checks the flag, if the block being
written is still _original_, LVM copies out the block to an unused part of the
VG and the flag is changed to mark the block _updated_.
The main mount point uses the original set of FS blocks exclusively.
The read-only snapshot uses the blocks still flagged _original_, and the copied
out blocks for the blocks flagged _updated_.
FYI: LVM 2.0 is going to support read/write snapshots. But I don't see a huge
value in that for backups. They can be very useful if you want to try a
complex DB action, and your not sure of what the results will be. i.e. Create
a r/w snapshot, mount it, run DB tests on it, delete the snapshot.
HTH
Greg Freemyer
Internet Engineer
Deployment and Integration Specialist
Compaq ASE - Tru64 v4, v5
Compaq Master ASE - SAN Architect
The Norcross Group
www.NorcrossGroup.com
|