Nothing backed up - planner error

[PCrighton]

Using Centos 4.4 / amanda 2.4.4p3 (that's the version that comes with Centos) Amanda is failing to back up my files. I thought I'd edited everything and amcheck passes.

The failure is logged in amdump. Here's an extract:

planner: time 1.102: got result for host localhost disk /mnt/server60g/Bin: 0 -> -1K, -1 -> -1K, -1 -> -1K
planner: time 1.102: getting estimates took 1.098 secs
FAILED QUEUE:
0: localhost /mnt/server60g/Bin
DONE QUEUE: empty

ANALYZING ESTIMATES...
planner: FAILED localhost /mnt/server60g/Bin 20061018 0 [disk /mnt/server60g/Bin, all estimate failed]
INITIAL SCHEDULE (size 64):

amanda has read access to the Bin directory that I am testing amanda with and there are four small files in there.

I've got over most problems using the amanda.org site (which incidentally has disappeared) and the zmanda wiki but am stuck with this one. Help please!

[paddy]

Please take a look at the /tmp/amanda/sendsize* logs for errors. It will be better if you
could upgrade to 2.5.X releases.

Paddy

[PCrighton]

Here's the contents of the sendsize debug file:

sendsize: debug 1 pid 6848 ruid 33 euid 33: start at Wed Oct 18 10:02:00 2006
sendsize: version 2.4.4p3
sendsize[6850]: time 0.008: calculating for amname '/mnt/server60g/Bin', dirname '/mnt/server60g/Bin', spindle -1
sendsize[6850]: time 0.008: getting size via dump for /mnt/server60g/Bin level 0
sendsize[6850]: time 0.014: calculating for device '/mnt/server60g/Bin' with ''
sendsize[6850]: time 0.015: running "/sbin/dump 0Ssf 1048576 - /mnt/server60g/Bin"
sendsize[6850]: time 0.018: running /usr/lib/amanda/killpgrp
sendsize[6848]: time 0.020: waiting for any estimate child: 1 running
sendsize[6850]: time 0.047: /dev/hdb5: Bad magic number in super-block while opening filesystem
sendsize[6850]: time 0.048: DUMP: The ENTIRE dump is aborted.
sendsize[6850]: time 0.048: .....
sendsize[6850]: estimate time for /mnt/server60g/Bin level 0: 0.033
sendsize[6850]: no size line match in /sbin/dump output for "/mnt/server60g/Bin"
sendsize[6850]: .....
sendsize[6850]: estimate size for /mnt/server60g/Bin level 0: -1 KB
sendsize[6850]: time 0.049: asking killpgrp to terminate
sendsize[6850]: time 1.050: done with amname '/mnt/server60g/Bin', dirname '/mnt/server60g/Bin', spindle -1
sendsize[6848]: time 1.050: child 6850 terminated normally
sendsize: time 1.051: pid 6848 finish time Wed Oct 18 10:02:02 2006


What does "Bad magic number mean?". It's a FAT32 (vfat mount) folder.

I may upgrade later - this is a test install and I plan to replace the hard disks, add RAID etc. and probably to re-install Centos and at that time plan to upgrade any applications, such as Amanda, that are out of date. I presume that 2.4.4 should work fine, and that any learning curve on this version will enable me to get the latest version working quickly.

[paddy]

The error means dump does not support the filesystem. Linux dump command supports only ext2/ext3 filesystems.

Paddy

[PCrighton]

Thanks for the help so far. I've now changed my disklist to backup /home/root and /home/peter. I have changed the access permissions so that amanda user has access (chmod 705). I thought amanda had full access to the disks though?

Before changing permissions amanda could not view the directories, but afterwards can so the change is successful. Is there an alternative to making users files visible to all though?

Sendsize now calculates sizes for each directory.

I'm getting further: the next error occurs in the sendbackup.xxx.debug file:

sendbackup: debug 1 pid 7490 ruid 33 euid 33: start at Fri Oct 20 09:42:45 2006
/usr/lib/amanda/sendbackup: version 2.4.4p3
parsed request as: program `DUMP'
disk `/home/root'
device `/home/root'
level 0
since 1970:1:1:0:0:0
options `|;bsd-auth;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.33049
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.33050
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.33051
sendbackup: time 0.005: waiting for connect on 33049, then 33050, then 33051
sendbackup: time 0.005: stream_accept: connection from 127.0.0.1.33052
sendbackup: time 0.005: stream_accept: connection from 127.0.0.1.33053
sendbackup: time 0.005: stream_accept: connection from 127.0.0.1.33054
sendbackup: time 0.005: got all connections
sendbackup: time 0.011: dumping device '/home/root' with ''
sendbackup: time 0.014: started index creator: "/sbin/restore -tvf - 2>&1 | sed -e '
s/^leaf[ ]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
sendbackup: time 0.014: spawning /sbin/dump in pipeline
sendbackup: argument list: dump 0usf 1048576 - /home/root
sendbackup: time 0.031: 93: normal(|): DUMP: You can't update the dumpdates file when dumping a subdirectory
sendbackup: time 0.032: 93: normal(|): DUMP: The ENTIRE dump is aborted.
sendbackup: time 0.099: index created successfully
sendbackup: time 0.101: error [/sbin/dump returned 1]
sendbackup: time 0.101: pid 7490 finish time Fri Oct 20 09:42:45 2006

DUMP is aborting the dump....

[paddy]

You can dump only filesystems. You can use Gnutar as program to backup
directories.

See Amanda wiki troubleshooting (http://wiki.zmanda.com/index.php/Amdump:_/sbin/dump_returned_1) section for more on this error message.

Thanks,
Paddy

[PCrighton]

Many thanks for your help - got amanda to backup and restore some files, so it's working now