Re: Backups done right (was [ANNOUNCE] Ext3 vs Reiserfs benchmarks)

[Sam Vilain <sam@vilain.net>]

stoffel@lucent.com wrote:

>   1. lock application(s), flush any outstanding transactions.
>   2. lock filesystems, flush any outstanding transactions.
>   3a. lock mirrored volume, flush any outstanding transactions, break
>       mirror.
>   3b. snapshot filesystem to another volume.

Or, to avoid the penalty of locking everything and bringing it down
and stuff:

  1. set a flag.

  2. start backing up blocks (read them raw of course, don't want to load
     those stressed higher level systems)

  3. If something wants to write to a block, quickly back up the old
     contents of the block before you write the new contents.  Unless of
     course you've already backed up that block.

Of course, step 3 does place a bit more unschedulable load on the
disk.  Heck, when the backups have just started, you're doubling the
latency of the devices.  You can avoid this with a transaction
journal; in fact, the cockier RDBMSes out there (eg, DMSII) don't even
bother to do this and assume that your transaction journal is on a
mirrored device - and hence there's no point in backing up the old
data, you just want to do one sweep of the disk - and replay the
journal to get current.

(note: implicit assumption: you're dealing with applications using
synchronous I/O, where it needs to be written to all mirrors before
it's trusted to be stored)

Ah, moot points - the Linux MD/LVM drivers are far too unsophisticated
to have journal devices ;-)
--
   Sam Vilain, sam@vilain.net     WWW: http://sam.vilain.net/
    7D74 2A09 B2D3 C30F F78E      GPG: http://sam.vilain.net/sam.asc
    278A A425 30A9 05B5 2F13

Law of Computability Applied to Social Sciences:
 If at first you don't suceed, transform your data set.