User talk:Renich/HowTo/Bacula

Where should backups be stored?

After checking the FHS, there's a bit of confusion about this issue. There are 3 possible locations: /srv, /var/backups and /var/spool/backups.

I have decided to put them in /var/backups since it's mentioned in the FHS and it's relevant to me.

Nevertheless, Southern_Gentlem; of irc://freenode.net/#fedora suggested to use /srv since he uses it and Red Hat uses it.

Anyway, please, feel free to discuss this here. Renich 00:41, 28 January 2010 (UTC)

When you ask "where should backups be stored", what exactly do you mean? Bacula can write it's backups to tape, dvd, removable media. Do you mean the backup database, which can also be stored under the database system?

Any files used as volumes for bacula should be stored in a location of the user's choice: the user needs the ability to be able to add capacity as necessary. For the catalogue, this is probably best stored in the default database location. --Barry905 02:23, 1 March 2010 (UTC)

Well, you're right. I should've specified the case of using a SAS or NAS. It should be mounted, according to the FHS, in /var/backups. This is all.

I think it's an important matter, since we use SELinux. This should be standarized and secured by SELinux. A umask of 177 should be used too.

In the case the user chooses an alternate location (for example, /mnt or /srv) we should note the correct SELinux context to be used and how to configure, don't you think? Renich 04:04, 1 March 2010 (UTC)

Password generation

I have run intro trouble while using signs in the passwords. I'd rather advise people to use lower and upper caps and numbers. I'd like some feedback about this, if possible. Renich 21:23, 19 February 2010 (UTC)

One of the biggest problems with passwords in the bacula system is relating passwords to each other: in other words which passwords should match which other. Some sort of architecture is really required here. --Barry905 02:33, 1 March 2010 (UTC)

Well, I really recommend using apg. This tool helps a lot with password generation and it's available in the repos.

We should, also, specify, the password relationships, as you say. Renich 04:07, 1 March 2010 (UTC)

I got this from thebacula documentation: perhaps we shouild include it here?

Here is sort of a picture of what names/passwords in which files/Resources must match up:

http://www.bacula.org/5.0.x-manuals/en/main/main/img20.png

What do you think? --Barry905 02:17, 5 March 2010 (UTC)

Excelent! ;) I'll add it as soon as I can figure out how to put an image there ;) Renich 09:14, 7 March 2010 (UTC)

You know what, we should email the bacula authors to let them know we're using their image and to see if it's ok with them... if not, to remove it. Also, they could lend an eye to the HowTo, don't you think? Renich 09:21, 7 March 2010 (UTC)

Distributed configuration

I like creating:

/etc/bacula/conf.d/

And adding all the specific conf files there. Afterwards, I just add the following to /etc/bacula/bacula.dir.conf:

@/etc/bacula/conf.d/foo-client.conf
@/etc/bacula/conf.d/bar-client.conf
@/etc/bacula/conf.d/jobs.conf

I'd love some feedback and suggestions on how to make this even better; so one can just add clients and jobs and stuff and have them well organized. A script for generating this would be awesome! ;) Renich 21:27, 19 February 2010 (UTC)

Just found out this piece of code:

# Include subfiles associated with configuration of clients.
# They define the bulk of the Clients, Jobs, and FileSets.
# Remember to "reload" the Director after adding a client file.
#
@|"sh -c 'for f in /etc/bacula/clientdefs/*.conf ; do echo @${f} ; done'"

Source: [1]

General Comments

This how-to could use a general discussion of the architecture of bacula: a description of the functionality of each component (the director, the client daemon, the file daemon, the catalogue database) and how they interact.

A discussion on backup strategies might also be in order. The strategy adopted for backups drives to a large degree the volumes, pools and jobs to be configured. The most time consuming part of setting up bacula is to create the .conf files to configure each of the components. Installation is relatively easy. --Barry905 03:04, 1 March 2010 (UTC)

I agree with you, totally. We should, also, point out this at the current bacula manual. There's a concept definition somewhere... ;) Renich 04:09, 1 March 2010 (UTC)

Try this for a concept definition:

Basic description of bacula:

The basic system comprises three components: the director, the file daemon and the storage daemon. To take them in reverse order, the storage daemon takes data from the file daemon and stores it wherever directed. The file daemon gets the data (files) to be backed up and passes it to the storage daemon. The director then does the rest of the work; that is, defines the task to be performed and the schedule for them to be performed. The basic unit for a backup is the job. This describes what is to be backed-up, when it is to occur and where the data is to be stored.

Some definitions:

Volume - basic unit of storage, e.g. a tape, a dvd, a file on a hard drive

Pool - a collection of volumes, usually used for the same purpose

FileSet - the files to be backed up

Job - the overall definition of the work to be performed

Catalogue - storage area for information about all jobs that have run

Full Backup - every file in the FileSet is to be copied

Incremental - a backup that contains all files that have changed since the last full, differential or incremental backup

Differential - a backup that contains all files that have changed since the last full backup

To configure each component there is a .conf file in /etc/bacula. Each file defines the interconnectivity with the others, so you need make sure all the passwords agree one with another (you'll see what I mean when you look at the details). bacula-sd.conf defines the storage devices that you want to use, and bacula-fd.conf merely defines itself. The main work is done in bacula-dir.conf, which sets up the everything else. The configuration files are used to define those components that are to be run automatically: ad-hoc jobs can be run through the console.

Of volumes, pools, filesets, schedules and jobs:

The method of operation for bacula is that the requisite data is stored on Volumes, which are essentially container files stored on differing media. These volumes are organized into Pools in a many to one relationship. Filesets are the collections of files that you want to backup using the same volumes. The timing for preforming backups are defined using Schedules, and all these are tied together as jobs, which define the pool (and hence volumes) to be used to create backups of the files defined within a fileset at a particular schedule.

--Barry905 05:41, 1 March 2010 (UTC)

Ok, done! Very nice! Did you take this from the manual or did you interpret it? We should be weary of licencing difficulties ;) Renich 05:49, 1 March 2010 (UTC)

SELinux

I haven't had much trouble with SELinux. Yet, I'm not so well informed on the creation of policies and stuff so, If anyone can tell me anything about this, would be awesome! Renich 21:29, 19 February 2010 (UTC)