On Thu, Oct 6, 2011 at 1:04 PM, Timothy J Massey <tmas...@obscorp.com>wrote:
>
> > On Thu, Oct 6, 2011 at 11:56 AM, Timothy J Massey <tmas...@obscorp.com>
> wrote:
>
> > Personally, I feel that compression has no place in backups. Back
> > when we were highly limited in capacity by terrible analog devices
> > (i.e. tape!) I used it from necessity. Now, I just throw bigger
> > hard drives at it and am thankful. :)
> >
> > No, it makes perfect sense for backuppc where the point is to keep
> > as much history as possible online in a given space.
>
> No, the point of backup is to be able to *restore* as much historical data
> as possible. Keeping the data is not the important part. Restoring it is.
> Anything that is between storing data and *restoring* that data is in the
> way of that job.
>
> Obviously, there *are* things that have to go between it: a filesystem to
> store the data, for example. But if I can avoid something in between
> storing my data and using my data, I absolutely will.
>
> Compression falls in that area.
>
My experience is that the failures are more likely in the parts underneath
storing the data than in the compression process. Admittedly, that goes
all the way back to storing zip files on floppies vs. large uncompressed
text files and media reliability has improved a bit.
> > If you have
> > trouble with compression, just throw a faster CPU at it. Just
> > anecdotally, I saw 95% compression recently on a system where
> > someone requested including their web content directory and forgot
> > to mention the 40Gb of log files that happened to be there.
>
> That's all well and good. My issue is *NOT* performance. Or capacity, for
> that matter. I'm not saying that there is no value to compression. I'm
> saying that my objective for of a backup server is FIRST to be as simple and
> reliable as possible, and THEN only to have other features. Features that
> detract from that first requirement are considered skeptically.
>
Media fails. Things that reduce the media necessary to hold a given amount
of data reduces the chances of failure. The CPU and RAM can fail too, but
if those go you are fried whether you were compressing or not.
>
> This entire thread is a *PERFECT* example of why I have my reasons. I have
> avoided an entire category of failure simply by throwing more disk at it (or
> by having a smaller "window" of backups). Seeing as I have, at a minimum, 4
> months of data (with varying gaps between the backups) within the backup
> server itself, and archive data in long-term storage every three months, I
> have what I (and my clients) feel to be enough data. Extra capacity would
> have no value. Extra reliability *always* has value.
>
> YMMV, of course.
With compressible data you increase both capacity and reliability by
compressing before storage. There's no magical difference between the
reliability of 'cat' vs 'zcat'. Either one could fail.
--
Les Mikesell
lesmikes...@gmail.com
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
BackupPC-users mailing list
BackupPC-users@lists.sourceforge.net
List: https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki: http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
