Jurgen Pletinckx schrieb:
> I'm trying to revive an installation of amanda 2.4.2 which has
> been left unattended for quite a while. I've flushed whatever
> was in the holding disks to tape, cleaned up the remaining 
> cruft, and, very tentatively, started amdump.
> 
> Rather to my surprise, that seems to work. Several disks
> from several hosts have been written to tape, and more are
> waiting. I will verify what is actually on tape, but it sure
> looks good.

What did you expect from amanda?

;)

> Except for the following types of failures, that is: 
> deepskyblue:/dev/xlv/xlv1                0 [dumps too big, but cannot
> incremental dump skip-incr disk]
> deepskyblue:/dev/xlv/xlv2                0 [dump larger than tape, but
> cannot incremental dump skip-incr disk]
> 
> Now, the current state of these disks is
> Filesystem             Type  kbytes     use     avail  %use Mounted on
> /dev/xlv/xlv2           xfs 71124192 57681676 13442516  82  /xlv2
> /dev/xlv/xlv1           xfs 71124160 57826144 13298016  82  /xlv1
> 
> but they were larger at the time I started amdump. (Yes, I'm doing
> a bit of spring-cleaning on the disks, while waiting for amdump to
> continue). However, they were well under 65G. I would therefore expect
> 
> them to fit on the 70G tapes I'm using.

I assume you have other DLEs in your config as well.
The message only tells you "in this run these DLEs wouldn't fit onto
tape anymore (in sum with the other DLEs) and I *have* to do a
level0(=full)-backup at first". This is perfectly OK for a first run of
a config.

> Is this a problem that will disappear after a few more amdump runs?
> I.e., the planner just gets the other partitions out of the way first.

Kind of. You should see a lev0 of those DLEs soon.

> Or should I expect to have to alter the disklist, in order to split
> the contents of these large disks over different dumps? 

You could do that, depends on your overall volume to dump and its
relation to your num of tapes and their size.

I would wait for the next runs.

S