[H-GEN] Tape Drives

Bruce Campbell bc at humbug.org.au
Tue Jan 8 13:28:15 EST 2002


[ Humbug *General* list - semi-serious discussions about Humbug and  ]
[ Unix-related topics.  Please observe the list's charter.           ]
[ Worthwhile understanding: http://www.humbug.org.au/netiquette.html ]

On 8 Jan 2002, Jason Henry Parker wrote:

> James Lever <jamver at adams.humbug.org.au> writes:
>
> > According to Jason Henry Parker (on Tue, Jan 08, 2002 at 08:41:59AM +1000):
> > > *Bad* idea.  Using software (-5 is only one step down from the gzip
> > > default) and hardware compression at the same time will only make the
> > > backup images faster.
>
> The problem is that if the data going to tape is already compressed,
> the hardware compression will only make the data take up *more* tape.

As a generalisation, yes.  As a hard and fast rule, don't bet on it.

> Software compression is the best way to decrease the amount of data
> written to the tape.

If your goal is to reduce the amount of tape used in a backup, that is
mostly correct.

However, you've completely missed several factors, being paraphrased as
reliability, redundancy and speed.

If you manage to find a software compression routine that leaves you with
a backup (what we're writing to tape) less than 30% of your original data
size, bully for you.  How are you putting it on tape?

If you are doing the software compression inline, you're probably feeding
data to the tape drive at well under its recommended data rate due to the
cpu overhead in compressing this data.

A tape drive works best when it has a full buffer to write to tape.  If
the buffer runs out, the tape drive has to stop the tape, rewind the tape,
and be prepared to start the tape and start writing where it left off.
Repeat that process a few times and you have more wear and tear on your
drive and tape, you've wasted tape because 'where it left off' is
rather loose when you measure the speed of the tape in metres/second, and
you've decreased the reliability of your backup.

So, to get around this, you always provide the tape drive with a full
buffer.  You compromise on your software encryption (if you don't have the
cpu grunt) because to have your cpu backoff and resume a process is an
event measured in thousandths of a second, where the same for a tape drive
is measured in seconds.

Your milage may vary, but in a serious backup regime, you have one or more
of:

	serious cpu to do decent software compression inline
	a staging area to put compressed images before dumping to tape
		(read, oodles of spare diskspace)
	hardware compression on the tape drive.
	Lots and lots of tapes.

Then, you get into incompatibilities between differing brands of the same
drive type (eg, DDS3), and even incompatibilities between different drive
models.

Decide whether you want speed, long-term reliability or small tape usage.
Two of these at the same time is usually not attainable ;)

--==--
Bruce.



--
* This is list (humbug) general handled by majordomo at lists.humbug.org.au .
* Postings to this list are only accepted from subscribed addresses of
* lists 'general' or 'general-post'.



More information about the General mailing list