Re: Failed dumps with new amanda client
On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
Here's the complete report, now that it finally finished:
su-2.05a$ amtapetype -f /dev/nrsa0
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 24034 mbytes
filemark 81 kbytes
speed 1530 kps
}
Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
Yep, which means it's not an amanda issue. And I have no idea why it's
doing that. Good luck with it. ;)
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
Re: Failed dumps with new amanda client
On Wed, Jun 21, 2006 at 08:23:57AM -0400, Joshua Baker-LePain wrote:
On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
Here's the complete report, now that it finally finished:
su-2.05a$ amtapetype -f /dev/nrsa0
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 24034 mbytes
filemark 81 kbytes
speed 1530 kps
}
Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
Yep, which means it's not an amanda issue. And I have no idea why it's
doing that. Good luck with it. ;)
24GB, that is just about where it ran out during amdump too.
I've no idea either; just a possible coincidence.
In my tapechart DLT IV tape is shown as 1800 inches long
while DLT III tape is 1200 inches long.
That ratio , 1200/1800 is pretty close to the
24GB (observed)/35GB (expected) ratio.
Any chance these are just short tapes?
For all I know about DLT, the physical cartridge may have
changed between DLT III and DLT IV so my question is silly.
I note your speed is pretty low compared to my chart listing,
1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed?
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Failed dumps with new amanda client
On Wed, 21 Jun 2006, Jon LaBadie wrote:
On Wed, Jun 21, 2006 at 08:23:57AM -0400, Joshua Baker-LePain wrote:
On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
Here's the complete report, now that it finally finished:
su-2.05a$ amtapetype -f /dev/nrsa0
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 24034 mbytes
filemark 81 kbytes
speed 1530 kps
}
Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
Yep, which means it's not an amanda issue. And I have no idea why it's
doing that. Good luck with it. ;)
24GB, that is just about where it ran out during amdump too.
I've no idea either; just a possible coincidence.
In my tapechart DLT IV tape is shown as 1800 inches long
while DLT III tape is 1200 inches long.
That ratio , 1200/1800 is pretty close to the
24GB (observed)/35GB (expected) ratio.
Any chance these are just short tapes?
If so, I've been defrauded...they are clearly stamped FujiFilm DLT IV
For all I know about DLT, the physical cartridge may have
changed between DLT III and DLT IV so my question is silly.
I note your speed is pretty low compared to my chart listing,
1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed?
Not sure...I noticed the speed as well. I had raised the conf parameter:
From: netusage 1600 Kbps
To:netusage 7200 Kbps
I can't recall if that's bits or bytes (small b should be bits, right?).
But I'll try raising it alot more, since all dumps are over 100mbit
ethernet.
James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]
http://3.am
=
Re: Failed dumps with new amanda client
On Wed, 21 Jun 2006 at 11:23am, [EMAIL PROTECTED] wrote On Wed, 21 Jun 2006, Jon LaBadie wrote: I note your speed is pretty low compared to my chart listing, 1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed? Not sure...I noticed the speed as well. I had raised the conf parameter: From: netusage 1600 Kbps To:netusage 7200 Kbps I can't recall if that's bits or bytes (small b should be bits, right?). But I'll try raising it alot more, since all dumps are over 100mbit ethernet. That parameter is only a guide to amanda. If amanda sees that the current backups coming over the network are using more than 'netusage' bandwidth, it won't start another one. But it doesn't throttle running backups to fit within netusage. Besides that, amtapetype only showed the slow speed. That means the cause has to be your tape drive, tapes, or the SCSI chain the tape drive is on. Those are the only things involved in running amtapetype. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Failed dumps with new amanda client
On Wed, Jun 21, 2006 at 11:23:28AM -0400, [EMAIL PROTECTED] wrote:
On Wed, 21 Jun 2006, Jon LaBadie wrote:
On Wed, Jun 21, 2006 at 08:23:57AM -0400, Joshua Baker-LePain wrote:
On Tue, 20 Jun 2006 at 10:59pm, [EMAIL PROTECTED] wrote
Here's the complete report, now that it finally finished:
su-2.05a$ amtapetype -f /dev/nrsa0
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 24034 mbytes
filemark 81 kbytes
speed 1530 kps
}
Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
Yep, which means it's not an amanda issue. And I have no idea why it's
doing that. Good luck with it. ;)
24GB, that is just about where it ran out during amdump too.
I've no idea either; just a possible coincidence.
In my tapechart DLT IV tape is shown as 1800 inches long
while DLT III tape is 1200 inches long.
That ratio , 1200/1800 is pretty close to the
24GB (observed)/35GB (expected) ratio.
Any chance these are just short tapes?
If so, I've been defrauded...they are clearly stamped FujiFilm DLT IV
For all I know about DLT, the physical cartridge may have
changed between DLT III and DLT IV so my question is silly.
I note your speed is pretty low compared to my chart listing,
1.5 vs 5.0 MB/sec. Is DLT capacity affected by slow feed?
Not sure...I noticed the speed as well. I had raised the conf parameter:
From: netusage 1600 Kbps
To:netusage 7200 Kbps
I can't recall if that's bits or bytes (small b should be bits, right?).
But I'll try raising it alot more, since all dumps are over 100mbit
ethernet.
You are not running amtapetype across a network,
so the dump network usage parameter has no impact.
It is how fast your system can feed your tapedrive.
I'd look into your scsi system, check system logs for errors, try the
usual culprits, cables, terminators, ... Even with a mediocre scsi
card I can drive my lto-1 at about 90% of its rated speed. Even with
the ancient card I was first using I was getting nearly 7 MB/sec.
Something seems amiss with your setup.
--
Jon H. LaBadie [EMAIL PROTECTED]
JG Computing
4455 Province Line Road(609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
Re: Failed dumps with new amanda client
On Tue, 20 Jun 2006 at 10:35am, [EMAIL PROTECTED] wrote On Mon, 19 Jun 2006, Joshua Baker-LePain wrote: I'd be awfully suspicious that you're running with hardware compression enabled (quite possibly unbeknownest to you). That doesn't really make sense to me...if that were the case, wouldn't it affect all of the clients? In any case, I manually turn off the hardware compression before every backup. One thing that has me curious is this: Yes, it would affect all the clients. All the (already) compressed data going to tape would be hardware compressed by the drive, making it expand and take up more tape space. Therefore, even though amanda only saw ~25GB go to tape, on tape it took up the whole 35GB. The error you got (short write) typically means you hit EOT. That happened on one particular client, and so that particular client failed. I don't have any experience with DLT, but I've heard tell that with some drives turning off hardware compression isn't always easy. Avg Dump Rate (k/s) 1491.9 1491.9-- Tape Time (hrs:min)4:00 4:00 0:00 That speed looks a bit slow for a DLT7000...closer to what you'd expect from a DLT4000. Is there some kind of timeout at 4 hours? Not that I'm aware of, and you didn't hit any timeout anyway -- you got a short write. Regarding the speed, since you're not running with a holding disk, there are all sorts of things that can affect the dump/tape rate -- speed from the client disks, network congestion, etc. I'd start by using amtapetype to test your new drive, both for hardware compression and native speed. I'd also look at adding a holding disk to your config, if at all possible. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Failed dumps with new amanda client
On Tue, 20 Jun 2006, Joshua Baker-LePain wrote: On Tue, 20 Jun 2006 at 10:35am, [EMAIL PROTECTED] wrote On Mon, 19 Jun 2006, Joshua Baker-LePain wrote: I'd be awfully suspicious that you're running with hardware compression enabled (quite possibly unbeknownest to you). That doesn't really make sense to me...if that were the case, wouldn't it affect all of the clients? In any case, I manually turn off the hardware compression before every backup. One thing that has me curious is this: Yes, it would affect all the clients. All the (already) compressed data going to tape would be hardware compressed by the drive, making it expand and take up more tape space. Therefore, even though amanda only saw ~25GB go to tape, on tape it took up the whole 35GB. The error you got (short write) typically means you hit EOT. That happened on one particular client, and so that particular client failed. I don't have any experience with DLT, but I've heard tell that with some drives turning off hardware compression isn't always easy. Avg Dump Rate (k/s) 1491.9 1491.9-- Tape Time (hrs:min)4:00 4:00 0:00 That speed looks a bit slow for a DLT7000...closer to what you'd expect from a DLT4000. Is there some kind of timeout at 4 hours? Not that I'm aware of, and you didn't hit any timeout anyway -- you got a short write. Regarding the speed, since you're not running with a holding disk, there are all sorts of things that can affect the dump/tape rate -- speed from the client disks, network congestion, etc. I'd start by using amtapetype to test your new drive, both for hardware compression and native speed. I'd also look at adding a holding disk to your config, if at all possible. Thanks for the response. Here's what I get with amtapetype: su-2.05a$ amtapetype -f /dev/nrsa0 Writing 256 Mbyte compresseable data: 92 sec Writing 256 Mbyte uncompresseable data: 90 sec Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write) It's going through another write at the moment, but I assume short write means it isn't getting full capacity from the tape? Not sure what those compression stats mean, either... James Smallacombe PlantageNet, Inc. CEO and Janitor [EMAIL PROTECTED] http://3.am =
Re: Failed dumps with new amanda client
On Tue, 20 Jun 2006 at 4:27pm, [EMAIL PROTECTED] wrote On Tue, 20 Jun 2006, Joshua Baker-LePain wrote: I'd start by using amtapetype to test your new drive, both for hardware compression and native speed. I'd also look at adding a holding disk to your config, if at all possible. Thanks for the response. Here's what I get with amtapetype: su-2.05a$ amtapetype -f /dev/nrsa0 amtapetype runs better when given an estimate of the tapelength. Writing 256 Mbyte compresseable data: 92 sec Writing 256 Mbyte uncompresseable data: 90 sec That's a check to see if hardware compression is enabled -- it isn't. That's good. Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write) 763218*32KiB = 23.3GiB, /13153s = 1857 KiB/s. Those are pretty similar to what your network dumps were getting. So it's your tape drive and/or tapes that are the issue. Again, I have no experience with DLT, but check your tapes to make sure they're really 35GB capacity. Any problems with the SCSI chain? Does the drive simply need to be cleaned? It's going through another write at the moment, but I assume short write means it isn't getting full capacity from the tape? Not sure what those short write simply means that it tried to write another 32KB block, and there wasn't room on the tape for it. That's what happens when you hit EOT. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
Re: Failed dumps with new amanda client
On Tue, 20 Jun 2006, Joshua Baker-LePain wrote:
On Tue, 20 Jun 2006 at 4:27pm, [EMAIL PROTECTED] wrote
On Tue, 20 Jun 2006, Joshua Baker-LePain wrote:
I'd start by using amtapetype to test your new drive, both for hardware
compression and native speed. I'd also look at adding a holding disk to
your config, if at all possible.
Thanks for the response. Here's what I get with amtapetype:
su-2.05a$ amtapetype -f /dev/nrsa0
amtapetype runs better when given an estimate of the tapelength.
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
That's a check to see if hardware compression is enabled -- it isn't.
That's good.
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
763218*32KiB = 23.3GiB, /13153s = 1857 KiB/s. Those are pretty similar to
what your network dumps were getting. So it's your tape drive and/or
tapes that are the issue. Again, I have no experience with DLT, but check
your tapes to make sure they're really 35GB capacity. Any problems with
the SCSI chain? Does the drive simply need to be cleaned?
It's going through another write at the moment, but I assume short write
means it isn't getting full capacity from the tape? Not sure what those
short write simply means that it tried to write another 32KB block, and
there wasn't room on the tape for it. That's what happens when you hit
EOT.
Here's the complete report, now that it finally finished:
su-2.05a$ amtapetype -f /dev/nrsa0
Writing 256 Mbyte compresseable data: 92 sec
Writing 256 Mbyte uncompresseable data: 90 sec
Estimated time to write 2 * 1024 Mbyte: 720 sec = 0 h 12 min
wrote 763218 32Kb blocks in 2334 files in 13153 seconds (short write)
wrote 757298 32Kb blocks in 4646 files in 20125 seconds (short write)
define tapetype unknown-tapetype {
comment just produced by tapetype prog (hardware compression off)
length 24034 mbytes
filemark 81 kbytes
speed 1530 kps
}
Does this mean that this 35GB uncompressed tape is only yeilding 24GB?
The mt program recognises it as a 35GB tape:
su-2.05a$ mt status
Mode Density Blocksize bpi Compression
Current: 0x1b:DLTapeIV(35GB)variable 85937IDRC
-available modes-
0:0x1b:DLTapeIV(35GB)variable 85937IDRC
1:0x1b:DLTapeIV(35GB)variable 85937IDRC
2:0x1b:DLTapeIV(35GB)variable 85937IDRC
3:0x1b:DLTapeIV(35GB)variable 85937IDRC
-
Current Driver State: at rest.
-
File Number: 0 Record Number: 0Residual Count 0
BTW, with DLT, the 2000, 4000 and 7000 all use the same actual media, DLT
IV.
James Smallacombe PlantageNet, Inc. CEO and Janitor
[EMAIL PROTECTED]
http://3.am
=
Failed dumps with new amanda client
Hi:
It's been many years since I needed help with Amanda, but I'm stuck on
this one. I've had a client+server and a client only box set up for
years, backing up no problem (running amanda-2.4.4). I switched from a
DLT4000 to a DLT7000 several months ago, as the former was wearing out and
I needed more space.
A colo customer requested that I backup his FreeBSD box, which was built
with only on file system, which is using around 8GB of space. I built and
installed amanda-2.4.5 without a hitch and amchecks look fine. However,
I've attempted full dumps 3 times using two different tapes (the last
time, I reconfigured and reinstalled amanda duplicating my other client's
config) and all have failed exactly like this:
These dumps were to tape FULL0.
*** A TAPE ERROR OCCURRED: [[writing file: short write]].
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: FULL1.
FAILURE AND STRANGE DUMP SUMMARY:
main.heart /dev/da0s1a lev 0 FAILED [data write: Broken pipe]
main.heart /dev/da0s1a lev 0 FAILED [dump to tape failed]
main.heart /dev/da0s1a lev 0 FAILED [out of tape]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:09
Run Time (hrs:min) 4:34
Dump Time (hrs:min)4:00 4:00 0:00
Output Size (meg) 20978.420978.40.0
Original Size (meg) 38216.538216.50.0
Avg Compressed Size (%)54.9 54.9--
Filesystems Dumped8 8 0
Avg Dump Rate (k/s) 1491.9 1491.9--
Dump Time (hrs:min)4:00 4:00 0:00
Output Size (meg) 20978.420978.40.0
Original Size (meg) 38216.538216.50.0
Avg Compressed Size (%)54.9 54.9--
Filesystems Dumped8 8 0
Avg Dump Rate (k/s) 1491.9 1491.9--
Tape Time (hrs:min)4:00 4:00 0:00
Tape Size (meg) 20978.520978.50.0
Tape Used (%) 59.9 59.90.0
Filesystems Taped 8 8 0
Avg Tp Write Rate (k/s) 1491.8 1491.8--
USAGE BY TAPE:
Label Time Size %Nb
FULL0 4:00 20978.5 59.9 8
?
FAILED AND STRANGE DUMP DETAILS:
/-- main.heart /dev/da0s1a lev 0 FAILED [data write: Broken pipe]
sendbackup: start [main.hearth.com:/dev/da0s1a level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/sbin/restore -f... -
sendbackup: info COMPRESS_SUFFIX=.gz
sendbackup: info end
| DUMP: Date of this level 0 dump: Mon Jun 19 15:33:29 2006
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/da0s1a (/) to standard output
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 8092024 tape blocks.
| DUMP: dumping (Pass III) [directories]
| DUMP: dumping (Pass IV) [regular files]
| DUMP: 12.34% done, finished in 0:35
| DUMP: 30.07% done, finished in 0:23
| DUMP: 45.62% done, finished in 0:17
| DUMP: 62.13% done, finished in 0:12
\
?
NOTES:
planner: Last full dump of ns1.pil.net:/dev/da0s1a on tape FULL0
overwritten on this run.
planner: Last full dump of ns1.pil.net:/dev/da0s1g on tape FULL0
overwritten on this run.
planner: Last full dump of ns1.pil.net:/dev/da0s1e on tape FULL0
overwritten on this run.
planner: Last full dump of ns1.pil.net:/dev/da0s1f on tape FULL0
overwritten on this run.
planner: Last full dump of mail.pil.net:/dev/aacd0s1a on tape FULL0
overwritten on this
run.
planner: Last full dump of mail.pil.net:/dev/aacd0s1g on tape FULL0
overwritten on this
run.
planner: Last full dump of mail.pil.net:/dev/aacd0s1e on tape FULL0
overwritten on this
run.
planner: Last full dump of mail.pil.net:/dev/aacd0s1f on tape FULL0
overwritten on this
run.
planner: Last full dump of main.hearth.com:/dev/da0s1a on tape
overwritten in 1 run.
taper: tape FULL0 kb 24499968 fm 9 writing file: short write
?
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
mail.pil.net -v/aacd0s1a 0 117614 42944 36.5 0:361184.0 0:361183.7
mail.pil.net -v/aacd0s1e 0 2494624 865536 34.7 10:301373.8 10:301373.7
mail.pil.net -v/aacd0s1f 0 1808993 407328 22.5 6:421012.6 6:421012.5
mail.pil.net -v/aacd0s1g 0 160671519237184 57.5 95:261613.2 95:261613.2
main.hearth. /dev/da0s1a 0 FAILED ---
ns1.pil.net /dev/da0s1a 0 127749 74624 58.4 0:471579.3 0:471577.8
ns1.pil.net /dev/da0s1e 0 2505458 770528 30.8 18:29 694.7 18:29 694.7
ns1.pil.net /dev/da0s1f 0 700444 126752 18.1 3:11 663.6 3:11 663.6
ns1.pil.net /dev/da0s1g 0
Re: Failed dumps with new amanda client
On Mon, 19 Jun 2006 at 6:45pm, [EMAIL PROTECTED] wrote
taper: tape FULL0 kb 24499968 fm 9 writing file: short write
*snip*
define tapetype DLT7000 {
comment DEC/Quantum DLT7000 tape drive, hardware compression turned
off
length 35000 mbytes
filemark 8 kbytes
speed 5 mbytes
}
I'd be awfully suspicious that you're running with hardware compression
enabled (quite possibly unbeknownest to you).
--
Joshua Baker-LePain
Department of Biomedical Engineering
Duke University
