Shamelessly stolen from http://www.bacula.org/rel-manual/What_is_Bacula.html
Bacula is a Client/Server network based backup program, with a simple modular design. There are 5 main components.
- Bacula Director
- The program that supervises all the backup, restore, verify and archive operations. The system administrator uses the Bacula Director to schedule backups and to recover files.
- Bacula Console
- The program that allows the administrator or user to communicate with the Bacula Director
- Bacula File services
- The software that is installed on the machine to be backed up. It is specific to the operating system on which it runs and is responsible for providing the file attributes and data when requested by the Director. The File services are also responsible for the file system dependent part of restoring the file attributes and data during a recovery operation.
- Bacula Storage services
- The software programs that perform the storage and recovery of the file attributes and data to the physical backup media or volumes. In other words, the Storage daemon is responsible for reading and writing your tapes (or other storage media, e.g. files).
- Catalog services
- Comprised of the software programs responsible for maintaining the file indexes and volume databases for all files backed up. The Catalog services permit the System Administrator or user to quickly locate and restore any desired file. The Catalog services sets Bacula apart from simple backup programs like tar and bru, because the catalog maintains a record of all Volumes used, all Jobs run, and all Files saved, permitting efficient restoration and Volume management. Fink uses PostgreSQL as it's database backend.
Any of these programs can be run on different hosts, but with the exception of the storage daemon they are all located on finch. The storage daemon is run on our backup server, backup.finkproject.org, and we have a set of scripts for each backup job that are run before and after to setup the backups (dump DBs, start ssh tunnel, cleanup).
The master config file is the director's [/etc/bacula/bacula-dir.conf]. In it is all the information needed to be able to backup the servers it manages. Since each component of the backups system is it's own daemon, the host, port, and passwords to communicate with them are all listed in the conf file. All options need to match the ones in the daemon's config, or communication will fail. We use RunBeforeClient and RunAfterClient to run scripts that setup or cleanup the backup, including db dumps and ssh tunnels to the backup server. Each job needs its own script, and they are run as root, so care must be taken to sudo to another user to prevent disasters.
Schedules and Rotation
- We do a monthly Full Backup of the server, with the last 6 month's worth of backups kept.
- We keep weekly Differential Backups, from the last Full Backup, with the last 6 weeks kept.
- Daily backups are performed and kept for 1 week's time.
See http://www.bacula.org/rel-manual/Automated_Disk_Backup.html for an example conf
Things are a little weird on the backup server, owing to the fact that we do not have admin access. We manually extract the bacula-sd deb and missing deps to $HOME/bacula, and modify the init.d script to use the absolute locations and LD_LIBRARY_PATH. TODO is accept connections and listen only on localhost. Maybe we should also use a non-standard port in order to further obscure the fact we run a bacula daemon?