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

[James Sutherland]

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:
>> On Tue, Jun 22, 2010 at 1:31 PM, Conor Daly <c.daly at met.ie> wrote:
>> > On Tue, Jun 22, 2010 at 08:03:22AM -0400 or thereabouts, Little Girl wrote:
>> >> Hey there,
>> >>
>> >> Conor Daly wrote:
>> >>
>> >> > I'm backing up a 300Gb filesystem to an SDLT320 tape and,
>> >> > occasionally, the weekly level 0 dump will overflow to a second
>> >> > tape.
>> >> >
>> (snip)
>> > Mag tapes are a different kind of storage.  Basically data gets written /
>> > read sequentially so there's no real way to interact with a tape.  Depending
>> > on the software that wrote the tape, there may be a catalogue stored at the
>> > beginning of the tape but there's no real way to know about size stored.
>>
>> 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. 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?

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.

(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.)

-- 
James A Sutherland
mobile +44 7977 563483; Skype jas88cam