On 14Aug2022 15:22, Emmett Culley <lst_manage(a)webengineer.com> wrote:
I've been using BackupPC for many years. It can use rsync via ssh
for
remote backups or rsync directly for local (LAN) backup. It can
automatically dedup as well.
We had a client using BackupPC. Maybe for a single PC it works well.
They were backing up several (well over 10) PCs to a NAS. It hammered
the system in both I/O and CPU. Combined with some (old kernel)
filesystem bugs, it would mangle the filesystem. It seems to do the
rsync protocol _in Perl_ at the BackupPC end, and uses an elaborate
hash-named file tree for the deduplication function. It needed a special
web interface to browse/restore.
It kind of works, but does not scale.
Now we use histbackup (disclaimer: a script of my own similar in use and
implementation to rsnapshot). The backups are MUCH faster and we haven't
had the (again, ancient kernel) filesystem bugs at all. because even
though we run the backups in series, it is still much faster.
Basic scheme is:
- a directory per target (machine:subdir)
- timestampted hardlinked subtrees in each of the targets
Hardlink the previous backup to a new tree for today's backup, rsync
from the target into the new tree.
rsnapshot does the same kind of thing and modern rsync even has a mode
to do the "new hard link tree and sync" part of this as a command line
switch.
The trees are just... directory trees you can cd around in etc.
We NFS export them from the NAS read only so they can be directly
browsed. Because its NFS, the UIDs etc are identical and therefore
people can't brwose stuff they can't browse in the live filesystems
anyway.
These days I use this script:
https://github.com/cameron-simpson/css/blob/main/bin-cs/run-backups
for my personal backups. I'm usually prepared to rebuilt an utterly
failed machine instead of restoring an OS from backup.
Cheers,
Cameron Simpson <cs(a)cskk.id.au>