I believe I've solved the issue with the "planner: partial result". While it appeared Amanda was attempting to do the backup, it really couldn't because the disklist was misconfigured. My initial understanding on reading the docs was that I could use the device path ie /dev/hdaX to indicate what data I wanted to backup. When I changed these to a filesystem path /, ..../home and so forth, amdump was more successful.
However, I have a new error message for which I can not find any info. This message is part of the amstatus output for the set: planner: [dumps too big, 3319760 KB, but cannot incremental dump new disk] If you need more info let me know and I can send the entire amstatus output. Thanks On Friday 05 January 2007 8:57 pm, David Stillion wrote: > I did my first backup after installing Amanda and all seemed to go well > except there was only a little bit of data that was actually backed up. > > It appears that the planner was unable to determine the amount of data on > the 3 disks in the backup set. Here is an excerpt from the amdump log > file: > > SETTING UP FOR ESTIMATES... > planner: time 0.002: setting up estimates for buster.zone64.net:/dev/hda2 > buster.zone64.net:/dev/hda2 overdue 13519 days for level 0 > setup_estimate: buster.zone64.net:/dev/hda2: command 0, options: none > last_level -1 next_level0 -13519 level_days 0 getting estimates 0 (-2) > -1 (-2) -1 (-2) > planner: time 0.003: setting up estimates for buster.zone64.net:/dev/hda3 > buster.zone64.net:/dev/hda3 overdue 13519 days for level 0 > setup_estimate: buster.zone64.net:/dev/hda3: command 0, options: none > last_level -1 next_level0 -13519 level_days 0 getting estimates 0 (-2) > -1 (-2) -1 (-2) > planner: time 0.003: setting up estimates for buster.zone64.net:/dev/hda6 > buster.zone64.net:/dev/hda6 overdue 13519 days for level 0 > setup_estimate: buster.zone64.net:/dev/hda6: command 0, options: none > last_level -1 next_level0 -13519 level_days 0 getting estimates 0 (-2) > -1 (-2) -1 (-2) > planner: time 0.003: setting up estimates took 0.000 secs > > GETTING ESTIMATES... > driver: pid 4883 executable /usr/libexec/driver version 2.4.5 > driver: tape size 4096000 > driver: send-cmd time 0.005 to taper: START-TAPER 20070105 > driver: adding holding disk 0 dir /data/amanda/tmp/dumps size 35059852 > chunksize 512000 > reserving 35059852 out of 35059852 for degraded-mode dumps > driver: started dumper0 pid 4885 > driver: started dumper1 pid 4886 > driver: started dumper2 pid 4887 > planner: time 0.049: got partial result for host buster.zone64.net > disk /dev/hda6: 0 -> -2K, -1 -> -2K, -1 -> -2K > planner: time 0.050: got partial result for host buster.zone64.net > disk /dev/hda3: 0 -> -2K, -1 -> -2K, -1 -> -2K > planner: time 0.050: got partial result for host buster.zone64.net > disk /dev/hda2: 0 -> -2K, -1 -> -2K, -1 -> -2K > > So far I've found this issue talked about by one other user. She said it > was a problem with the version of tar she was using. She is running RHEL4. > I'm running Gentoo 2006.0 on both my server and workstation. Has anyone > else run into this problem? > > Let me know and thanks.
