[Techtalk] Detect if Dump used multiple tapes for backup.

Conor Daly conor.daly-linuxchix at cod.homelinux.org
Thu Jun 24 20:48:55 UTC 2010


On Thu, Jun 24, 2010 at 08:16:02AM +0100 or so it is rumoured hereabouts, 
James Sutherland thought:
> On Tue, Jun 22, 2010 at 4:44 PM, Conor Daly
> <conor.daly-linuxchix at cod.homelinux.org> wrote:
> > On Tue, Jun 22, 2010 at 04:23:51PM +0100 or so it is rumoured hereabouts,
> > James Sutherland thought:
> >>
> >> How does the tape get changed? Presumably, in the overrun case, your
> >> dump starts writing to tape #1, fills up the 160Gb (after compression),
> >> then something goes "whoops, out of space - on to tape #2!" Even if
> >> it's automatic, *something* must be getting told to change the tape for
> >> the first backup to continue: could you not detect that event from logs,
> >> exit status or whatever?
> >
> > There is a script that runs between tapes.  Currently it does nothing and
> > just returns and dump continues to attempt to write to the same tape.
> > This repeats a bunch of times before dump gives up.
> >
> > The filling of tapes is only really becoming an issue for us recently and
> > it's in the context of updating our backup scripts that I'm trying to
> > figure out this stuff.
> >
> > We use a tape library to load up to 8 tapes sequentially.  Currently there
> > is one tape dedicated to each 300Gb filesystem and another covering the /
> > /home etc filesystems.
> >
> > The plan is for dump to call a tape change script when a tape fills and
> > then to carry on.  Because we do a weekly level 0 followed by daily level
> > 1 dumps to the same tape, we must wind the tape to end of data for each
> > level 1.  In the case that tape 1 is full and the end of data is on tape
> > 2, I need to figure out how to detect that.  I'll have to do some more
> > testing, particularly for the case where we actually change the tape when
> > it fills to see is there any flag readable from the tape.
> >
> > Otherwise I'll have to log the status in the filesystem instead...
> 
> Hm - since you must have a working "append" facility, perhaps
> trying "append this block of randomness to the tape" would do?
> That will fail iff the tape is full; I suppose you still get a corner
> case where the final dump fitted *exactly* on the tape without
> a single block to spare.

Hmm.  That's an interesting idea.  I wonder would restore get upset in
this case or will it just detect the end of volume #1 and ask for volume
#2?  I suspect so...

> Alternatively, if there is a "wind to end
> of data", can you either explicitly ask "how many blocks remain?"
> or "wind to end of tape" then ask how far it moved?

This would be nice and I'll have to investigate further.  There was
something like this in the back of my head..
 
> Personally, I think I'd set it up to dump everything to tape 1,
> changing once that is full - keep track of what is on which tape
> on a local drive, but copy that to the start of each tape when
> you change. Then you still have your tape index if anything
> happens to local storage, but also have that index for easily
> finding data in the library.

Now that is a major revision of our backup strategy and is getting into
the realm of using somebody else's backup software.  As it stands it's all
our own software running this stuff and we know exactly what's happening.
I'm reluctant to shift our currently successful strategy without extensive
pondering / research / testing...

OTOH, the current tape library reaches end of life in 2 years so, at that
point we may move to some other solution.  One possibility is a machine
filled with a bunch of hotplug SAS/SATA drives that get rotated in similar
fashion to the tapes.  Hard disks are close to the same price (or less) as
the SDLT tapes.
 
> (Or prepare the backups on a hard drive and rzip them, rather
> than rely on the drive's own compression: this will give you
> better ratios and also let you know as you load the tapes
> where each dump will be put.)

For this, we currently have insufficient space.
 
Some nice ideas there.  Thanks a bunch.

Conor

-- 
Conor Daly <conor.daly at cod.homelinux.org>
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCS/G/S/O d+(-) s:+ a+ C++(+) UL++++ US++ P>++ L+++>++++ E--- W++ !N
PS+ PE Y+ PGP? tv(-) b+++(+) G e+++(*) h-- r+++ z++++ 
------END GEEK CODE BLOCK------
http://www.geekcode.com/ http://www.ebb.org/ungeek/


More information about the Techtalk mailing list