On Wednesday 28 December 2005 11:25, Geert Uytterhoeven wrote:
> Hi all,
>
>Is anyone else using vtapes with runtapes > 1?
>
>Recently I decreased tapelength and increased runtapes from 1 to 2.
>On most days 1 vtape is sufficient. But every time Amanda hits
> (artificial as specified by tapetype) end of tape on a vtape and
> retries on the second tape,
>
>she fails with:
>|*** THE DUMPS DID NOT FINISH PROPERLY!
>|
>|These dumps were to tapes DAILY14, DAILY15.
>|The next 2 tapes Amanda expects to used are: DAILY16, DAILY17.
>|
>|FAILURE AND STRANGE DUMP SUMMARY:
>| anakin /usr/share lev 3 FAILED ["data write: Connection reset
>| by peer"]
>|
>|USAGE BY TAPE:
>| Label Time Size % Nb
>| DAILY14 0:10 3058470k 100.2 20
>| DAILY15 0:00 0k 0.0 0
>|
>|FAILED AND STRANGE DUMP DETAILS:
>|
>|/-- anakin /usr/share lev 3 FAILED ["data write: Connection
>| reset by peer"] sendbackup: start [anakin:/usr/share level 3]
>|sendbackup: info BACKUP=/bin/tar
>|sendbackup: info RECOVER_CMD=/bin/gzip -dc |/bin/tar -f... -
>|sendbackup: info COMPRESS_SUFFIX=.gz
>|sendbackup: info end
>|
>|NOTES:
>| taper: tape DAILY14 kb 3071968 fm 21 writing file: No space left
>| on device taper: retrying anakin:/usr/share.3 on new tape: [writing
>| file: No space left on device]
>
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Sometimes I get `[writing file: short write]' here instead.
>
>| taper: tape DAILY15 kb 0 fm 0 [OK]
>|
>|DUMP SUMMARY:
>| DUMPER STATS
>| TAPER STATS HOSTNAME DISK L ORIG-kB
>| OUT-kB COMP% MMM:SS KB/s MMM:SS KB/s
>| ---------------------------------
>| ------------------------------------------- --------------- anakin
>| /usr/share 3 FAILED
>| ----------------------------------------------------
>
>The first vtape contains all succesfully backed up DLEs, and a part
> of the failed DLE.
>
>The second vtape always contains the tape header and the tape end
> only,
>
>but no evidence of the retried DLE:
>| # ls -l
>| total 72
>| -rw------- 1 backup backup 10 Dec 28 00:57 00000-DAILY15
>| -rw------- 1 backup backup 32768 Dec 28 00:57 00000.DAILY15
>| -rw------- 1 backup backup 10 Dec 28 00:57 00001-TAPEEND
>| -rw------- 1 backup backup 32768 Dec 28 00:57 00001.TAPEEND
>| #
>
>/tmp/amanda/sendbackup.20051228005526.debug doesn't contain any
> clues, just `strange(?): gzip: stdout: Connection reset by peer'
> instead of the usual `size(|): Total bytes written ...'.
>
>I'm using Amanda 2.4.5-2 (from Debian testing) and tpchanger
> "chg-disk" with the `file:' driver.
>
>Any one with a clue? Thanks!
>
>I guess for now I'll fall back to using `runtapes 1' and very large
> tape lengths, so all daily backups will fit on one tape (until my
> vtape partition fills up, of course)...
ISTR I had a similar problem Geert, but that was because I'd somehow
disabled my holding disk when I converted to vtapes. Fixing the
holding disk up fixed that up, but then I reduced my runtapes back to
1, and then adjusted the dumpcycle days until its doing about 90% of
the tapesize each time, and the partition the vtapes is on stays
somewhere between 80% and 95% full, with 21 vtapes, a 4 day dumpcycle,
and a bit less than 8Gbytes for the tapesize. Its been running at 82%
for the last 2-3 months. I go clean out /usr/src when it steadily
runs that partition above 95%. By then I've probably got 4GB in
kernel trees alone.
Don't be allergic to fine tuning the tapesizes and dumpcycles so that
you are making the best use of the resources available.
>Gr{oetje,eeting}s,
>
> Geert
>
>--
>Geert Uytterhoeven -- There's lots of Linux beyond ia32 --
> geert AT linux-m68k DOT org
>
>In personal conversations with technical people, I call myself a
> hacker. But when I'm talking to journalists I just say "programmer"
> or something like that. -- Linus Torvalds
--
Cheers, Gene
People having trouble with vz bouncing email to me should add the word
'online' between the 'verizon', and the dot which bypasses vz's
stupid bounce rules. I do use spamassassin too. :-)
Yahoo.com and AOL/TW attorneys please note, additions to the above
message by Gene Heskett are:
Copyright 2005 by Maurice Eugene Heskett, all rights reserved.
|
