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@xxxxxxxxxxxxxxxxx> 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.
