> > I've just completed a full cycle (2 weeks) through my 22 DLT8000 (40Gb)
> > tapes, and most of my disklist entries have never been dumped.
> >
> > I have one disklist entry that is getting a full dump every day, and I
don't
> > know why. It's so large that it's preventing most other things from
getting
> > dumped.
Several kind users gave me suggestions to try:
> Does the /etc/amandates file exist (and get updated each run)?
Yes, though I don't quite know what the lines inside mean...
[root]% ls /etc/amandates
-rw-r--r-- 1 amanda disk 13k Jun 20 00:35 /etc/amandates
[root /tmp/amanda]% grep bia /etc/amandates
/home/proj/bia-9584 0 1023872273
/home/proj/bia-9584 1 1024554189
/home/proj/bia-9584 2 1006837703
/home/proj/bia-9584 3 1002222594
> Does the tar command in /tmp/amanda/runtar.*.debug* show
> '--listed-incremental',
> followed by a gnutar-lists file, which should exist (without the .new
> extension) and contain a list of files?
There are several (2 to 5) /tmp/amanda/runtar.*.debug* files for the disk in
question for each day:
[root /tmp/amanda]% grep -l /home/proj/bia /tmp/amanda/runtar.20020619*
/tmp/amanda/runtar.20020619210554006.debug
/tmp/amanda/runtar.20020619210555.debug
/tmp/amanda/runtar.20020619210556.debug
/tmp/amanda/runtar.20020619232310.debug
[root]% cat /tmp/amanda/runtar.20020619210554006.debug
runtar: debug 1 pid 25144 ruid 507 euid 0 start time Wed Jun 19 21:05:54
2002
/bin/gtar: version 2.4.2p2
running: /bin/gtar: /bin/gtar --create --file /dev/null --directory
/home/proj/bia-9584 --one-file-system --listed-incremental
/var/amanda/gnutar-lists/beowulf_home_proj_bia-9584_0.new --sparse
--ignore-failed-read --totals .
[root]% ls /var/amanda/gnutar-lists/server_home_proj_bpa-9584_*
-rw------- 1 amanda disk 1.1k Jun 12 02:16
/var/amanda/gnutar-lists/server_home_proj_bia-9584_0
-rw------- 1 amanda disk 1.1k Jun 19 23:41
/var/amanda/gnutar-lists/server_home_proj_bia-9584_1
-rw------- 1 amanda disk 1022 Nov 26 2001
/var/amanda/gnutar-lists/server_home_proj_bia-9584_2
-rw------- 1 amanda disk 706 Oct 4 2001
/var/amanda/gnutar-lists/server_home_proj_bia-9584_3
So the answer is "yes" to both questions.
> Are the timestamps on all the files in the disk actually
> being changed daily?
No. The most recently changed file has a May 13 timestamp, according to
/usr/bin/find.
> Does the filesystem have 'snapshots' or similar funtionality
> that can be traversed by tar (you would see the entire
> snapshot as new, plus the files that actually changed)?
No, it's good old (or is that good new) ext3. What's a 'snapshot'?
> First, I'd look at the index file and see what files are
> being backed up.
> For some reason, it looks to GNU tar as if that much data is changing
> every time it's run. Do an "ls -l" on some of the files and
> see if they are changing.
[root]% cd /var/lib/amanda/Daily/index/sever/_home_proj_bia-9584/
[root]% ls
total 48k
-rw------- 1 amanda disk 2.9k May 30 23:21 20020530_0.gz
-rw------- 1 amanda disk 2.9k May 31 23:32 20020531_1.gz
-rw------- 1 amanda disk 2.9k Jun 4 00:36 20020603_1.gz
-rw------- 1 amanda disk 2.9k Jun 4 22:37 20020604_1.gz
-rw------- 1 amanda disk 2.9k Jun 5 21:49 20020605_1.gz
-rw------- 1 amanda disk 2.9k Jun 6 22:01 20020606_1.gz
-rw------- 1 amanda disk 2.9k Jun 7 22:46 20020607_1.gz
-rw------- 1 amanda disk 2.9k Jun 10 23:31 20020610_1.gz
-rw------- 1 amanda disk 2.9k Jun 12 02:16 20020611_0.gz
-rw------- 1 amanda disk 2.9k Jun 18 00:19 20020617_1.gz
-rw------- 1 amanda disk 2.9k Jun 18 23:46 20020618_1.gz
-rw------- 1 amanda disk 2.9k Jun 19 23:41 20020619_1.gz
[root]% zdiff 20020619_1.gz 20020618_1.gz
[root]% zdiff 20020619_1.gz 20020611_0.gz
[root]%
They are all the same, no difference between the level 0 and level 1 dumps.
> Next I'd look at /tmp/amanda/sendbackup*debug (on the client) for that
> "disk" and see if GNU tar is whining about anything. In particular,
> a problem being able to update the listed incremental file would cause
> the trouble you're seeing, although I would have thought those errors
> would at least have shown up as "STRANGE" in the Amanda report.
No, nothing to whine about that I see. Note however (see the ls above) that
/var/amanda/gnutar-lists/server_home_proj_bia-9584_0 is older than *_1. I
suppose that is because amanda renamed *_1.new to *._1.
[root]% cat /tmp/amanda/sendbackup.20020619232309.debug
sendbackup: debug 1 pid 25488 ruid 507 euid 507 start time Wed Jun 19
23:23:09 2002
/usr/libexec/sendbackup: version 2.4.2p2
sendbackup: got input request: GNUTAR /home/proj/bpa-9584 1
2002:6:12:8:57:52 OPTIONS
|;bsd-auth;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;
parsed request as: program `GNUTAR'
disk `/home/proj/bia-9584'
lev 1
since 2002:6:12:8:57:52
opt
`|;bsd-auth;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;'
sendbackup: exclude list file "/usr/local/lib/amanda/exclude.gtar" does not
exist, ignoring
sendbackup: try_socksize: send buffer size is 65536
sendbackup: stream_server: waiting for connection: 0.0.0.0.54744
sendbackup: stream_server: waiting for connection: 0.0.0.0.54745
sendbackup: stream_server: waiting for connection: 0.0.0.0.54746
waiting for connect on 54744, then 54745, then 54746
sendbackup: stream_accept: connection from 192.168.1.88.54747
sendbackup: stream_accept: connection from 192.168.1.88.54748
sendbackup: stream_accept: connection from 192.168.1.88.54749
got all connections
sendbackup-gnutar: doing level 1 dump as listed-incremental from
/var/amanda/gnutar-lists/server_home_proj_bia-9584_0 to
/var/amanda/gnutar-lists/server_home_proj_bia-9584_1.new
sendbackup-gnutar: doing level 1 dump from date: 2002-06-12 8:57:53 GMT
sendbackup: started index creator: "/bin/gtar -tf - 2>/dev/null | sed -e
's/^\.//'"
sendbackup: spawning /usr/libexec/runtar in pipeline
sendbackup: argument list: gtar --create --file - --directory
/home/proj/bia-9584 --one-file-system --listed-incremental
/var/amanda/gnutar-lists/server_home_proj_bia-9584_1.new --sparse
--ignore-failed-read --totals .
sendbackup-gnutar: /usr/libexec/runtar: pid 25494
sendbackup: index created successfully
sendbackup: pid 25488 finish time Wed Jun 19 23:41:09 2002
> Next I'd look for GNUTAR in /tmp/amanda/amandad*debug and see where
> the GNU tar is that Amanda is running, then run that exact path with
> --version to see which version of GNU tar is being used.
> Anything prior to 1.13.19 is evil in one way or another.
It's GNUTAR="/bin/gtar"
[root]% /bin/gtar --version
tar (GNU tar) 1.13.19
Copyright 2001 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public License;
see the file named COPYING for details.
Written by John Gilmore and Jay Fenlason.
[root]% grep bia amandad.20020619*debug
amandad.20020619165501.debug:GNUTAR /home/proj/bia-9584 0 OPTIONS
|;bsd-auth;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;
amandad.20020619165501.debug:OK /home/proj/bpa-9584
amandad.20020619210502.debug:GNUTAR /home/proj/bia-9584 0 1970:1:1:0:0:0 -1
exclude-list=/usr/local/lib/amanda/exclude.gtar
amandad.20020619210502.debug:GNUTAR /home/proj/bia-9584 1 2002:6:12:8:57:52
-1 exclude-list=/usr/local/lib/amanda/exclude.gtar
amandad.20020619210502.debug:GNUTAR /home/proj/bia-9584 2 2002:6:19:6:28:23
-1 exclude-list=/usr/local/lib/amanda/exclude.gtar
amandad.20020619210502.debug:/home/proj/bia-9584 0 SIZE 16919390
amandad.20020619210502.debug:/home/proj/bia-9584 1 SIZE 16919390
amandad.20020619210502.debug:/home/proj/bia-9584 2 SIZE 16919390
amandad.20020619232309.debug:GNUTAR /home/proj/bia-9584 1 2002:6:12:8:57:52
OPTIONS |;bsd-auth;index;exclude-list=/usr/local/lib/amanda/exclude.gtar;
I think this answers all the questions people sent me, and I still see
nothing wrong. I'm stumped!
Bart
--
Bart Brashers MFG Inc.
Air Quality Meteorologist 19203 36th Ave W Suite 101
[EMAIL PROTECTED] Lynnwood WA 98036-5707
http://www.mfgenv.com 425.921.4000 Fax: 425.921.4040
