rsnapshot

Choose the directory where you want to store the file system back ups, in this case I will store the back ups in /mnt/backups/

/etc/rsnapshot.conf

# All snapshots will be stored under this root directory.
#
snapshot_root   /mnt/backups/

Uncomment the lines refering to the unix commands cp, du, ssh (if you want to do remote back ups) and rsnapshot-diff, etc. This section of the file should look like this:

/etc/rsnapshot.conf

# LINUX USERS:   Be sure to uncomment "cmd_cp". This gives you extra features.
# EVERYONE ELSE: Leave "cmd_cp" commented out for compatibility.
#
# See the README file or the man page for more details.
#
cmd_cp          /usr/bin/cp

# uncomment this to use the rm program instead of the built-in perl routine.
#
cmd_rm          /usr/bin/rm

# rsync must be enabled for anything to work. This is the only command that
# must be enabled.
#
cmd_rsync       /usr/bin/rsync

# Uncomment this to enable remote ssh backups over rsync.
#
cmd_ssh /usr/bin/ssh

# Comment this out to disable syslog support.
#
cmd_logger      /usr/bin/logger

# Uncomment this to specify the path to "du" for disk usage checks.
# If you have an older version of "du", you may also want to check the
# "du_args" parameter below.
#
cmd_du          /usr/bin/du

# Uncomment this to specify the path to rsnapshot-diff.
#
cmd_rsnapshot_diff      /usr/bin/rsnapshot-diff

# Specify the path to a script (and any optional arguments) to run right
# before rsnapshot syncs files
#
#cmd_preexec    /path/to/preexec/script

# Specify the path to a script (and any optional arguments) to run right
# after rsnapshot syncs files
#
#cmd_postexec   /path/to/postexec/script

Rsnapshot allows named backup levels that retain a given number of previous backups.

When configuring these, note that the first in the list will be the only one that actually backs up files from the file system AND rotates its own previous backups. The rest will ONLY rotate previous backups, creating its newest backup from the oldest backup created by the previous item on the list. So, the order these are listed in the configuration file are very important.

Replace the default "BACKUP LEVELS / INTERVALS" section in the rsnapshot configuration file:

• When is called, a new backup will be created from the file system, and saved in <snapshot_root>/hourly.0/. The rest of the retained backups will continue to get incremented each time the command is run. So eventually, what was <snapshot_root>/hourly.0, will become <snapshot_root>/hourly.23/. Then the next time the command is run, this will be deleted.

• When is called, it will create <snapshot_root>/daily.0/ from the <snapshot_root>/hourly.23/ backup if it exists. Otherwise, rotation works the same way.

• Likewise, when rsnapshot weekly is called, it will create <snapshot_root>/weekly.0/ from the <snapshot_root>/daily.6/ backup if it exists. The pattern follows the same for each additional retain level that is configured.

Using the above config, you could call:

every hour  

every day  

rsnapshot weekly every week

rsnapshot monthly every month

This would give you a robust 12 months of backups while minimizing the space taken up by older snapshots.

If you just wanted to run this same config, but only backup daily, you would need to comment out the hourly backup level. Otherwise calling would never actually backup any files since it is not the first on the list.

This is the section where you tell rsnapshot which files you actually want to back up. You put a parameter first, followed by the full path to the directory or network path you are backing up. The third column is the relative path you want to back up to inside the snapshot root. In this example, backup tells us it is a backup point. is the full path to the directory we want to take snapshots of, and is a directory inside the we are going to put them in. Using the word localhost as the destination directory is just a convention. You might also choose to use the server's fully qualified domain name instead of localhost. If you are taking snapshots of several machines on one dedicated backup server, it is a good idea to use their various hostnames as directories to keep track of which files came from which server.

In addition to full paths on the local filesystem, you can also backup remote systems using rsync over ssh. If you have ssh installed and enabled - via the parameter - you can specify a path like: This behaves fundamentally the same way, but you must take a few extra things into account:

• The ssh daemon must be running on example.com

• You must have access to the account you specify the remote machine, in this case the root user on example.com.

• You must have key-based logins enabled for the root user at example.com, without passphrases. If you wanted to perform backups as another user, you could specify the other user instead of root for the source (i.e. user@domain.com). Please note that allowing remote logins with no passphrase is a security risk that may or may not be acceptable in your situation. Make sure you guard access to the backup server very carefully! For more information on how to set this up, please consult the ssh man page, or a tutorial on using ssh public and private keys. You will find that the key based logins are better in many ways, not just for rsnapshot but for convenience and security in general. One thing you can do to mitigate the potential damage from a backup server breach is to create alternate users on the client machines with uid and gid set to 0, but with a more restrictive shell such as scponly.

• This backup occurs over the network, so it may be slower. Since this uses rsync, this is most noticeable during the first backup. Depending on how much your data changes, subsequent backups should go much, much faster since rsync only sends the differences between files.

There is an extra line. With this parameter, the second column is the full path to an executable backup script, and the third column is the local path you want to store it in (just like with the parameter). For example:

In this example, rsnapshot will run the script /usr/local/bin/backup_mysql.sh in a temp directory, then sync the results into the localhost/mysql/ directory under the snapshot root.

Your backup script simply needs to dump out the contents of whatever it does into its current working directory. It can create as many files and/or directories as necessary, but it should not put its files in any pre-determined path. The reason for this is that rsnapshot creates a temp directory, changes to that directory, runs the backup script, and then syncs the contents of the temp directory to the local path you specified in the third column. A typical backup script would be one that archives the contents of a database. It might look like this:

When you have made all your changes, you should verify that the configuration file is syntactically valid, and that all the supporting programs are where you think they are. To do this, run rsnapshot with the configtest argument:

# rsnapshot configtest

If all is well, it should say Syntax OK. If there is a problem, it should tell you exactly what it is. Make sure your configuration file is using tabs and not spaces, etc.

The final step to test your configuration is to run rsnapshot in test mode. This will print out a verbose list of the things it will do, without actually doing them. To do a test run, run this command:

# rsnapshot -t hourly

This tells rsnapshot to simulate an "hourly" backup. It should print out the commands it will perform when it runs for real.

If the destination drive is in an external enclosure connected via USB or eSATA, it may not have mounted during boot or may otherwise be unmounted at the time rsnapshot is scheduled to begin. If rsnapshot is configured to write to a path that always exists, e.g. , the data will be backed up on whichever hard drive is mounted as the root directory rather than the desired external drive.

To remedy this situation one must configure rsnapshot to depend upon the disk being mounted to the expected mount point. There are two actions required: alter /etc/fstab and /etc/systemd/system/rsnapshot@.service.

Systemd will read the /etc/fstab file and create unit files for all of the mount points therein. For this setup we need to add one, optionally two, configuration options to the mount point. At the end of the options column for the desired mount point add and, if you want the mount point to unmount after inactivity, . The value 10m can be changed to any value you wish. See and for additional details about the options available.

An example mount point:

After changing /etc/fstab, run a daemon-reload so systemd picks up the changes made. Check that the mount and automount units look correct:

Finally, edit /etc/systemd/system/rsnapshot@.service and add the following line in the "[Unit]" section:

/etc/systemd/system/rsnapshot@.service

[Unit]
Requires=mnt-backups.mount
After=mnt-backups.mount

To ensure everything is configured properly check that the rsnapshot service units now require the mount point: