I've been a proponent of dump for years but I'm looking to move to
gnu tar for one disk. Amanda fails with dump on just this disk when
it tries to do a level 0 backup.
/-- Odin /home lev 1 FAILED [/sbin/dump returned 3, compress got signal 24]
sendbackup: start [Odin:/home level 1]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/bin/gzip -dc |/sbin/restore -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| DUMP: Date of this level 1 dump: Sat Jan 5 02:00:00 2002
| DUMP: Date of last level 0 dump: Wed Dec 12 02:00:00 2001
| DUMP: Dumping /dev/sdb1 (/home) to standard output
| DUMP: Added inode 7 to exclude list (resize inode)
| DUMP: Label: none
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 7985435 tape blocks.
| DUMP: Volume 1 started with block 1 at: Sat Jan 5 02:01:14 2002
| DUMP: dumping (Pass III) [directories]
| DUMP: dumping (Pass IV) [regular files]
| DUMP: 7.89% done at 2100 kB/s, finished in 0:58
| DUMP: 16.43% done at 2186 kB/s, finished in 0:50
? sendbackup: index tee cannot write [Broken pipe]
| DUMP: Broken pipe
| DUMP: The ENTIRE dump is aborted.
? index returned 1
sendbackup: error [/sbin/dump returned 3, compress got signal 24]
\--------
If I take out compression for this disk all is fine (I'm doing the gzip
on the client (machine with the disk). It's an amanda problem of some
sort but I have given up trying to fix it (started happening when I
cranked down the dumpcycle to try and squeeze a set of archivals onto
fewer tapes. It'd happened once months before but went away by itself).
So I switch the dumptype on this one disk to:
define dumptype tcomp-u-s2 {
global
comment "User partitions on reasonably fast machines, start 2am, gnutar"
priority medium
program "GNUTAR"
starttime 200
}
amcheck runs fine. But when I do the amdump I don't get an estimate.
Here's the lines from the amdump file:
setting up estimates for Odin:/home
setup_estimate: Odin:/home: command 0, options:
got result for host Odin disk /home: 0 -> -1K, 1 -> -1K, -1 -> -1K
0: Odin /home
planner: FAILED Odin /home 0 [disk /home offline on Odin?]
And sendsize.20020116210824.debug on the client:
/usr/local/pkg/amanda-2.4.2p2/libexec/sendsize: version 2.4.2p2
calculating for amname '/', dirname '/'
calculating for amname '/boot', dirname '/boot'
sendsize: getting size via dump for / level 0
calculating for amname '/home', dirname '/home'
calculating for amname '/usr', dirname '/usr'
sendsize: getting size via dump for /boot level 0
sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda8"
sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda1"
running /usr/local/pkg/amanda-2.4.2p2/libexec/killpgrp
running /usr/local/pkg/amanda-2.4.2p2/libexec/killpgrp
sendsize: getting size via dump for /usr level 0
sendsize: getting size via gnutar for /home level 0
sendsize: running "/sbin/dump 0Ssf 1048576 - /dev/sda5"
running /usr/local/pkg/amanda-2.4.2p2/libexec/killpgrp
calculating for amname '/var', dirname '/var'
sendsize: spawning /usr/local/pkg/amanda-2.4.2p2/libexec/runtar in pipeline
sendsize: argument list: /bin/gtar --create --file /dev/null --directory /home
--one-file-system --listed-in
cremental /usr/local/pkg/amanda-2.4.2p2/var/amanda/gnutar-lists/Odin_home_0.new
--sparse --ignore-failed-rea
d --totals .
runtar: error [must be invoked by operator]
.....
(no size line match in above gnutar output)
.....
I'm running amanda 2.4.2p2 on both client and server. OSs are Linux,
kernels are 2.4.12. gnu tar is 1.13.25, dump is 0.4b25 on both.
I'm backing up 30 machines and 75 disks. Client OSs are Solaris,
HP-UX, IRIX and Linux. The only thing I changed when the dump on
the one disk started failing was dumpcycle. Since amanda can handle
things if I tell that one disk NOT to compress that tells me that it's
an amanda problem rather than dump.
Help appreciated. Wither getting dump woking with compression again
or getting gnutar to work.
--
[EMAIL PROTECTED] - HMC UNIX Systems Manager
My opinions are my own and probably don't represent anything anyway.
