rsnapshot backup



Reaction score: 2
Messages: 58

i would like to try out this backup but where in the below link does it specify the destination for the backup?

Once I know where to specify it, I would lthen like to do full system backups to a local internal hard drive NOT by ssh.
Using the examples in the link what would be the code I would need to include to achieve this type of backup.
Thank You.


Aspiring Daemon

Reaction score: 411
Messages: 704

I've never used rsnapshot, but looking at the manpage, you'll have to define source and destination in /usr/local/etc/rsnapshot.conf like e.g. backup / localhost/ for a local full backup.
Snapshot destination seems to be defined by e.g. snapshot_root /.snapshots/ in the configuration file, too.
There should be a /usr/local/etc/rsnapshot.conf.default or maybe /usr/local/share/examples/rsnapshot.conf.default for reference.

You should study and tweak the configuration file to your needs, before you start and take a look at rsnapshot(1) to understand what you are doing.


Active Member

Reaction score: 38
Messages: 159

I use rsnapshot to backup all my Unix-like systems. It's fast, efficient, and easy.

The backups are run from, and stored on, a FreeBSD ZFS server (named "sherman"), where I have the disk space needed.

Since rsnapshot uses a "pull model", that ZFS server must have the right to read file systems on the backup clients, via rsync.

It's possible for rsync to use a "transparent remote shell" other than ssh, but by far the most convenient way of doing this is certainly with ssh. I don't believe you will identify another sensible option.

To permit the required access, I copy the ZFS server's root user public key (e.g. ~root/.ssh/ to each client into the file ~root/.ssh/authorized_keys.

i.e. the root account on all clients is accessible by ssh key, without password, by the root account on the ZFS server. When setting up, you need to test this.

This means that (after the first use of the key on each client) the backups run transparently.

However it has security implications you may wish to contemplate -- you can mitigate, but in the end analysis, only root has the required power to do backups.

I run the backups with this script, as root, on the ZFS server:
[sherman.136] $ cat ~/bin/snap2disk
# See: /usr/local/etc/rsnapshot.conf
export PATH
cd /
rsnapshot -v $interval
Here are the configuration file details:
[sherman.137] $ grep -v "^# " /usr/local/etc/rsnapshot.conf | sed -e'/^$/d'
config_version    1.2
snapshot_root    /tank/backups/rsnapshot/
cmd_rm        /bin/rm
cmd_rsync    /usr/local/bin/rsync
cmd_ssh        /usr/bin/ssh
cmd_logger    /usr/bin/logger
cmd_du        /usr/bin/du
retain    sequential    40
verbose        2
loglevel    3
lockfile    /var/run/
rsync_long_args        --delete --delete-excluded --devices --group --hard-links --links --numeric-ids --owner --perms --recursive --relative --sparse --times
link_dest    1
## Backup clients
## a Linux physical host (KVM server)
backup        root@orac:/    orac/    exclude=/sys,exclude=/proc,exclude=/run,exclude=/dev,exclude=/media,exclude=/var/lib/vm,exclude=/spin/vm,exclude=/var/cache/apt/archives,exclude=/work
## the physical ZFS server backs up itself (excluding the tank)
backup        root@sherman:/    sherman/    exclude=/backups*,exclude=/cdrom,exclude=/cdrom1,exclude=/usb,exclude=/stick,exclude=/windows,exclude=/tank,exclude=/tank/myth,exclude=/mount
## a FreeBSD VM under KVM
backup        root@ritz:/    ritz/    exclude=/backups*,exclude=/cdrom,exclude=/cdrom1,exclude=/usb,exclude=/stick
## a FreeBSD VM under Virtualbox
backup        root@f113:/    f113/    exclude=/backups*,exclude=/cdrom,exclude=/cdrom1,exclude=/usb,exclude=/stick,exclude=/windows
## a Raspberry Pi (bastion firewall)
backup        root@piwall:/    piwall/    exclude=/sys/*,exclude=/proc/*
## many clients deleted...
I use a sequential rotation, keeping 40 backups (as of today, going back to Dec 22 2013). If you want daily/monthly/weekly rotations, you can sort that once it's working.