On 12/19/2013, 04:00 , lists@xxxxxxxxxxxxxxxxxx wrote:
> 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
I would agree that BackupPC is a great tool, stable and well respected,
and I have to admit I didn't give it a fair chance before moving on to a
simple, crude homebrew solution many years ago.
One thing I neglected to mention about using inotify+lsync for a
near-real-time secondary file server is that if the primary server
croaks, I can quickly switch users to the secondary. When the primary
server is repaired, a one-shot rsync to it brings it back to the current
state of users' files. This conflicts a bit with non-deletion of old
files on the secondary, but it keeps users going while repairs are made.
I haven't had to use this trick ... yet. ZFS Raid-z3 and disk hot
swap have done their jobs well so far.
I'm toying with the idea of keeping a marker file on the secondary whose
timestamp can be used to limit rsync back to the primary to only those
files which got added while the secondary was being used. That would
take care of the non-deleted files issue on the secondary. Fortunately
there are no database files involved in any of this.
Chuck
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
