Hi Paul!
Paul Bijnens wrote:
...
The problem here is that when you had a real tape error, and then try
to flush o a new tape, then amanda refuses to put that one tape, because
it got an error last time? Not good. So how you do see if you got
a real error or just EOT. Explain me, because I surely want to know.
AFAICT most drivers do not distinguish between write error or EOT.
(At least that is my experience.)
I think we discussed the EOT versus real tape error here some weeks ago ...
O.k. maybe I expect a little to much guessing - my thought was, that the
image that failed last time gets sheduled at the end, not recoginsed in the
choosing and ordering process for each flush, so if the flush is done, the
others have there chance.
If a tape error was the reason why the flush failed, the following
run - expecting the next tape is o.k. - will work anyway, anly
the order of the images on tape is changed. But if the image was the
reason why the flush failed, all the other images may move to tape, and
the error on will propably trigger its error again.
Size may not be the only reason why the image failes to tape - there may
be a hardware error e.g. disk or controller which prevents it from taping
- would be a bad thing anyway - but especially in such situations it would
be fine if at least the rest is taped.
Another problem in the flush stategy is mentioned in a reply of Matt
Hyclak:
The top level criteria for ordering the images to flush seems to be the
date.
As in my case, where one big image left over from a ambackup run, all
following ambackup runs produce 2rd and 3rd level backups to fit into the
remaining holding disk.
The flush runs, either triggered by ambackup or manually continue to try
the one big image becaus its from an older ambackup run ....
Bye, Peter
WOTLmade
|
