On Tue, 27 Feb 2001, Bill Freeman wrote:
> The network only has about 70GB of disk total.
Unfortunately, that is sufficiently large that you are getting into the
realm of "expensive". I recommend you bite the bullet and buy a serious
backup solution. Yes, you will pay a lot more in the short term, but given
the fact that data is generally a company's most important asset, it is well
worth it.
Without knowing enough details to say for sure, I would say a DDS-3 or DDS-4
drive and auto-changer might be in order. A larger, single-drive solution
like AIT-2 or DLT-8000 might avoid the need for an auto-changer for now, but I
suspect you'll just end up buying one down the road.
> My thought is to occasionally do full backups, and regularaly do
> incrementals from the last full backup.
That depends entirely on how important your data is.
Ask yourself this question: If all of your data -- everything from your
address book to your payroll files -- was lost tomorrow, what would be the
impact on your operations?
Just think about it for a minute or two.
Now consider that hardware failure is just one cause of data loss.
Software failure (program corrupts its own database), data entry error (user
corrupts the database for you), user error (user deletes the database by
mistake), virus infection (nukes the database), disgruntled worker (deletes
everything), outside attacker (who changes things in non-obvious ways), burst
pipes, cosmic rays, space aliens, etc., are all possible, too.
Now go back and think about losing all your data again.
I have found the question of "How often should I make backups?" answers
itself after that little exercise. :-)
> My current thought is to use one of the Seagate or Tecmar Travan internal
> SCSI offerings.
Travan TR5 is an ideal solution for the small business with between 10 and
30 GB of data to backup. Drives are cheap, tapes are cheap, and it is easy to
use. However, they are slow to write, slower to read, and agonizingly slow to
search. I've also noticed Travan drives and tapes tend to fail significantly
more often than more expensive alternatives like DDS and DLT, in my personal
experience.
> DAT and DLT seem amazingly more expensive, at least up front.
You get what you pay for.
> 1. Would someone care to pontificate about the relative advantages of DAT
> and DLT versus Travan, and whether they apply to my scenario?
DLT and DDS (Digital Data Storage, the official name for data-on-DAT) are
faster and more reliable. For your needs, I would definitely recommend
against Travan. Your needs are simply in a different class than Travan
supports well.
> 2. My poking around the web turns up "NS" versions of Travan. Can anyone
> explain how or if that differes from just Travan?
"NS" supposedly stands for "Network Server" or some such foolishness.
However, as far as I can tell, the tape technology itself is completely
identical in all versions of TR5. The only difference is price.
> The bundles are confusing ...
When it comes to the bundles, compare the specifications on the drives.
You will generally find more expensive drives have a higher burst rate, more
cache memory, longer warranty, etc., etc.
> 3. For a bunch more money, the drives claim to do ALDC (adaptive loseless
> data compression) in hardware.
And my portable CD player includes an "impact resistant, polycarbonate
shell". In other words, it is made out of plastic.
"Adaptive" means it refreshes the compression dictionary every so often, on
the assumption that you are backing up more than one file.
"Lossless" means you get the same data out you put in. Nice feature, that.
Hardware data compression means your software doesn't have to do it. This
can simplify things, and generally makes it easier to stream. In practice, I
haven't found hardware data compression decreases reliability significantly,
but that might be because I have seen software data compression screw up often
enough. :-)
> 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?
Backwards compatibility is always an issue, regardless of whether or not you
use hardware data compression. Travan drives have traditionally been able to
read previous generations of cartridges but not write to them. YMMV.
> 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?
In theory, this sounds good. The drive writes to tape with one (set of)
head(s), and immediately reads it back with another (set of) head(s). This
should help detect media failure immediately. In practice, I'm not too sure
how well it works or how well it reports failures. In any event, I firmly
believe in doing a full verify of everything I write to tape, which makes the
whole thing somewhat moot.
> 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?
Possible, but unlikely. If you are worried about it, look for a vendor who
specifically supports Linux.
On Tue, 27 Feb 2001, Paul Lussier wrote:
> However, they last, and can be re-written to greater than 10 times each.
*Ten times*? Please tell me that is a typo. I get better reliability than
that from floppy disks! :-)
> I don't know the lifespan of Travan or DAT tapes.
DDS and Travan tapes are usually rated in "passes", i.e., passes over the
read/write head. (Actually, I think DLT tapes are, too.) 2000 is the number
I usually see. If you verify your backups, that will at least double the
number of passes. Appending to the end of a tape may also increase usage, if
your backup solution rewinds at the end of the job, and later searches for
end-of-data on the next job. The typical worst-case I hear is six passes per
backup session.
Be aware that Travan tapes are tracked; as you read through the tape, it
will wind back and forth from one spool to the other. This increases passes.
> Also, I don't think that compression or data verification is actually
> related to SCSI.
Not directly, but turning such features on and off, and tweaking their
knobs, is often done via SCSI commands.
--
Ben Scott <[EMAIL PROTECTED]>
Net Technologies, Inc. <http://www.ntisys.com>
Voice: (800)905-3049 x18 Fax: (978)499-7839
**********************************************************
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
**********************************************************
