From owner-freebsd-hackers  Wed Jun 18 18:00:01 1997
Return-Path: <owner-hackers>
Received: (from root@localhost)
          by hub.freebsd.org (8.8.5/8.8.5) id SAA23013
          for hackers-outgoing; Wed, 18 Jun 1997 18:00:01 -0700 (PDT)
Received: from pandora.hh.kew.com (kendra.ne.highway1.com [24.128.53.73])
          by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id RAA22972;
          Wed, 18 Jun 1997 17:59:55 -0700 (PDT)
Received: (from ahd@localhost)
	by pandora.hh.kew.com (8.8.5/8.8.5) id UAA05638;
	Wed, 18 Jun 1997 20:58:43 -0400 (EDT)
Date: Wed, 18 Jun 1997 20:58:43 -0400 (EDT)
From: Drew Derbyshire <ahd@kew.com>
Message-Id: <199706190058.UAA05638@pandora.hh.kew.com>
To: freebsd-hackers@FreeBSD.ORG, jmb@FreeBSD.ORG
Subject: Re: dump/restore with compression
Cc: brandon@ice.cold.org, freebsd-questions@FreeBSD.ORG, nate@mt.sri.com
Sender: owner-hackers@FreeBSD.ORG
X-Loop: FreeBSD.org
Precedence: bulk

> ps.	dont use compression.  if the data is valuable enough to backup
> 	its valuable enough to backup reliably.

This implies compression is not reliable.  I can't say much for
UNIX backups, but in general I've never had hardware or software
compression screw up worse than any other hardware/software
combination.

I believe in compression because it encourages backups by reducing
the media needed, cutting both media cost and time spent swapping
volumes.  Less media per megabyte up also reduces the chances of
an I/O error on media, so compressed backups can be more reliable
than uncompressed.

Like anything to do with backups, test and then test again.

-ahd-