Thanks for the info.  Your answer was right on target. That really helped and 
solved the issue.  I do have another issue about "failed to tape (will 
retry)".  This is an interesting message because I am running a tapeless 
backup.   There is no holding disk being used. I have about 36Gbs of storage 
space and am dumping 8Gb of data after compression.  I am not sure if this 
error message is due to something that can't be read on the clients or 
something to do with my setup.  This error message may lead to another 
question.  


On Saturday 06 January 2007 3:31 pm, you wrote:
> David Stillion wrote:
> > 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]
>
> 'dumps too big' means Amanda thinks that the size of a full dump of
> that filesystem is larger than the space available to dump it to.
> If runtapes = 1 or if tape spanning is not enabled, then it means
> your dump is larger than your tape length.  If runtapes > 1 and spanning
> is enabled, then it means dump > ( runtapes * tape lenght ).
>    What size is the filesystem and how big are your tapes (or vtapes)?
> If you think it should fit, either the estimate is wrong (check your
> logs for the estimated size), you are backing up more than you think
> (some tar versions incorrectly cross filesystem boundaries, or your
> excludes aren't what you think they are), or perhaps your config is
> not what you think it is .
>    The "can't incremental" part of the message just lets you know
> that while normally a lack of tape space would just cause Amanda to
> delay the full and do a smaller incremental instead, it can't do that
> in this case since there is no previous full dump to base the incremental
> on.
>
> Frank
>
> >  If you need more info let me know and I can send the entire amstatus
> > output.