BackupPC-users

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

2011-10-06 18:44:53
Subject: Re: [BackupPC-users] Bad md5sums due to zero size (uncompressed) cpool files - WEIRD BUG
From: Holger Parplies <wbppc AT parplies DOT de>
To: Les Mikesell <lesmikesell AT gmail DOT com>
Date: Fri, 7 Oct 2011 00:42:52 +0200
Hi,

Les Mikesell wrote on 2011-10-06 13:42:09 -0500 [Re: [BackupPC-users] Bad 
md5sums due to zero size (uncompressed) cpool files - WEIRD BUG]:
> On Thu, Oct 6, 2011 at 1:04 PM, Timothy J Massey <tmassey AT obscorp DOT 
> com>wrote:
> >
> > 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.
> [...]
> 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.
> [...]
> 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.
> [...]
> 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.

the problem, I believe, is not 'cat' or 'zcat' failing, it's a *media* error,
as you pointed out, rendering a complete compressed file unusable instead of
only the erraneous bytes/sectors. Yes, there are compression algorithms that
are able to recover after an error, but I don't think BackupPC uses any of
these.

Sure, the common case might be losing a complete disk rather than having a few
bytes altered, but in that case, you can either recover from the remaining
disks (presuming you have some form of redundancy), or you lose your complete
pool, whether or not compressed.

While you might reduce the chances of failure with compression, you increase
the impact of failure.

> > This entire thread is a *PERFECT* example of why I have my reasons.

I agree with your reasons, but it remains to be seen whether compression makes
any difference in the context of this thread. But I'll reply to that
separately.

Regards,
Holger

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