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

Mike Meredith very at zonky.org
Thu Jul 8 15:18:36 CDT 2010

On Wed, 7 Jul 2010 07:56:24 -0400, Rich Kulawiec wrote:
> Actually, yes, it does (have code to cope with filesystems that are
> changing) -- the manual page has been wrong since the days of SunOS.

It's still SunOS. As I can't read the source code for the Solaris
ufsdump, I rather have to take the word of the manual page even if it's
wrong. It may be that it's safe, but without it being documented as
safe, I can't trust it.

> > Filesystem snapshots are of course the answer to the problem here. 
> They are definitely an answer to some problems, but I don't see how

I meant that they're a good way of ensuring that dump gets a static
filesystem to play with ... take a snapshot, dump the snapshot and you
have a dump of a filesystem that's guaranteed to be static.

Using snapshots to assist dump doing incrementals ? I'm not sure it
would help, although you could use it as a way of comparing old
versions of a file to see if it's changed.

In general, snapshots are _very_ useful as they allow you to go back
to previous versions in a way that is so much easier than ordinary
restores that you will find yourself beginning to use them in ways
that wouldn't be practicable with tape backups. 

> on a day-to-day basis.  I don't NEED to snapshot all that unchanging
> data over and over and over again: I just want the deltas, which are

Well with ZFS you're not snapshotting that unchanging data - you may
see it in the snapshot but the blocks are coming from the "live"

> Dump actually tries very hard to create output that's logically

Unless dump takes a zero amount of time to create the output, it
_cannot_ produce a consistent view of the filesystem as it was at 00:01
(or whenever you start it) - it cannot be done without snapshots. 

You can dump a filesystem that is relatively unchanging without
problems; you can even dump a filesystem that is changing frequently in
a way that allows the filesystem to be restored. But without taking a
snapshot of the filesystem you cannot guarantee a consistent view of
the filesystem. And yes there can easily be some applications getting
confused if they're writing to lots of files all over the place ... yes
such applications may well be badly written, but the world is full of
badly written applications.

> break it, but those are pretty unlikely to occur in production, and
> very likely to occur repeatedly.

A _single_ backup failure in some environments is enough to cause red
flashing lights, loud sirens, strident demands for RCAs, and all sorts
of stress.

Mike Meredith (http://zonky.org/)
 Write a wise saying and your name will live forever
 -- anonymous

More information about the rescue mailing list