[Discuss] On-site backups revisited - rsnapshot vs. CrashPlan

[gaf at blu.org (Jerry Feldman)]

On 02/22/2013 04:09 PM, Rich Pieri wrote:
> On Fri, 22 Feb 2013 12:29:23 -0800
> "Rich Braun" <richb at pioneer.ci.net> wrote:
>
>> underneath.  You need a list of files, you need a place to put file
>> meta data, you need a way to run comparisons.
> Problems solved more than thirty years ago. The most commonly used
> variations on UNIX systems are tar and cpio, with a nod to pax and *dump
> for some UNIXes. Add a database to find specific files and dates on a
> particular piece of media, sure. That makes sense and makes restoration
> easier by reducing time needed searching tapes/disks/whatever. But
> making a database integral to the backup, verification and recovery
> mechanisms needlessly complicates the system.
>
>
>> That has nothing whatsoever to do with whether Rich Braun is going to
>> lock a potential user into a particular solution, even if my code
>> were to be published and used. I'm not following your argument.
> The problem with your solution is that if you get hit by a bus and I
> have to come in and take over then I'm stuck with your "system". Even
> if I scrap it and implement something sane the older archives are still
> stored with your database as a requirement. I'm saddled with it for all
> eternity or until the old tapes/disks/whatever are reused. I can't
> tar/cpio/restore that data without the database and Ghu help me if the
> database is corrupted or lost.
>
>
>> I pretty much never choose a solution based on hard-and-fast criteria
>> like those.  Each reader here makes their own choices, and I'm sure
>> many agree with you.  But on this matter, you and I do not.
> Then I hope you never get hit by a bus.
>
> M-x old-man-voice
>
> I've been through this shit before with Legato Networker. Pain in the
> ass, that. Great-looking backup system that didn't back up the database.
> The result: a catastrophic failure requires rebuilding the ENTIRE
> database which entails reading the ENTIRE level 0 backup and all
> incremental and differential backups made against it. Then, and only
> then, can files be restored. Which makes restoring after catastrophe
> take more than twice as long as restoring a simple tar or cpio backup.
>
> M-x old-man-voice
>
> But hey! don't take my word for it. Assume a worst case scenario: no
> database, no "helpful" extras, just a stack of tapes or disks and a
> blank target computer. Do a full restore. This is, after all, the
> ultimate test of any backup system.
>
Rich P, how can I agree with you so much ;-). While I am not a
professional IT guy, I've been in the industry long enough to fully
respect backups and recovery, and the fact that getting hit by a bus in
Boston is probably likely these days.

-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90