RE: Suggestions Please -- help!
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 100594 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
RE: Suggestions Please -- help!
--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 100594 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
