BackupPC-users

Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG

2011-10-06 14:14:09
Subject: Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG
From: Timothy J Massey <tmassey AT obscorp DOT com>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Thu, 6 Oct 2011 14:04:57 -0400
Les Mikesell <lesmikesell AT gmail DOT com> wrote on 10/06/2011 01:21:29 PM:

> On Thu, Oct 6, 2011 at 11:56 AM, Timothy J Massey <tmassey AT obscorp DOT 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.

>  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.

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.

Timothy J. Massey
 
Out of the Box Solutions, Inc.
Creative IT Solutions Made Simple!

http://www.OutOfTheBoxSolutions.com
tmassey AT obscorp DOT com
      22108 Harper Ave.
St. Clair Shores, MI 48080
Office: (800)750-4OBS (4627)
Cell: (586)945-8796

------------------------------------------------------------------------------
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 AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/
<Prev in Thread] Current Thread [Next in Thread>