Scheduled Backups With Rsyncbackup On Debian Etch - Page 2

Want to support HowtoForge? Become a subscriber!
 
Submitted by o.meyer (Contact Author) (Forums) on Thu, 2008-04-10 18:12. ::

4.3 Configuration

4.3.1 Main

This file contains the standard rsync options for all backups.

vi /etc/rsyncbackup/config.conf

The content could look like this:

--stats
--progress
--links
--hard-links
--times
--recursive
--perms
--owner
--group
--compress
--backup

Note: You can also use the short style - e.g.: "-p" instead of "--perms". I chose the long style for better understanding.

 

4.3.2 Sources

This file contains all files/folders that shall be available in the backup sets.

vi /etc/rsyncbackup/sources.conf

The content could look like this:

configs|local:/etc|true|
logs|local:/var/log|true|

The syntax: tag|source path|conditional shell code|optional rsync options

Note: "true" means that this source is enabled - "false" would disable it.

 

4.3.3 Destinations

This file contains all destinations that shall be available in the backup sets.

vi /etc/rsyncbackup/destinations.conf

The content could look like this:

store_configs|ssh[key=id_rsa,incremental=7,tag=increment]:root@192.168.0.102:/backups/configs/|/usr/bin/traceroute -m 2 192.168.0.102|--bwlimit=300 --delete
store_logs|ssh[key=id_rsa,incremental=7,tag=increment]root@192.168.0.102:/backups/logs/|/usr/bin/traceroute -m 2 192.168.0.102|--bwlimit=300 --delete
store_manual|ssh[key=id_rsa]:root@192.168.0.102:/backups/manual/|/usr/bin/traceroute -m 2 192.168.0.102|

The syntax: tag|destination path (optional with ssh & incremental settings)|conditional shell code|optional rsync options

In this example (first and second destination) we use our backup server as destination and authenticate against it with the private ssh key. We want to keep seven increments (incremental=7) whose names begin with "increment" (tag=increment). The optional shell code (/usr/bin/traceroute -m 2 192.168.0.102) will return true (and start the backup) if the backup server is running and at least two hops away. Also we use two optional rsync options (--bwlimit=300 and --delete) - so we have a bandwidth limit for this destination and deleted files on the main server will also be deleted on the backup server (for a new increment). Please note that you can only use ONE source for a backup set that has an incremental destination.

 

4.3.4 Backup Sets

This file joins the souces with the destinations.

vi /etc/rsyncbackup/backupset.conf

It could look like this:

[manual]
configs,logs|store_manual|true|

[daily]
logs|store_logs|true|

[weekly]
configs|store_configs|true|

As you can see, we've created three backup sets.

The syntax: source tags|destination tags|conditional shell code|optional rsync options

 

4.4 Test

Now let's test if our configuration is ok.

rsyncbackup -x /etc/rsyncbackup -vv -d -s manual

The output should look like this:

PATH DIR:/etc/rsyncbackup/
LOG DIR:/etc/rsyncbackup/logs
CONFIG_FILE:/etc/rsyncbackup/config.conf
SOURCE FILE:/etc/rsyncbackup/sources.conf
DESTS_FILE:/etc/rsyncbackup/destinations.conf
BACKUPSET_FILE:/etc/rsyncbackup/backupset.conf
BACKUPSET:manual

Backup set 1 configs to store_manual
Source : configs
Source dir : [local] /etc
Source opts :
Source cond : true
Destination : store_manual
Destination dir : [ssh] root@192.168.0.102:/backups/manual/ [key=id_rsa,sshport=22]
Destination opts:
Destination cond: /usr/bin/traceroute -m 2 192.168.0.102
Config options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup
Backupset opts : true
All options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup
All conditions : /usr/bin/traceroute -m 2 192.168.0.102 true true

Backup set 2 logs to store_manual
Source : logs
Source dir : [local] /var/log
Source opts :
Source cond : true
Destination : store_manual
Destination dir : [ssh] root@192.168.0.102:/backups/manual/ [key=id_rsa,sshport=22]
Destination opts:
Destination cond: /usr/bin/traceroute -m 2 192.168.0.102
Config options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup
Backupset opts : true
All options : --stats --progress --links --hard-links --times --recursive --perms --owner --group --compress --backup
All conditions : /usr/bin/traceroute -m 2 192.168.0.102 true true

If all looks ok, we'll do our first backup.

rsyncbackup -x /etc/rsyncbackup -b -s manual

After that the backup should be on the backup server - if not, have a look at the logs (/etc/rsyncbackup/logs/ or /var/log/rsyncbackup/).

 

4.5 Cronjob

Now we create cronjobs for the backups.

crontab -e

The content could look like this:

# m h  dom mon dow   command
# Backups
00 02 * * *     /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s daily >> /var/log/rsyncbackup/backup.daily.log
00 04 * * 0     /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s weekly >> /var/log/rsyncbackup/backup.weekly.log

The backup set "daily" will be backed up every day at 2:00am, the backup set "weekly" every sunday at 4:00am. Optional, if you want to get mails when errors occurs, you can add the option "-e email@domain" to the rsyncbackup command - it should look like this:

# m h  dom mon dow   command
# Backups
00 02 * * *     /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s daily -e email@domain >> /var/log/rsyncbackup/backup.daily.log
00 04 * * 0     /usr/local/bin/rsyncbackup -x /etc/rsyncbackup -b -v -s weekly -e email@domain >> /var/log/rsyncbackup/backup.weekly.log

 

4.6 Manual

Please have a look at the manual for further information. It is included in the package that you downloaded in step 4.1.

 

5 Links


Please do not use the comment function to ask for help! If you need help, please use our forum.
Comments will be published after administrator approval.
Submitted by mikemcc (registered user) on Sat, 2008-07-12 07:02.

Interesting article. Thanks for writing it up.

 I don't allow shared root keys on any production machines (i.e., fine in a lab or a home network, but not at work), so as I read the article I wondered what I'd need to do in order for a non-root account to make comprehensive backups. I'd have no object to two "backup" accounts having shared keys, so I suppose as long as the "backup" user on the client machine has read access to all important files, I'd be good to go.

Thanks again for taking the time to write this up.