Re: [Amanda-users] Re: Tape DDS-3 values
Good drives and tapes rarely have errors. If you are getting frequent tape errors you should investigate why; your tapes and/or drives could be in need of cleaning/repair/replacement. Since failing drives and tapes don't get better, just worse, you will be continually adding more workarounds (shorter backup cycles, duplicate backups, duplicating data on your systems, archiving in error-tolerant formats, etc.) and still always live in fear of having to attempt a restore. I've been there, done that, and its certainly no fun. If your company won't pay to repair or replace whatever it takes, and you don't have any other employment options at the moment (I know times are tough in IT), be sure to document your problems, send memos, add it to your reports, so when (not if) you are unable to restore critical data due to tape errors you won't be the one escorted out the door. Frank --On Saturday, September 14, 2002 13:16:10 +1000 Jason Thomas [EMAIL PROTECTED] wrote: we had the same problem, we now store the data uncompressed on the tape. And still get frequent errors. On Fri, Sep 13, 2002 at 06:14:46PM +0100, Niall O Broin wrote: On Fri, Sep 13, 2002 at 10:25:29AM -0400, Jon LaBadie wrote: Is it a real, or theoretical, problem? I.e. has anybody experienced bit errors in a gzip'ed document? For me the incidence is low enough that I don't feel a need to use bzip2 for that extra protection. The value of your data may lead to a different conclusion. I brought this up and it's not theoretical - I've had problems with gzipped tar files coming back off tapes. I definitely have problems with my tape drive but as mentioned, such errors in a tar file would only have caused problems with some files - with the gzipped tar file, you're done for once you hit an error. -- Frank Smith[EMAIL PROTECTED] Systems Administrator Voice: 512-374-4673 Hoover's Online Fax: 512-374-4501 *** Qmail-Scanner Envelope Details Begin *** X-Qmail-Scanner-Mail-From: [EMAIL PROTECTED] via maat.reeusda.gov X-Qmail-Scanner-Rcpt-To: [EMAIL PROTECTED] X-Qmail-Scanner: 1.12 (hbedv: 2.0.3/vdf=6.14.0.3 Clear:. Processed in 0.53702 secs) *** Qmail-Scanner Envelope Details End ***
Re: Tape DDS-3 values
On Fri, Sep 13, 2002 at 10:25:29AM -0400, Jon LaBadie wrote: Is it a real, or theoretical, problem? I.e. has anybody experienced bit errors in a gzip'ed document? For me the incidence is low enough that I don't feel a need to use bzip2 for that extra protection. The value of your data may lead to a different conclusion. I brought this up and it's not theoretical - I've had problems with gzipped tar files coming back off tapes. I definitely have problems with my tape drive but as mentioned, such errors in a tar file would only have caused problems with some files - with the gzipped tar file, you're done for once you hit an error. Regards, Niall O Broin *** Qmail-Scanner Envelope Details Begin *** X-Qmail-Scanner-Mail-From: [EMAIL PROTECTED] via maat.reeusda.gov X-Qmail-Scanner-Rcpt-To: [EMAIL PROTECTED] X-Qmail-Scanner: 1.12 (hbedv: 2.0.3/vdf=6.14.0.3 Clear:. Processed in 1.182701 secs) *** Qmail-Scanner Envelope Details End ***
Re: [Amanda-users] Re: Tape DDS-3 values
we had the same problem, we now store the data uncompressed on the tape. And still get frequent errors. On Fri, Sep 13, 2002 at 06:14:46PM +0100, Niall O Broin wrote: On Fri, Sep 13, 2002 at 10:25:29AM -0400, Jon LaBadie wrote: Is it a real, or theoretical, problem? I.e. has anybody experienced bit errors in a gzip'ed document? For me the incidence is low enough that I don't feel a need to use bzip2 for that extra protection. The value of your data may lead to a different conclusion. I brought this up and it's not theoretical - I've had problems with gzipped tar files coming back off tapes. I definitely have problems with my tape drive but as mentioned, such errors in a tar file would only have caused problems with some files - with the gzipped tar file, you're done for once you hit an error. *** Qmail-Scanner Envelope Details Begin *** X-Qmail-Scanner-Mail-From: [EMAIL PROTECTED] via maat.reeusda.gov X-Qmail-Scanner-Rcpt-To: [EMAIL PROTECTED] X-Qmail-Scanner: 1.12 (hbedv: 2.0.3/vdf=6.14.0.3 Clear:. Processed in 0.53725 secs) *** Qmail-Scanner Envelope Details End ***
Re: Tape DDS-3 values
On Thu, 12 Sep 2002, Kablan BOGNINI wrote:
Hello,
I am using HP DDS-3 tapes for my backup. I've tried to
get the correct values for my tape. But tapetype gives
this result:
define tapetype HP-DDS3-DAT {
comment just produced by tapetype program
length 9860 mbytes
filemark 0 kbytes
speed 840 kps
}
I think this is not correct because I've a DDS-3 125M
tape with 12GB.
Nope, they are not correct. The reason is that you probably have hardware
compression on which actually expands the data Amanda uses to determine
tapesize which in turn gives a smaller length.
However, you are in good company since, even though I have only been on
this list for a short time, this seems to be one of the most frequent
questions here.
I had the same problem and I solved it by removing the drive from it's
drivebox and changing a dip-switch. Some OS:s seems to allows you to
change if the drive should use compression with the mt command (I have not
found it in Solaris 8 though).
Also, tar+gnuzip gives you alot better compression than the internal
hardware of the drive, at least from what I've read on this list.
Could someone give me more accurate values for this
tape or point me to doc ?
I use the following tapetype:
define tapetype HP-C1554a {
comment just produced by tapetype program
length 10075 mbytes
filemark 0 kbytes
speed 872 kps
}
Perhaps the length could be a bit larger, but better safe than sorry. If
you change the drive to default to hardware compression off you can rerun
tapetype to get more accurate values.
Hope it helps!
--
Conny Gyllendahl
Don't try to have the last word -- you might get it.
-- Lazarus Long
Re: Tape DDS-3 values
--On Thursday, September 12, 2002 15:54:43 +0200 Kablan BOGNINI [EMAIL PROTECTED]
wrote:
I am using HP DDS-3 tapes for my backup. I've tried to
get the correct values for my tape. But tapetype gives
this result:
define tapetype HP-DDS3-DAT {
comment just produced by tapetype program
length 9860 mbytes
filemark 0 kbytes
speed 840 kps
}
I think this is not correct because I've a DDS-3 125M
tape with 12GB.
Could someone give me more accurate values for this
tape or point me to doc ?
You probably have compression enabled on your drive, and
it is making tapetype's data bigger. Try turning off the
compression and re-running tapetype.
Frank
--
Frank Smith[EMAIL PROTECTED]
Systems Administrator Voice: 512-374-4673
Hoover's Online Fax: 512-374-4501
Re: Tape DDS-3 values
On Thu, Sep 12, 2002 at 05:13:53PM +0300, Conny Gyllendahl wrote: Also, tar+gnuzip gives you alot better compression than the internal hardware of the drive, at least from what I've read on this list. This is true but as a friend pointed out to me recently when I was having some tape reading problems - if you get some bit errors reading a tar file from a tape, most likely asll you will lose is the affected file. If OTOH you get bit errors reading a gzipped tar file, you most likely will not be able to read anything after the bit errors. Just something to be aware of. Kindest regards, Niall O Broin
Re: Tape DDS-3 values
Kablan BOGNINI wrote:
Hello,
I am using HP DDS-3 tapes for my backup. I've tried to
get the correct values for my tape. But tapetype gives
this result:
define tapetype HP-DDS3-DAT {
comment just produced by tapetype program
length 9860 mbytes
filemark 0 kbytes
speed 840 kps
}
I think this is not correct because I've a DDS-3 125M
tape with 12GB.
Could someone give me more accurate values for this
tape or point me to doc ?
Thanks in advance.
___
Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
I'm gonna go out on a limb and say you have hardware compression turned
on...as any search through the archives will state, turn if off and
leave it off. Software compression will most likely give you more than
the tape advertises (just ask Gene). If you are running linux, run mt
-f /dev/tapedevice compression 0 . If you still get the same result
you may have to play with data density settings for the drive which will
require perusing the manuals.
=G=
Re: Tape DDS-3 values
On Thursday 12 September 2002 09:54, Kablan BOGNINI wrote:
Hello,
I am using HP DDS-3 tapes for my backup. I've tried to
get the correct values for my tape. But tapetype gives
this result:
define tapetype HP-DDS3-DAT {
comment just produced by tapetype program
length 9860 mbytes
filemark 0 kbytes
speed 840 kps
}
I think this is not correct because I've a DDS-3 125M
tape with 12GB.
Could someone give me more accurate values for this
tape or point me to doc ?
Thanks in advance.
That looks as if you have the drives hardware compression enabled,
which for amanda is a Bad Thing(tm).
When you run tapetype, the source of the data is /dev/urandom. This
is not generally compressable data because there is little
removable redundancy in such data. And in most cases, the rll
encoder in the drive will actually expand such data, hence the
apparent short tape.
This also places an unknown into amanda's idea of what the tape will
hold as amanda counts bytes sent to the tape *after* any software
compression has been applied.
So turn off the hardware compression and leave it off forever. Then
re-run the tapetype.
Software compression is usually much more effective anyway. Last
nights run here put 8370k of real data out to the tape as 3780k on
a DDS2 120 meter tape, the first time I've actually had a tape 100%
used. And its a 46 gig system.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.15% setiathome rank, not too shabby for a WV hillbilly
Re: Tape DDS-3 values
On Thursday 12 September 2002 10:43, Galen Johnson wrote:
Kablan BOGNINI wrote:
Hello,
I am using HP DDS-3 tapes for my backup. I've tried to
get the correct values for my tape. But tapetype gives
this result:
define tapetype HP-DDS3-DAT {
comment just produced by tapetype program
length 9860 mbytes
filemark 0 kbytes
speed 840 kps
}
I think this is not correct because I've a DDS-3 125M
tape with 12GB.
Could someone give me more accurate values for this
tape or point me to doc ?
Thanks in advance.
___
Do You Yahoo!? -- Une adresse yahoo.fr gratuite et en français !
Yahoo! Mail : http://fr.mail.yahoo.com
I'm gonna go out on a limb and say you have hardware compression
turned on...as any search through the archives will state, turn
if off and leave it off. Software compression will most likely
give you more than the tape advertises (just ask Gene). If you
are running linux, run mt -f /dev/tapedevice compression 0 .
If you still get the same result you may have to play with data
density settings for the drive which will require perusing the
manuals.
=G=
While you can use mt to turn it off, on most drives is a switch that
will turn it off, a bit more dependable than remembering to do it
with mt, if your platforms mt even has that ability.
Which brings me to the next subject regarding compression.
Most modern drives can autoswitch, and will switch it back on if it
finds, in the tapes own, you can't read it, header, that the
compression is on for that individual tape. So basicly it doesn't
do you any good to turn it off if the *(% tape itself turns it
back on during the tape recognition as each tape is inserted into
the drive.
What I've found to be a way to fix that is to rewind the tape, then
dd the amanda label block out to a scratch file, then rewind the
tape again, use mt to shut the compression off and write 20 megs or
so of data from /dev/zero to it using dd. Rewind it and rewrite
the scratch file back to restore the label.
By doing this long garbage data write, you are going to force the
drive to flush its buffers. When this is done, the drive will
re-write those hidden headers, doing it with the compression flag
now set to off. If such a flush operation is not forced, the drive
doesn't update those headers and you're stuck with xx gig tapes
that only hold less because the compression is on regardless of
your wishes. Sometimes much less when you feed the drives rll
compressor with a few gigs worth of bz2 files.
--
Cheers, Gene
AMD K6-III@500mhz 320M
Athlon1600XP@1400mhz 512M
99.15% setiathome rank, not too shabby for a WV hillbilly
Re: Tape DDS-3 values
On Thu 12 Sep 02 16:38, Niall O Broin wrote: This is true but as a friend pointed out to me recently when I was having some tape reading problems - if you get some bit errors reading a tar file from a tape, most likely asll you will lose is the affected file. If OTOH you get bit errors reading a gzipped tar file, you most likely will not be able to read anything after the bit errors. Just something to be aware of. So... when, and how much work is it to get bzip2 used. Apparently it doesn't suffer from this problem? If I were to replace (by hook or by crook) the COMPRESS_PATH to bzip2 would that work? And what is the opinion of the Right Way to do this? Regards, Brian -- Init Systems - Linux consulting 031 767-0139082 769-2320[EMAIL PROTECTED]
