David wrote at about 10:51:55 +0200 on Thursday, August 20, 2009:
 > Thanks for the replies so far :-) They were very informative.
 > 
 > About BackupPC itself, I'm still evaluating whether or not to actually
 > use it, but I'm starting to decide against it. Here are my reasons:
 > 
 > 1) We're not backing up a lot of machines with a huge amount of
 > duplicate data between machines. Just about every server and user's
 > data is different. The common stuff between servers (/usr/, etc),
 > isn't that large (the vast majority of storage is for unique data).
 > For user machines, we backup their user folders, not the entire C:
 > drive. Pooling common files from different machines isn't a priority.

But BackupPC gives it for free...
 > 
 > 2) A big problem, is user dbx files, 2 GB etc .. don't want to store
 > multiple copies of those. Actually a reverse diff-based approach works
 > a lot better imo.

This is certain a limitation unless and until block-level diffs are
implemented.

 > 
 > My current backup system lets me define which kind of "history
 > storage" system to use for backups. rdiff-backup (for most places,
 > where it works), and hardlinks, for servers which cause problems with
 > rdiff-backup (although that led to my current problems with du &
 > locate, which I'm currently researching). I might add more "history
 > storage" systems, if I find something more appropriate later (eg
 > HashBackup or gibak), or write my own. I lose that kind of flexibility
 > if I change to most "fully integrated, prepackaged" backup systems
 > (like BackupPC and most others), as opposed to command-line tools
 > which you can script and mix & match to get a backup system that works
 > best for your setup.
 > 
 > Which is also why I asked earlier about the ability to mix and match
 > parts of BackupPC separately :-)
 > 
 > Yeah, there are downsides to home-brewed stuff, and I prefer to use
 > premade stuff most of the time. But when none of the existing stuff
 > matches my needs, I won't hesitate throw together scripts that do it
 > better (for my needs), by scripting command-line tools, or writing new
 > tools and then calling them. That's the unixy way :-). You can read
 > more here:
 > 
 > http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy

I think we all know the Unix philosophy. However, the point about
backups is that they need to be rock solid and need to be there 100%
in the rare case when you need them. Most people don't have the time
or ability to test their homebrew backup scripts leading to unpleasant
surprises when they actually need to use them.

 > 
 > 3) The incremental/full system of backuppc is bothersome. I don't want
 > to copy over full servers later, after initial rsync (or if I do,
 > relatively infrequently, like once a month). I actually do want most
 > of the backups to be incremental (ie, how rsync does it in hardlink
 > snapshot-like schemes). But, a lot can change during incrementals, and
 > dealing with those multiple incremental levels seems kind of annoying,
 > although I'm sure there are good reasons for them.

I frankly don't understand what you are saying here. You can have as
many or as few levels of incrementals as you like.

 > 4) Possibly lots of redundant config in the text files
 > 
 > This is very minor in the grand scheme of things, but it's a pet peeve
 > of mine, with backup systems I've seen in general. Every single server
 > or user backup etc has the complete backup details in the config
 > files, even if they are 99% similar.
 > 
 > This violates the "DRY" (Don't Repeat Yourself) programming principle
 > (yeah, I treat backup configuration as a programming exercise :-) ).
 > 
 > Like if you have 40 servers, then it looks like you need to define all
 > the details for all servers, rather than just defining the parts that
 > changed per-server.

WRONG. You only need to define the variables that differ. If all your
backups are the same then you can use just a single config.pl. You
only use individual host config files to specify differences. Also,
since the config files are perl code you can write as much or as
little perl code to further customize the variables by hostname or class.

 > 
 > In my own config, adding a new server to the backup config is as
 > simple as adding one line, like this to my server backups config file:
 > 
 >     bkp('192.168.0.2 complete backup') # Router
 > 
 > This basically adds the complete specification for a backup, to a list
 > of backups to be run (after all the backup configs are loaded into
 > memory, and filtered according to user command-line arguments and so
 > on to the main backup script, which itself is run daily from cron).
 > 
 > Earlier in the config file for server backups, there is a Python class
 > definition, where you define the details, kind of like a template. And
 > those classes can also inherit from other Python classes, to customize
 > a few details. Or take advantage of other Python programming
 > constructs.

Same with BackupPC except the language is Perl. Individual host files
inherit from the config file and you can write additional Perl code to
further filter and customize.

 > 
 > Also, passwords are stored separately, in a secure text file, using a
 > ~/.pgass-like format, that supports wildcards for individual fields
 > (for those of you familiar with PostgreSQL). eg:
 > 
 >     rsync:192.168.0.2::root:rrbackups:gib5Gryn
 >
 > (gib5Gryn is a password I just generated with apg, for this
 > example)

Unnecessary when using rsync over ssh -- since Backuppc uses the user
backuppc and the security is equivalent to the security of the ssh
setup, which again is probably better tested than a homebrew approach.

 > 
 > Although, these types of config files are more oriented at people who
 > prefer to edit text files directly (eg, programmers like myself :-) ),
 > and understand how classes, inheritance, and other programming-related
 > things work, rather than going through a web frontend. And adding a
 > templating-type system can introduce more complexity by itself.
 > 
 > Web frontends like BackupPC's are probably a lot more usable in
 > general though, especially for non-programmers :-)

I don't use the web frontend. I do all my customizations in the
config.pl and host files.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
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/