In a message dated: Tue, 27 Feb 2001 09:13:26 EST
Bill Freeman said:
>
> My current thought is to use one of the Seagate or Tecmar
>Travan internal SCSI offerings. DAT and DLT seem amazingly more
>expensive, at least up front.
>
> 1. Would someone care to pontificate about the relative
>advantages of DAT and DLT versus Travan, and whether they apply to my
>scenario?
I know nothing about Travan, so I can not provide any data, +/-, about
that technology. 4mm DAT is rumored to be highly reliable, and I know many
people who have been using it for years. I don't think 8mm DAT is widely
used anymore, though I may be wrong.
DLT is my personal favorite. It's reasonably fast, quite reliable, and
holds a lot of data. However, there's a financial cost involved. Single
drives are in the $3-4k range, 8-tape changers in the $7-8k range. Tapes
are anywhere between $60-80 each. However, they last, and can be
re-written to greater than 10 times each. I don't know the lifespan of
Travan or DAT tapes.
> 3. For a bunch more money, the drives claim to do ALDC
>(adaptive loseless data compression) in hardware. Is this just asking
>for archival tapes to be useless because the compression technology
>will move on and a few years down the road the replacement for a
>failed drive will be able to read the physical media but not undo that
>compression? (I guess there's always reading the media raw and
>de-compressing in software, if the stuff is well enough specified.)
I'm not familiar with this particular type of compression. However, I would
suspect that if you continue with the same drive, or the same model of drive,
you'll always be able to read your older tapes. I think a more serious
concern would be, will the solution you purchase now, last a reasonable amount
of time before you outgrow it and are forced to move to a new, incompatible
technology. For example, assume you choose Travan today because it's cheap,
reasonably reliable, and fits your capacity needs perfectly. How soon will
you be forced to abandon Travan because your data capacity has outgrown
your backup capacity? And when it does, how long will you need to keep that
Travan drive around in case you need to restore something from one of those
tapes? In other words, if your archival plan is to retain tapes for 1 year,
then once you move to a new technology, you need to keep that Travan drive
around for 1 year until all your archives are now on the new tape formats.
If your archival plan is to retain tapes forever, guess how long you need
to keep a working Travan drive around :)
> 4. The ALDC drives also seem to offer what I'd call read
>behind verification. In the experience of the sysadmins out there,
>is this a desireable feature?
Never heard of it. That doesn't mean that it's not good, I've just never
heard of it.
> 5. Are features like ALDC and read behind likely to be
>controlled by vendor specific SCSI commands that aren't going to be
>supported under linux without doing my own backup utility coding, or
>even driver coding? (It might be fun, but it's not clear that it
>would ever reach the top of my stack.)
It's possible. What I would do is look at other drives out there like DAT
VXA, and DLT and see what types of features those drives offer. Look to see
if any of them have the same features as the Travan. If they do, it's likely
that it's not going to be a problem. Also, I don't think that compression
or data verification is actually related to SCSI. SCSI is the transport
mechanism by which the data is sent from the host to the drive. Once it's
on the drive, the data is de-encapsulated (de-capsulated?) and SCSI no longer
plays any part in what goes on. So compression and verification are
controlled by hardware on the the drive, and not affected by SCSI commands.
At least, that's how I understand it.
I highly recommend that you seek out the O'Reilly Backups book by W. Curtis
Preston. He is probably one of the foremost authorities on backups, and his
book is supposed to be excellent!
HTH!
--
Seeya,
Paul
----
It may look like I'm just sitting here doing nothing,
but I'm really actively waiting for all my problems to go away.
If you're not having fun, you're not doing it right!
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
