--On Thursday, June 20, 2002 12:36:38 -0600 "Brashers, Bart -- MFG, Inc."
<[EMAIL PROTECTED]> wrote:
>
>> > 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
The file has the format:
filesystem level date(using unix time, i.e. seconds since 1-1-1970)
For your file, your last level 0 was Wed Jun 12 03:57:53 2002,
level 1 - Thu Jun 20 01:23:09 2002
level 2 - Mon Nov 26 23:08:23 2001
level 3 - Thu Oct 4 14:09:54 2001
Those are the times converted to my timezone, but show that it thinks
it is doing a level 1.
>> 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;
For some reason the level 1 (and 2) tars estimate the same size as a level
one. Id suggest you experiment running tar manually with all the options
Amanda uses (as in the /tmp/amanda/files) and try to see why tar thinks all
the files are new. Possibly try the 1.13.25 from alpha.gnu.org.
> 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
Good luck,
Frank
--
Frank Smith [EMAIL PROTECTED]
Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
