--On Monday, April 22, 2002 11:42:46 -0600 "Brashers, Bart -- MFG, Inc." 
<[EMAIL PROTECTED]> wrote:
> Hi Frank, thanks for your response!
>
>> To summarize what I think you've said, you are trying to back up
>> ~200GB on a 40GB tape, and are dynamicly rewriting your disklist
>> entries into ~25GB chunks. You don't say how many tapes you have
>> in your runtapes and tapecycle, or if you have some kind of changer
>> configured (even if it is chg-manual).
>
>> > The relevant parts of my amanda.conf file are:
>> >
>> > dumpcycle 3 weeks
>> > runspercycle 15
>> > tapecycle 17 tapes
>> > define dumptype mydumptype {
>> >     program "GNUTAR"
>> >     compress none
>> > } (plus more of the usual options)
>
> runtapes 1
> tapedev "/dev/nst0"
>
> I'm trying to avoid using chg-manual, and let amanda run on 1 tape per
> night.  I'd like to be able to use my tape drive for other non-amanda tasks
> during the day ;-).

You could still use it during the day, as long as amdump or amcheck
weren't trying to use it.  If you really don't want to set up a changer,
and if you have enough holding disk, you could lie to Amanda about
your tapetype and say it is 80GB, then planner will dump up to that
much.  You will get a tape error in your daily report (since it will
hit EOT around 40GB), but you can then amflush it whenever it is
convenient.

>>> FAILURE AND STRANGE DUMP SUMMARY:
>>>   beowulf    /home/proj/mm5 lev 1 FAILED [dump larger than tape, skipping
>>> incremental]
>>>   beowulf    /var/mail lev 1 FAILED [dumps way too big, must skip
>>> incremental dumps]
>>> (and so on, for ~30 or so directories)
>>
>> This says an incremental of /home/proj/mm5 is >40GB so it can't write
>> it to tape.  The /var/mail error (dumps way too big) indicates that
>> the day's backup can't fit on the tapes allotted to it, so Amanda is
>> having to skip backups of those filesystems.
>
> Ok, I'm confused.  Each of these errors "dump larger than tape" and "dumps
> way too big" refers not to the overall amanda run, BUT TO THAT PARTICULAR
> DISK?  That should be impossible.  Each night _before_ amanda is run, my
> ammakelist script would break up /home/proj/mm5 into sub-directories that
> are each less than 25Gb.  So it's impossible for the lev 1 to be larger than
> 25Gb, and it should fit on a tape.  Not necessarily this tape, since the
> amount to be written on any one night is generally larger than my
> tapedrive...
>
> [root]% du -h /var/spool/mail/
> 360k    /var/spool/mail
>
> There's no way the lev 1 on /var/spool/mail is larger than a tape.  So these
> errors "dump larger than tape" and "dumps way too big" must refer to the
> total amount dumped to tape.

"dumps way too big" does refer to total backup size, but the other
warning, "dump larger than tape" refers to the individual filesystem.
Check the size of /home/proj/mm5.  Perhaps its size changed between
the time your disklist was created and when amdump ran.

>> Increasing runtapes should help (although you may have to adjust
>> tapecycle and runspercycle unless you have extra tapes).
>
> So my idea that I should add tapes (I recently went from 12 to 17) was
> heading in the right direction.  I have extra tapes in-house.  Can I go to
>
> dumpcycle 4 weeks
> runspercycle 20
> tapecycle 22 tapes
> runtapes 1
>
> or do I have to go to something like
>
> dumpcycle 2 weeks
> runspercycle 10
> tapecycle 22 tapes
> runtapes 2

Unless you can use compression to get more on a tape, it will take
quite a while to get everything backed up if you only use one tape
(5 or 6 days to do the first set of fulls without any incrementals).
I prefer having more than one full backup around, so I would prefer
the shorter dumpcycle.  If your data doesn't change too much it might
only require two tapes for the first couple of weeks and then it
will level out and fit on one tape again.  Definitely look into
compression, some data (especially text) compresses amazingly well.
  If you are using hardware compression you may be able to increase
the size in your tapetype if you are not getting EOT errors.

> <much trimmed>

Frank

--
Frank Smith                                                [EMAIL PROTECTED]
Systems Administrator                                     Voice: 512-374-4673
Hoover's Online                                             Fax: 512-374-4501

Reply via email to