On Monday 14 March 2005 08:59, Mark Lidstone wrote:
>Hi all,
>
>I've had a search through the FAQ, generally on the 'net and through
> the list archives, but I can't seem to find anyone else reporting
> similar symptoms to me, so here I go with my first post to the
> list. If I've made a mistake, please be gentle...
>
>I have a Linux box at another site. It's running Amanda 2.4.4p2 and
> is plugged into a Compaq DDS4 drive.
>
>Partway through a full nightly backup I'm getting the following
> email
>
>back:
>> These dumps were to tape Haslar12.
>> *** A TAPE ERROR OCCURRED: [[writing file: No space left on
>> device]]. Some dumps may have been left in the holding disk. Run
>> amflush to flush them to tape. The next tape Amanda expects to use
>> is: Haslar14.
>>
>> FAILURE AND STRANGE DUMP SUMMARY:
>> olympic /samba/company lev 0 FAILED [out of tape]
>> olympic /samba/company lev 0 FAILED ["data write: Connection
>
>reset by
>peer"]
>
>> olympic /samba/company lev 0 FAILED [dump to tape failed]
>>
>>
>> STATISTICS:
>> Total Full Daily
>> -------- -------- --------
>> Estimate Time (hrs:min) 0:00
>> Run Time (hrs:min) 5:07
>> Dump Time (hrs:min) 1:10 1:10 0:00
>> Output Size (meg) 5208.7 5208.7 0.0
>> Original Size (meg) 8918.1 8918.1 0.0
>> Avg Compressed Size (%) 58.4 58.4 --
>> Filesystems Dumped 4 4 0
>> Avg Dump Rate (k/s) 1272.8 1272.8 --
>>
>> Tape Time (hrs:min) 1:10 1:10 0:00
>> Tape Size (meg) 5208.7 5208.7 0.0
>> Tape Used (%) 27.0 27.0 0.0
>> Filesystems Taped 4 4 0
>> Avg Tp Write Rate (k/s) 1274.0 1274.0 --
>>
>> USAGE BY TAPE:
>> Label Time Size % Nb
>> Haslar12 1:10 5208.7 27.0 4
>>
>>
>> FAILED AND STRANGE DUMP DETAILS:
>>
>> /-- olympic /samba/company lev 0 FAILED ["data write:
>> Connection
>
>reset
>by peer"]
>
>> sendbackup: start [olympic:/samba/company level 0]
>> sendbackup: info BACKUP=/bin/tar
>> sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
>> sendbackup: info COMPRESS_SUFFIX=.gz
>> sendbackup: info end
>> \--------
>>
>>
>> NOTES:
>> taper: tape Haslar12 kb 16875296 fm 5 writing file: No space
>> left on
>
>device
>
>> DUMP SUMMARY:
>> DUMPER STATS TAPER
>
>STATS
>
>> HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s
>> MMM:SS
>
>KB/s
>
>> -------------------------- ---------------------------------
>
>------------
>
>> olympic /etc/ 0 35090 10956 31.2 0:22 507.0
>
>0:052276.1
>
>> olympic /home 0 90793005319769 58.6 69:241277.4
>
>69:251277.4
>
>> olympic -ba/company 0 FAILED
>
>---------------------------------------
>
>> olympic -a/netlogon 0 10 1 10.0 0:00 0.0
>> 0:13
>
>0.1
>
>> olympic /var/log 0 17730 2938 16.6 0:04 702.6
>> 0:04
>
>786.5
>
>> (brought to you by Amanda version 2.4.4p2)
>
>Now, if I'm reading this right, it's saying that it's hit the end of
> a 20Gb tape at around the 5Gb mark. Here's what I think are the
> relevant parts of my amanda.conf:
>
>tapetype HP-DDS-4
>
>define tapetype HP-DDS-4 {
> comment "just produced by tapetype prog (hardware compression
>on)"
> length 17021 mbytes
> filemark 403 kbytes
> speed 1578 kps
>}
>
>(Some of you may recognise this - provided by rnaydenov on the
> Amanda site).
>
>I'm wondering about a faulty tape drive or tapes?
>
>Any help would be greatly appreciated,
>
>Mark Lidstone
>IT and Network Support Administrator
[snip legal disclaimer nobody pays any attention to anyway]
My first guess is that somewhere along the line, you've got some old
DDS2 tapes mixed into the stack somehow.
Go back to that exact tape (its not much good for a backup anyway) and
run an 'amtapetype -e 20GB -f /dev/whatever-it-is'. With hardware
compression on, you should get about what you have in your
amanda.conf.
Please note that the majority of us usually recommend the hardware
compression be turned off, in which case you'll get a bit less, the
lower of the two capcities the marketroids like to claim. But in
some instances you will get a lot more than 20GB of data stored
because gzip is more efficient than the hardware compressors. Last
night here, for instance:
Output Size (meg) 7303.0 6632.4 670.6
Original Size (meg) 16943.6 15064.9 1878.7
Avg Compressed Size (%) 36.1 36.2 35.0 (level:#disks)
This with a tapetype set for about 8GB. No problem. Expand that to a
10GB tapetype, and you can see that over 20GB would have fit after
gzip munched on it a while. Conversely, some other nights run may
have been most of my tar.gz's etc, and only 13GB would have fit. But
amanda would have been happy in either event.
We do this because amanda counts bytes sent down the cable, which if
using software compression, is after the compression, so it knows to
within a percent or so, exactly how much a tape can hold. When
hardware is in use, amanda has no idea how much tape has been used
because the commpression depends very much on the kind of data, and
you must set the size down somewhat so that amanda can handle what it
thinks will be an overflow with a bit more grace.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.34% setiathome rank, not too shabby for a WV hillbilly
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.
|
