On Tue, Nov 01, 2005 at 08:52:43PM +1100, Jeff Allison wrote:
> > >On Mon, 2005-10-31 at 09:18 -0400, Gene Heskett wrote:
> > >> On Monday 31 October 2005 07:13, Jeff Allison wrote:
>
> > >The biggest DLE is /home/samba which is 11GB uncompressed.
> > >
>
> > ISTR from a previous post of yours, your holding disk is smaller than
> > that, which forces amanda to do a direct to tape write.
>From the report below, this seems to be the case. /home/samba is not
listed as having dumped successfully, so it seems to have failed while
dumping direct to tape.
> DUMPER STATS TAPER STATS
> HOSTNAME DISK L ORIG-MB OUT-MB COMP% MMM:SS KB/s MMM:SS KB/s
> -------------------------- --------------------------------- ------------
> dalston / 1 102 102 -- 9:10 190.6 2:06 831.0
...
> dalston /home/samba 0 FAILED ---------------------------------------
Had it made it to the holding disk, it would have been listed under
DUMPER STATS.
Pulling a few other lines:
> USAGE BY TAPE:
> Label Time Size % Nb
> homes_06 0:57 3293M 28.2 12
So 12 DLE's made it to tape for a total of 3.3GB successful.
That matches your dump report sums.
> homes_07 0:00 0M 0.0 0
And of course nothing made it to this tape.
> NOTES:
> taper: tape homes_06 kb 11350144 fm 13 writing file:
> No space left on device
Tape hit EOT on the 13th DLE at 11.3 GB (?DDS3 tapes?) so 8GB
of /home/samba had been sent direct to tape when it hit EOT.
> taper: retrying dalston:/home/samba.0 on new tape:
> [writing file: No space left on device]
As discussed recently on the list, this message is a little
misleading as it sounds like the next tape hit EOT. It really
is just informational duplication saying the next tape is being
tried because the previous one hit EOT.
What interests me is the ".0" at the end of the DLE name. It
sounds like a holding disk file name. But my holding disks are
large so I've not seen 'direct to tape' references. Perhaps that
is just the normal form they take in reports.
> taper: tape homes_07 kb 0 fm 0 [OK]
To me, this says no taping was even tried. Question is why ...
> ... I'm currently suspecting the change-manual
> script as it seems to request the tape and write 0k to it then exit with
> connection reset error.
That is certainly one possibility. But I wonder if it instead it
is just an property of amanda's that a failed "direct to tape"
dump is not tried again in the same amdump run. Remember, this is
not just a retry of taping, but an entire redump of /home/samba.
As I noted, my dumps go to holding disk so I've not experienced
this situation. Perhaps someone can comment on whether a direct
to tape dump is, or is not, retried after failure.
One suggestion I might make is to get that /home/samba to tape.
It is trying a level 0 and as it now stands you will never get
it there. And the report shows your only level 0 is about to be
overwritten. For one run you might comment out the other 12 DLE's
in the disklist and dump only /home/samba. That will get it to
tape if it fits in 11.3GB. Newly labeled tapes could be used to
avoid overwriting the last level 0 on tape. No need to change any
other parameters, amanda will always be happy with new tapes, even
if more than tapecycle.
After that you /home/samba will be getting incrementals and you
will have a little time to explore the situation.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
