[rescue] Mounting and Dumping

[Sheldon T. Hall]

Mike Meredith says ...
> On Wed, 14 Jan 2004 14:04:39 -0500, Sheldon T. Hall wrote:
> > Janet L. Campbell writes [on the subject of ufsdumping mounted
filesystems] ...
> > >
> > > It depends on what's happening to the filesystems at the time.  The
> > > principle danger of dumping a mounted filesystem is that writes may
> > > make the dump inconsistent.  This is *usually* not a big problem
> > > when the machine is otherwise quiet.
> >
> > Inconsistent, I can stand,  Unreadable, I can't.  Will the fs activity
> > while dumping a mounted filesystem make the dump unusable, or just
>
> If you find a reliable answer, I'd be very interested in hearing about
> it. I wouldn't use ufsdump myself despite ufsrestore having one of the
> nicest interfaces for emergency restored I've seen.

Y'know, I was just testing last nights dump to the new DLT tape, and cursing
ufsrestore's UI.... Different strokes, I suppose.  Of course, I've hardly
ever had to use ufsrestore, except to test my backups.  Only once have I
used it in anger.

> A few years ago I was converting work's backup script from Digital Unix
> to Solaris and spent a long time looking into ufsdump. At the time I
> couldn't find a definitive answer to this problem. I seem to recall
> someone commenting that a write to a filesystem that is being dumped can
> cause the entire dump to be useless if you're unlucky.

Of course, what's _really_ bad is that ufsdump doesn't tell you it's writing
crap; you only find that out when you try to restore from your backup.

> I don't like relying on my luck when it comes to backups.
>
> http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb/71515
> http://sunsolve.sun.com/pub-cgi/retrieve.pl?doc=fsrdb/70105
> http://www.sunmanagers.org/pipermail/sunmanagers/2001-January/000915.html
>  (Read all the way through all the responses to that one)

No consistent message there ... some say it's OK, some say it's not.
However, one chap suggests using `nice` to raise ufsdump's processing
priority so that one's exposure to filesystem changes is reduced.  It seems
that might also help with the streaming issue, if the process isn't just
disk-bound.  My backup jobs run in the wee hours, and no one local is using
the machine at all.  I can give ufsdump a lot of priority without
inconveniencing anyone.

I find it interesting that SGI does things quite differently.  xfsdump will
_only_ dump mounted filesystems, according to the man page, and the SGI GUI
backup thingie uses cpio rather than xfsdump anyway.

Tonight we'll find out if my normal "xfsdump on the SGI through dd to the
tape on the Classic" will work with the new tape drive.

FWIW, the old DDS drive took 2:30 to backup the Classic.  The DLT took about
40 minutes.

> Of course using fssnap is a whole different ball game.

Yeah, it looks pretty cool, indeed.

> Yes I know I'm not in agreement with the majority view here which means
> I'm probably wrong :)

Oh, I wouldn't say that.

> > > Maybe.  If you're dumping a partition with lots of small files, the
> > > Classic may just not be able to keep up with the DLT drive because
> > > of disk speed and fragmentation.
> >
> > Jochen Kunz suggests the same thing: the Classic isn't as fast at the
> > tape. He also suggested disableing compression to help it stream, and
> > I'll try that.
>
> Disabling compression on the DLT drive or the Classic?

On the DLT drive.  Its capacity is way larger than any of the filesystems,
so running it uncompressed to keep it streaming would be OK.

> The DLT drive should be able to stream with its
> compression on.

The drive can, but it looks like the little Classic can't feed it fast
enough to keep it streaming, at least as I have it now.  I'll play with
`nice`, compression, and the other SCSI channel to see what I can do about
that.

> Not streaming is (long term) a recipe for dead tapes
> and drives.

Yep.  Been there.  Done that.  Remember those sucky little Colorado drives
that ran off the floppy disk cable on a PC?

-Shel