On Thursday 14 August 2003 03:21, Toralf Lund wrote:
>> On Wednesday 13 August 2003 02:55, Toralf Lund wrote:
>> >I suddenly realised that I have a lot of dump directories on my
>> > holding disk, even though dumps have generally been successful.
>> > The below "amflush" output should illustrate this.
>> >
>> >
>> >-sh-2.05b$ /usr/sbin/amflush ks
>> >Scanning /dumps/amanda/hd...
>>
>> And they're all zero length files??
>>
>> I'd assume that /dumps itself is also owned by amanda:disk?
>> In which case I've NDI Toralf.  Delete them and see if they come
>> back.
>>
>> Is there anything odd in this mornings report for the dle's
>> mentioned?
>
>Ahem... I guess I didn't check "FAILURE AND STRANGE DUMP SUMMARY"
> well enough. The thing is, I expect it to contain *some* entries
> because we also try to back up laptops etc. that aren't always on
> the net (these will be backed up whenever they are connected
> overnight, which is good enough.) Sorry.

:)

>Anyhow, I actually get data timeout for some, if not all, of the
> DLEs, i.e. I have
>
>fileserv   /var/www lev 0 FAILED [data timeout]
>
>That might explain a great deal, I suppose. I don't understand why I
> get the timeouts, though. Note in particular that other disks on
> the same host are backed up successfully during the same run. Also,
> shouldn't the holding disk be cleaned up when dumps fail like this?
>
>And all this started happening quite suddenly (or so it seems) while
> I was on holiday, but I'm somehow not surprised by that... I moved
> the amanda server (and tape drives) from one host to another some
> time before that, but I *think* everything worked correctly after
> that (I'm fairly sure that e.g. fileserv:/var/www has been backed
> up a number of times after the move.)

Well, my old slow firewall needs a dtimeout of 1800 to get rid of that
error when it has to gzip a 2.9 gig /usr/src, so you may want to
increment that.

I inserted

dtimeout 3600

--
- Toralf