Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.



BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org