On 12/18/2013 07:50 AM, Les Mikesell wrote:
> I've always considered backuppc to be one of those rare things that
> you set up once and it takes care of itself for years. If you have
> problems with it, someone on the backuppc mail list might be able to
> help. It does tend to be slower than native rsync and especially bad
> at handling huge directories, but sometimes you can split up large
> filesystems into smaller subdirectory runs and if necessary you can
> use the ClientAlias feature to make it look like a single large host
> is several different systems so you can skew the full and incremental
> runs of different areas to different days.
BackupPC is a great product, and if I knew of it and/or it was available
when I started, I would likely have used it instead of cutting code. Now
that we've got BackupBuddy working and integrated, we aren't going to be
switching as it has worked wonderfully for a decade with very few issues
and little oversight.
I would differentiate BackupBuddy in that there is no "incremental" and
"full" distinction. All backups are "full" in the truest sense of the
word, and all backups are stored as native files on the backup server.
This works using rsync's hard-link option to minimize wasted disk space.
This means that the recovery process is just copying the files you need.
Also, graceful recovery for downtime and optimistic disk space usage are
both very nice. (it will try to keep as many backup savepoints as it can
disk space depending)
I'm evaluating ZFS and will likely include some features of ZFS into
BBuddy as we integrate these capabilities into our backup processes.
We're free to do this in part because we have redundant backup sets, so
a single failure wouldn't be catastrophic in the short/medium term.
-Ben
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
