Amanda-Users

Re: dd gets tape native capacity, amanda (sometimes) dosen't

2002-08-11 22:30:32
Subject: Re: dd gets tape native capacity, amanda (sometimes) dosen't
From: Will Aoki <waoki AT umnh.utah DOT edu>
To: amanda-users AT amanda DOT org
Date: Sun, 11 Aug 2002 15:57:04 -0600
On Sat, Aug 10, 2002 at 12:08:43AM -0400, Jon LaBadie wrote:
> 
>     Pulling individual lines from a long message:
> 
> On Fri, Aug 09, 2002 at 03:37:32PM -0600, Will Aoki wrote:
> 
> > Some nights, to some tapes, my backups run fine. I get about 8 GB dumped
> > to tape:
> > 
> > But other days, to other tapes, I run out of tape at about 5 GB:
> > 
> 
> Note this line from your failed report:
> 
> >   taper: tape umnh-20011112-1 kb 9590432 fm 33 writing file: No space left 
> > on device
> 
> It says 9.6GB of data plus 33 file marks were written before the error.  Not 
> 5GB.
> 
> Now, your file system by file system list shows an output size (after 
> compression)
> of 5.3GB plus one failed file system.  Those 5.3GB were "successfully 
> written" as
> evidenced by the completed "taper" statistics.
> 
> My guess about the failed entry is that it is a very large file system, more 
> than 4GB
> after compression.

That seems to be it. I've been misreading the report - since the
STATISTICS section is actually only reporting successfully dumped data,
I thought that much less data was getting to tape than actually was.

Someone seems to have killed my .amandaexclude for the failing
filesystem between when the filesystem was being dumped successfully and
when it started failing, bloating a 2.5 GB volume to 8.5 GB. I'm pretty
sure I know who it was, since there's only one other person with the
neccessary access privs to do the deed, and he was cleaning up cruft
around the time my backups started failing...

I've recreated the exclude file, so I expect that tonight's backup will
be successful.

Thanks for your help!

> Further, I think there is insufficient holding disk space to receive that 
> system dump.
> Thus it was being dumped directly to tape.  I say this because there is no 
> dumper
> data.  A dump to the holding disk must complete before transfer to tape 
> begins.  As
> taping was in progress, yet there is no dumper data, the dump must be going 
> directly
> to tape.  Otherwise there would be dumper data and dumps left on the holding 
> disk
> available for amflush.
> 
> Basically some days you are backing up more data than a single tape can hold 
> and are not
> using multiple tapes per run.  Plus, some of your systems will not fit the 
> holding disk.
> About the holding disk space, how big is it and what percent is "reserved"?

Only 2GB, with 'reserve 60'. I'm hoping to get more after Tuesday's
mission to scavenge parts from the junk computers my department has left
in the building's heating / service tunnel.

-- 
William Aoki     waoki AT umnh.utah DOT edu       /"\  ASCII Ribbon Campaign
B1FB C169 C7A6 238B 280B  <- key change    \ /  No HTML in mail or news!
99AF A093 29AE 0AE1 9734   prev. expired    X
                                           / \

<Prev in Thread] Current Thread [Next in Thread>