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.
|
