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

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:

Holger Parplies <wbppc AT parplies DOT de>

Date:

Thu, 6 Oct 2011 21:06:51 -0400

Holger Parplies <wbppc AT parplies DOT de> wrote on 10/06/2011 06:58:06 PM:> Don't you feel uncomfortable about deduplication, too, then? After all, it
> introduces a single point of failure for common data.

No. Dedupe is merely a side effect of a filesystem. Dedupe errors are no different than any of 1,000 other possible filesystem errors. If I want to defend against a dedupe error, I can do so by *also* protecting against a filesystem error, too, and get dedupe safety for free.

Nearly all of my servers are virtualized today. These servers are backed up two ways: a file-level backup and a snapshot-based backup. So I have redundancy that protects against a *LOT* of failures. While it would be harder to get a single file from a snapshot backup, it's very doable. So I have that redundancy. Even if BackupPC were to decide to *maliciously* destroy my data, no problem: my snapshots don't use BackupPC! :)

(The big reason for the snapshot backups is that Windows systems are *way* easire bare-metal restored from a snapshot. But I get all the other advantages, too.)

> If you can't get back
> your file from the most recent backup, because it has somehow been corrupted,
> there's not much chance to get the same content from any other backup. In
> other words, deduplication *is* a form of compression ;-).

That's true. But I would consider that "accidental" (or maybe incidental) redundancy. It's still all on the same disk, with the same filesystem. I consider dedupe a problem to defend against, but I also consider filesystem (or disk!) failure a problem, too. I protect against *all* of them, but not necessarily each individually.

Redundancy is a good thing.

(While we're on the subject, I've considered Les' argument that compressed files take less space on the disk and are therefore less likely to be corrupted before. It's true, but like dedupe errors, it's just *one* possible failure--and to me, not a very likely one. It's not one worth defending against by *itself*. Having uncompressed files makes, e.g., scanning a badly scrambled filesystem for salvagable data *much* easier. When it comes to backup, I will almost *always* choose simple over fancy, even if fancy gives me other advantages but not additional safety.)

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 of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2

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

Previous by Date:

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

Next by Date:

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

Previous by Thread:

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

Next by Thread:

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

Indexes:

[Date] [Thread] [Top] [All Lists]