It's obviously this I/O error that's causing the problem... the
filesystem is 67 gig (df -k says 67108864 1048-K blocks). The other
filesystems being backed up to the tape only are using 3-4% of tape
capacity... and it's a DLT 40/80. The compression ratio seems like all
this should fit on 1 tape:

STATISTICS:
                          Total       Full      Daily
                        --------   --------   --------
Dump Time (hrs:min)       28:15      25:04       0:08   (1:18 start,
1:46 idle)
Output Size (meg)        1205.4        0.0     1205.4
Original Size (meg)      3534.7        0.0     3534.7
Avg Compressed Size (%)    33.9        --        33.9
Tape Used (%)               3.4        0.0        3.4   (level:#disks
...)
Filesystems Dumped           36          0         36   (1:35 2:1)
Avg Dump Rate (k/s)       178.1        --       178.1
Avg Tp Write Rate (k/s)    13.6        0.0     2660.9

but maybe it's possible this 67-gig filesystem is filling my DLT tape
up, it reaches the end of the tape, and it I/O errors? If so I need to
do some math (blech) to determine how much data we can get rid of on
this big filesystem...

wab



-----Original Message-----
From: owner-amanda-users AT amanda DOT org
[mailto:owner-amanda-users AT amanda DOT org] On Behalf Of Paul Bijnens
Sent: Thursday, March 13, 2003 5:04 AM
To: wab
Cc: amanda-users AT amanda DOT org
Subject: Re: level 0 of huge filesystem not working (tar returned 2, and
the backup fails)


wab wrote:
> One filesystem I'm trying to back up with AMANDA is really huge and
I'm
> encountering errors:
> 
> This filesystem is so huge, a level 0 is taking longer than 24 hours.
> Any ideas on what could be going wrong? My best guesses:
> 
> 1. The filesystem is just too big for TAR.

No, at the end of the tar output, you see its summary line:

 > | Total bytes written: 30747043840

All fine here.

> 2. The filesystem is so big, its contents are changing during the tar
> process and confusing it or amanda.

But there are some IO errors:

> ? gtar: Read error at byte 53808128, reading 10240 bytes, in file
> ./archive/www/access.0203.gz: I/O error

These trigger the "error code 2" message at the end.
It means that this file is probably corrupted on tape.
But the rest of the archive is still useable.

> ? gtar: Cannot add file
> ./opt/freeware/apache/share/htdocs/Library/easmenu.lbi.LCK: No such
file
> or directory
 > [...etc...]

These message are the result of tarring an active filesystem.
It's up to you to decide for each file if it is important or not.
e.g. a missing lockfile or other temporary file is harmless, a growing 
logfile is harmless, a growing mailbox (with simple sequential access) 
is also harmless, but a changing Berkeley DB file is probably more 
dangerous.

-- 
Paul Bijnens, Xplanation                            Tel  +32 16 397.511
Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM    Fax  +32 16 397.512
http://www.xplanation.com/          email:  Paul.Bijnens AT xplanation DOT com
***********************************************************************
* I think I've got the hang of it now:  exit, ^D, ^C, ^\, ^Z, ^Q, F6, *
* quit,  ZZ, :q, :q!,  M-Z, ^X^C,  logoff, logout, close, bye,  /bye, *
* stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt,  abort,  hangup, *
* PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e,  kill -1 $$,  shutdown, *
* kill -9 1,  Alt-F4,  Ctrl-Alt-Del,  AltGr-NumLock,  Stop-A,  ...    *
* ...  "Are you sure?"  ...   YES   ...   Phew ...   I'm out          *
***********************************************************************