can Amanda append to a tape that's not full?

[Gene Heskett]

On Friday 16 December 2005 15:08, Matt Morgan wrote:
>I'm about to do my first Amanda install next week (or so I thought),
>so I pulled out my O'Reilly "Unix Backup and Recovery" book. It's
> from 1999, and refers to Amanda version 2.4.2, but it says "Amanda
> currently starts a new tape for each run and does not provide a
> mechanism to append a new run to the same tape as a previous run
> ...".
>
>So I thought, well, that's probably out of date and I went to check
>the docs at Amanda.org, which appear to have been written for v.
> 2.4.2 as well and not updated (although the version I got through
> yum a couple days ago is 2.4.5).
>
>Can anyone tell me if this is still true? Also, it looks like Bacula
>works the other way--it keeps writing to a tape until it's full
>(although I can't tell yet if that's true over multiple jobs). Can
>anyone confirm that?

Its still true, and its intended to remain that way.  There are too 
many chances for someone to remove the tape and reinstert it which 
will of course rewind it since I don't know of any spinning head 
drives that don't, and the older qic formats would automaticly set the 
heads back to track 1 even if they didn't rewind it, which those I've 
encountered all did on tape insertion.

The whole point being that amanda has no guaranteed way to assure that 
the tape has not been moved since the last invocation.  Thats why it 
insists on full control of the tape while its running per invocation.

It probably also explains the relative lack of interest in patching 
amanda to allow it to span a file across more than one tape. That 
patch is available. The general idea is to not do anything that could 
impinge on its dependability.

Writing just one byte to the head end of a tape, and that tapes 
contents are gone.  And that to me, demonstrates the one achilles heel 
of tape.  I'm now using virtual disks on a 200GB drive and have had 
less than .01% of the nearly constant troubles I had with tape drives.  
What can I say other than virtual tapes Just Work(TM) here.  And in 
the event of needing to recover something, with the vtapes I have 
truely random access to the data, a huge advantage IMO.

You can find me on the amanda-users list at amanda.org too.

What you may want to do, if you have a big enough tape drive, is to 
setup an equally large holdingdisk area, and leave the tape out of the 
drive until enough data is on the holdingdisk that its worthwhile 
putting the tape into the drive and calling an amflush, which will 
move it all to tape in one session.

>This is for a very small business, with employees who aren't in the
>office a lot. The idea was to change the tape weekly, but write
>differentials to it 6 nights a week, and a full backup once a week
> (or something like that). The tapes are easily big enough to hold
> that much, and changing them more often would be very expensive.
>
>Maybe I should just write a script and use tar.
>
>Thanks a lot,
>Matt

-- 
Cheers, Gene
People having trouble with vz bouncing email to me should use this
address: <gene.heskett at verizononline.net> which bypasses vz's
stupid bounce rules.  I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.