What would it take to have some sort of config option that did exactly
that? I have a 15/30DLT ... I have a 15gig holding disk ... when holding
disk is full, dump it all to tape and then backup to the holding disk
again ... then, your tapes would always be full and you don't have to
worry about whether you have enough holding disk for a weeks worth of
data, or what not ...
You also then have the benefit of getting the tape "up to speed", dumping
15gig (or whatever) to her and getting max use of the drive ...
On Wed, 7 Feb 2001, Simon Mayr wrote:
> > Christoph Scheeder has told me that I can't use only one tape for backing up
> > all the days of the week. Can anybody suggest me a solution? By the moment,
> > I can´t pay more tapes.
> >
> > Thanks
>
> You should really (!) buy at least a second one.
>
> As stated in my copy of the FAQ:
>
> Q: What if my tape unit uses expensive tapes, and I don't want to use
> one tape per day? Can't Amanda append to tapes?
>
> A: It can't, and this is good. Tape drives and OS drivers are
> (in)famous for rewinding tapes at unexpected times, without telling
> the program that's writing to them. If you have a month's worth of
> backups in that tape, you really don't want them to be overwritten, so
> Amanda has taken the safe approach of requiring tapes to be written
> from the beginning on every run.
>
> This can be wasteful, specially if you have a small amount of data
> to back up, but expensive large-capacity tapes. One possible approach
> is to run amdump with tapes only, say once a week, to perform full
> backups, and run it without tape on the other days, so that it
> performs incremental backups and stores them in the holding disk.
> Once or twice a week, you flush all backups in the holding disk to a
> single tape.
>
> And you could even run the level 0 without tape and always flushing your
> backups, assuming you have enough space for a full week of backup.
>
> Try this ( or similar)
> dumpcycle 7
> runspercycle 5
> tapecycle <what-you-have>
> # with reserve 100 she will always degrade the level 0's
> reserve 30
>
>
> Simon
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
