>I've got amanda configured to dump to 2 tape devices /dev/nst0 and /dev/nst1.
>See conf below. ...
The configuration looks basically correct. The fact that the report says
"The next 2 tapes ..." says Amanda is seeing that you could use two tapes.
>The problem is that amanda writes to one tape on the first da
>y, and then to the next tape on the second day, repeating. ...
You've brought up two issues and I'll tackle the easy one first.
Just because you told Amanda "runtapes 2" does not mean that it will
use two tapes every day. The "runtapes" value is an upper limit, not
a mandatory value.
Since your backups fit on one tape (ignoring the problem of why it didn't
do all of them for the moment), there was no need to use the second tape,
and so it is next in line for the following run.
Now for the harder problem: why Amanda isn't doing all the dumps.
>ns0 /export lev 1 FAILED [dumps way too big, must skip incremental dumps]
Here's a quick summary of how planner works. First, it figures out what
dump levels might be used for every disk. If you've done a "force", for
instance, then only a full dump is possible. Same if it's a new disk.
Otherwise it will find out about the same incremental level as the
previous run and possibly the next level.
Once it has all that data, it picks the "preferred" level for each
disk and sees how much tape that will take. Then if there is too much
data to fit on the amount of tape space (two tapes times ~30 GBytes,
in your case), it will delay dumps (full dumps turn into incrementals,
some incrementals are deferred until the next run). Finally, if there
is space left over, it may promote some incrementals to full dumps to
balance things.
The message you got says that planner had delayed as much as it could
(full -> incremental) but even the incrementals of these file systems
would have been too large to fit on tape (which implies they are over
30 GBytes -- maybe).
About the only way that could happen given that you actually wrote about
one tape worth and should have had another 30 GBytes to play with is if
the estimates were very large. So now you need to dig into the amdump.NN
file and see what planner had to work with.
First, find the lines that look like this:
setting up estimates for fortress.cc.purdue.edu:/opt
setup_estimate: fortress.cc.purdue.edu:/opt: command 0, options:
last_level 2 next_level0 0 level_days 2
getting estimates 0 (740255) 2 (50879) -1 (-1)
This is for /opt on machine fortress.cc.purdue.edu. The last line
says planner asked for the size of a level 0 and the size of a level 2.
The number in parenthesis is the size from the previous run at that level
(I think -- I didn't dig into the code that deep).
Later on you'll see the result come back:
got result for host fortress.cc.purdue.edu disk /opt: 0 -> 654573K, 2 -> 78630K, -1
-> -1K
which says the estimate is ~650 MBytes for a level 0 and ~79 MBytes for a
level 2.
Further on you'll see this:
pondering fortress.cc.purdue.edu:/opt...
curr level 0 size 654573 total size 3492574 ...
This says it decided to try a level 0 and the total tape size so far,
including this level 0, is ~3.5 GBytes. If you look closely at the
numbers, don't forget the 32 KByte header and tape mark size (33 KBytes,
in your case) which get included for every image.
Next you'll see an "INITIAL SCHEDULE", which includes a size value showing
how much would be dumped if this were the final result.
Next you'll see the section on "DELAYING DUMPS", which will tell you the
estimated tape usage before doing anything, the total tape space available
(which should be ~60 GBytes) and the tape mark size. Then you'll probably
see a bunch of lines explaining why various file systems are being delayed
from what the initial idea was.
So, some things for you to look for:
* Are the estimate values reasonable from all your file systems, in
particular ns0:/export and ns1:/export?
* What is the size reported for the "INITIAL SCHEDULE"? How does it
relate to your two tape capacity (~60 GBytes)?
* Are all the tape values correct on the "DELAYING DUMPS" line?
* How did the delaying go? Does it look like it tried to do reasonable
things? Did it have enough to work with, i.e. would delaying full
dumps to incrementals and then incrementals to the next run eventually
win the battle?
>William
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
