On Tuesday 23 March 2004 22:48, Fernando Serto wrote: >> > My doubt is... isn't 324.7 K/s for dump rate too slow? I >> >> was backing up 1Gb >> >> > of data and it's taking almost 1 hour! does that mean that >> >> for 12Gb I'll get >> >> > something close to 12 hours? >> >> Probably, unless something changes. > >I hope it changes. :o) > >> > another thing, I tried using compress server best and >> >> compress client best >> >> > and I get no difference at all on the backups, same time to >> >> run, same amount >> >> > of data, and same tape usage. >> >> Is 'handsoff' the server itself, or another machine? If it is the >> server, then it would be the same either way. > >yup. anyway, compression is off now (and was already set to none > when I sent this one).
Drive hardware compression usually has a mind of its own. In particular, many drives look at the header, and set the compression on if the tape has ever been written to with the compression turned on, and there is nothing amanda can do about fixing that. Many drives have an indicator on the front panel called "dc", and if its lit while the tape is being written, then the compression is on. The only way I know of to fix such a tape is: rewind it read out the label to a scratch file using dd rewind it again turn the compression off with "mt -f device whatever turns it off" dd that scratch file back to the tape using the non-rewinding device dd at least enough data from /dev/zero to force the drive to flush its buffers. This will force the drive to turn the header compression flag off and that tape will not be compressed again unless you turn compression back on. I noted in a previous msg that your drive is a DDS3. This drive should be able to stream about 700k/second. I'd concur that the holding disk isn't enabled, or is somehow miss-configured and that the drive is shoe-shineing the tape due to running out of data and having to back up and restart once the buffer is up to 50% full or so. Thats a speed killer in addition to causing a lot of wear and tear on both the tape and the headwheel with all that starting and stopping that we suspect it may be doing. >> > NOTES: >> > planner: tapecycle (1) <= runspercycle (1) >> > planner: Last full dump of handsoff:/home/data/archive on >> >> tape DailySet01 >> >> > overwritten in 1 run. >> >> This is OK for testing, but would be a big problem for real >> backups. What >> does your tapecycle, runspercycle, and runtapes look like? > >well, this is just a test, but I'll run a full backup once in a > while for this box. I'll set up other backup clients to use a > different conf file. > >> Since the taper and dumper stats are almost identical, I'm >> guessing you >> aren't using a holdingdisk. Configuring one could greatly >> increase your >> taper speeds since the tape must constantly stop and reposition >> itself if the dumper can't keep up, and the dumper has to stop >> each time the tape does since there isn't much buffering in >> between. > >I followed all the steps for this, but I'm not sure if I'm using it > or not. > >> If this is old slow hardware then the compression might also >> limit your speed. > >it was set to none. doesn't matter what I use for compression, the > backup time is the same. > >thanks! > >--- >Certain disclaimers and policies apply to all email sent from > Memetrics. For the full text of these disclaimers and policies see ><a >href="http://www.memetrics.com/emailpolicy.html">http://www.memetric >s.com/em ailpolicy.html</a> -- 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.22% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attornies please note, additions to this message by Gene Heskett are: Copyright 2004 by Maurice Eugene Heskett, all rights reserved.