[rescue] Oracle making just a little harder to keep old machines in use

[Mike Meredith]

On Mon, 10 May 2010 08:00:53 -0400, Rich Kulawiec wrote:
> Tar doesn't have code to cope with filesystems that are changing
> as they're being read.

Actually neither does (ufs)dump ... the Solaris manual page
specifically warns against dumping filesystems mounted read/write, and
the FreeBSD 8.0 manual page hints that the same situation may cause
problems.

Some (incompatible) versions of dump such as avdfsdump (might be the
wrong time ... it's been a _long_ time) solve the problem of
filesystems changing underneath the dump process, but few others do.

Filesystem snapshots are of course the answer to the problem here. 

> It runs in userspace instead of reading the raw device.

Both run in userspace; reading the raw device might give some
advantages, but personally I prefer file-by-file backup ... whilst you
are not guaranteed consistency, at least it copes gracefully with the
inconsistencies unlike *dump which generates errors (although it
usually continues), and possibly generates erroneous backups[0].

> While it has some incremental backup capabilities, it's not readily
> usable in the same way that dump's incrementals are.  Yeah, you can
> wrap some shell around it and get close, but it's awkward.

Indeed. However you will almost certainly be wrapping any backup tool
in a shell script anyway ... unless you're using some 'advanced' backup
package such as Legato (which gives you a pretty Windows GUI and a
whole other set of problems).

For instance you often want to quiesce certain applications ... put
Oracle into "hot backup mode", stop a MySQL slave from applying
transactions. Or manually exclude log directories from backups.

You also (once you have more than about 2-3 servers to backup) want to
improve on the reporting. A simple cron mail becomes tricky to handle
once you get enough filesystems to monitor.

In addition it's also a good idea (which I must admit I never got
around to implementing) to "chunk" the backups to allow for better tape
streaming especially as modern tape drives are so fast. Dump is better
at this than file-by-file backup methods.

> What I'll argue that we (FSVO "we") need is a portable version of
> dump that runs on the appropriate set of currently-extant open-source

Perhaps. The problem of producing a portable dump format isn't trivial.

[0]: If the filesystem changes in just the right way, dump may write a
     series of blocks it thinks belongs to one file which actually
     (now) belong to another. Undoubtedly there is code that attempts
     to handle such situations, but the flaw is fundamental to the way
     that dump works with filesystems mounted read/write.

-- 
Mike Meredith (http://zonky.org/)
 "I wish there was a knob on the TV to turn up the intelligence.
There's a knob called `brightness', but it doesn't work." -- Gallagher