In last month's article, we discussed using the rsync utility on Linux to perform backups of data. This month, we will look at utilizing the rsnapshot utility to create rotating backups of data over periods of time.
rsync creates a single backup; when it completes, the destination contains exactly the files that were on the source when it ran. rsnapshot provides functionality to store rotating configurations, so that a full backup is available of all the files in the backup process at that time.
The first thing to choose is where the backups will be kept. This will typically be a mounted drive on a backup array that has enough storage to hold everything being backed up. How much storage is required (determined by the size of the folder(s) being backed up), how often they change, and how many past backups are being kept (which we will cover momentarily). To set the master backup location, define the following in the configuration file:
All the storage that rsnapshot requires will now be within this folder.
The standard backup for Smart Software is to store 7 daily backups, 3 weekly backups, and 2 monthly backups. This provides backups for the past quarter with the most graunularity in the past week. This configuration is very easy to achieve with rsnapshot. In the configuration file (typically /etc/rsnapshot.conf) there is a 'backup intervals' section to specify whether to perform hourly, daily, weekly, and/or monthly backups and how many to perform. To store the above configuration that we use, our interval configuration would be:
interval daily 7 interval weekly 3 interval monthly 2
Now, each time rsnapshot runs, it will perform the appropriate backup. The resulting directory listing of a full backup set will look like:
daily.0 daily.1 daily.2 daily.3 daily.4 daily.5 daily.6 montly.0 montly.1 weekly.0 weekly.1 weekly.2 weekly.3
rsnapshot will use hard links where possible to reduce the size of the backup set. Hard links are pointers for files. So, to anything reading the folders or files, everything is exactly what it expects, but at the filesystem level, all of the backups may point at a single file if that file has not changed over the course of the backups. Once the file changes, its new version is saved, and new backup folders point to it instead of the old file. Once the last backup cycles out that points at the old file, that old file is removed.
This is all well and good, but to this point the program still knows nothing about what to back up. To tell rsnapshot what files to backup, simply tell it what paths need to go to what folder:
backup /var/www/html/ htmlbackup/
The above configuration line tells rsnapshot that /var/www/html should be backed up into the htmlbackup folder. Once this is done, after its first execution, the directory tree for daily.0 should look like the following:
daily.0 - htmlbackup - var - www - html - [files under /var/www/html]
To execute a script to perform a database backup, use a command similar to the following:
backup_script /path/to/script unused
This executes the script desired. The backup_script configuration does require a folder for a destination even though the script executed may do something completely separate, so in this case we just give it a folder that is not being used.
The backup and backup_script elements are executed in order, so that can be used to export database backups into a folder path that is then backed up.
This is just a sample of what we can do. We have 15 years of experience working in nearly every technology and industry. Whatever you are doing, we've done it and are prepared to tackle your project. Reach out and we will discuss it with you.