Created Tuesday 12 May 2015
I am in the process of migrating from the Bacula (http://www.bacula.org) backup/restore tool (v5) to the Burp (http://burp.grke.org/) software. In this short article I will talk a bit about the rationale behind that decision and give some pointers on how to set up a more flexible Burp environment.
Let me start with a bit of background regarding my use of Bacula. I started using Bacula well over 10 years ago when it was still v2 something and long before its main author Kern Sibbald decided to split up the software in a community and enterprise version. At the time of writing this article, the community version has matured to v7.x. As far as I can recall there was never a major release v4 of Bacula - v2 became v3 and then the versioning was bumped up to v5. After v5 the release numbers were evenly (enterprise) and oddly (community) divided to indicate for which audience they are intended.
I have used Bacula in a variety of places and situations over the years. From backing up home servers - covering both Linux and Windows hosts - to safeguarding real life production data in a commercial setting. I usually configured Bacula to operate with disk-based backups but at one point I did invest in a small, second-hand DDS auto-changer and ran my home backups and restores from tapes. Unfortunately the hardware died a few months after acquisition which forced me to revert back to a disk-based set-up.
Burp is a fork of the popular Bacula tool and its author Graham Keeling explains quite well why he forked from the original project on this page: http://burp.grke.org/why.html. Below are my own motivations which are in part overlapping with Graham's:
So how does Burp makes things easier and better compared to Bacula? To summarize these points:
I will not cover the basic set-up of a Burp backup environment. Please refer to the Burp documentation and web site for this.
Burp allows configuration information to be sourced from other, configuration files. This allows for a re-usable and modular set-up. For example, I use following standard exclude snippets.
$ vi incexc-comp.conf # include/exclude from compression exclude_comp=7z exclude_comp=ace exclude_comp=apk exclude_comp=arc exclude_comp=ark exclude_comp=arj exclude_comp=bz2 exclude_comp=cab exclude_comp=cbr exclude_comp=cbz exclude_comp=dar exclude_comp=deb exclude_comp=exe exclude_comp=gz exclude_comp=ice exclude_comp=jar exclude_comp=lhz exclude_comp=lz exclude_comp=lzo exclude_comp=pka exclude_comp=rar exclude_comp=rpm exclude_comp=sis exclude_comp=tgz exclude_comp=uha exclude_comp=xz exclude_comp=zip exclude_comp=z exclude_comp=zoo
$ vi incexc-dev.conf # include/exclude filesystems exclude=/proc exclude=/sys exclude=/media exclude=/mnt
# include/exclude filesystems exclude=/donotbackup exclude=/tmp # include/exclude filesystem types exclude_fs=tmpfs exclude_fs=devtmpfs
Above snippets can be added to any client backup definition (burp.conf) by including them as a source file:
# The following options specify exactly what to backup. # The server will override them if there is at least one 'include=' line on # the server side. . /etc/burp/incexc-client.conf . /etc/burp/incexc-comp.conf . /etc/burp/incexc-dev.conf . /etc/burp/incexc-tmp.conf
In this example the snippet incexc-client.conf will contain the actual file paths that do need backing up.
By applying the concept of include files, we can define a set of scheduling and retention policies which can be re-used in different backup definitions.
Example: a 3 monthly schedule with a backup taken once a week on Sunday between midnight and 7am (4 x 3 = 12 backups):
$ more 3-months-weekly.conf # keep backup for 3 months, run weekly # retention to 4x3 keep = 4 keep = 3 # schedule only a once week on sunday (00hrs-07hrs) timer_arg = 1w timer_arg = Sun,00,01,02,03,04,05,06
Example: a 3 monthly schedule with a backup taken once a day between 3am and 7am (7 x 4 x 3 = 84 backups):
$ more 3-months-daily.conf # keep backup for 3 months, run daily # retention to 7x4x3 keep = 7 keep = 4 keep = 3 # schedule daily (between 03hrs-07hrs) timer_arg = 1d timer_arg = Mon,Tue,Wed,Thu,Fri,Sat,Sun,03,04,05,06
Scheduling & retention policies are best kept on the Burp server and included there in the client configuration files in /etc/burp/clientconfdir. And keep in mind: 84 backups do not mean 84 copies of your data! (see also http://burp.grke.org/docs/shuffling.html)
Out-of-the-box Burp does not support the existence of multiple backup definitions for a single client. Instead it sees a client system or host as a single entity. Yet in a lot of cases it is useful to have your backup split up in different parts based on the type of data you need to safeguard, for example: OS vs database backup. Luckily, this kind of set-up is possible in Burp by defining multiple backup clients for one single host. To achieve this, we configure a separate burp.conf file for each backup client. This also gives us the flexibility to distinguish backups by:
In the following example we will define 2 backup definitions, one for backing up the operation system (OS) and one for backing up the WWW root of a web server.
First we do the necessary configuration on the Burp server:
$ vi /etc/burp/clientconfdir/os_client $ vi /etc/burp/clientconfig/www_client
Customize both files by defining at least an entry for the client password:
password = <client_password>
You can opt to use different passwords for each client or keep the password consistent for each backup client. In any, case, the password should match the password configured in the client configuration file on the Burp client host (see below).
$ vi /etc/burp/clientconfdir/os_client # retention & schedule . /etc/burp/clientconfdir/schedule/3-months-weekly.conf $ vi /etc/burp/clientconfdir/www_client # retention & schedule . /etc/burp/clientconfdir/schedule/3-months-daily.conf
In this example we used the scheduling and retention policies that I mentioned in the previous chapter. Both scheduling configuration files are sourced from separate files in the schedule sub-directory. You will need to create and populate this directory with the necessary information first of course.
Next, we do the configuration on the Burp client system:
$ mkdir /etc/burp/os_client $ mkdir /etc/burp/www_client
server = <server_name> password = <client_password> cname = <client_name>
You can choose to use different passwords for each client or keep the password consistent for each backup client. In any, case, the password should match the password configured in the client configuration file on the Burp server (see above).
Also adjust the paths for the ssl_cert and ssl_key settings. Since we are going to have 2 different backup clients, it makes sense to have 2 different SSL certificates generated as well. They will be stored in the sub-directory for each backup client. For example, for the www_client:
# Client SSL certificate ssl_cert = /etc/burp/www_client/ssl_cert-client.pem # Client SSL key ssl_key = /etc/burp/www_client/ssl_cert-client.key
$ burp -c /etc/burp/www_client/burp.conf -a l 2015-04-22 13:37:43: burp before client 2015-04-22 13:37:43: burp begin client 2015-04-22 13:37:43: burp auth ok 2015-04-22 13:37:43: burp Server version: 1.4.36 2015-04-22 13:37:43: burp Server will sign a certificate request 2015-04-22 13:37:43: burp Generating SSL key and certificate signing request 2015-04-22 13:37:43: burp Running '/usr/sbin/burp_ca --key --keypath /etc/burp/www_client/ssl_cert-client.key --request --requestpath /etc/burp/CA-client/foobar.csr --name foobar' generating key foobar: /etc/burp/www_client/ssl_cert-client.key Generating RSA private key, 2048 bit long modulus ...............................................+++ ........................+++ e is 65537 (0x10001) generating request foobar 2015-04-22 13:37:43: burp /usr/sbin/burp_ca returned: 0 2015-04-22 13:37:43: burp Sent /etc/burp/CA-client/foobar.csr 2015-04-22 13:37:43: burp Received: /etc/burp/www_client/ssl_cert-client.pem.370248 2015-04-22 13:37:43: burp Received: /etc/burp/ssl_cert_ca.pem.370248 2015-04-22 13:37:43: burp Rewriting config file: /etc/burp/www_client/burp.conf 2015-04-22 13:37:43: burp Re-opening connection to server 2015-04-22 13:37:48: burp begin client 2015-04-22 13:37:48: burp auth ok 2015-04-22 13:37:48: burp Server version: 1.4.36 2015-04-22 13:37:48: burp nocsr ok 2015-04-22 13:37:48: burp SSL is using cipher: DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH 2015-04-22 13:37:48: burp List finished ok 2015-04-22 13:37:48: burp after client
$ vi /etc/cron.d/burp # os_client 15,35,55 * * * * root /usr/sbin/burp -c /etc/burp/os_client/burp.conf -a t # www_client 17,37,57 * * * * root /usr/sbin/burp -c /etc/burp/www_client/burp.conf -a t