Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am using Bacula to connect to servers remotely (in a different DC) and backup.

Due to speed constraints and no bogging the office network down during the day, I dont see it is feasible to perform a full backup of our 4 servers at the same time, so instead we can split out the full backups so each week one server has a full backup, in rotation.

Requirement 1 - Load spreading of full backup transfers

If we had 4 servers, we want to perform a full backup in rotation as follows:

  1. myhost1 => 1st of every month full, incremental all others.
  2. myhost2 => 8th of every month full, incremental all others.
  3. myhost3 => 15th of every month full, incremental all others.
  4. myhost4 => 22nd of every month full, incremental all others.

Given any particular date, we want to keep a full backup, plus the last full backup before that. All incremental from now to the most recent full backup should be kept.

Requirement 2 - Full and Incremental in seperate pools

I have two storage pools, one for incremental and one for full, we need to tell Bacula to use pool-full if a incremental snapshot cannot find a previous full, otherwise use the pool-inc.

Requirement 3 - Scalability

Potentially there could be more servers in future, if I wanted to rotate them over Saturdays and Sundays (giving up to 8 schedules per month on days [1,2], [8,9], [15,16], [22,23]). Is there any easier way to define jobs as I can see it becoming a large configuration file.

share|improve this question

closed as not constructive by Michael Hampton, mdpc, Lucas Kauffman, Ward, Scott Pack Jan 25 '13 at 3:39

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

What, precisely, is your question? I see a description of your environment (with what appears to be a sane backup schedule given your requirements) and a configuration dump, but I can't figure out what you want from us... – voretaq7 Jan 24 '13 at 20:02
I am new to Bacula (and backup in general) so I am asking is my schedule sensible (or are there better ways of doing it), and what is my config missing (I have tried as best as I can, but need an experienced eye to check if it is correct or amend as needed) – g18c Jan 24 '13 at 21:01
Not sure why this was closed, voretaqs answer was just what i was looking for – g18c Jan 25 '13 at 22:47
up vote 2 down vote accepted

Taking the individual points of your question:

Requirement 1 - Load Spreading
You need to figure this one out for your environment -- "reasonable" depends on a lot of factors (how many machines, how much data, what kind of media you're backing up to, how much bandwidth you have available, how much money your boss is willing to allocate for backups, whether or not you have a Ceiling Cat in your datacenter that can be trained to rotate tapes...)

You may also want to look into "synthetic full backups" (Bacula calls them VirtualFull backups) - these can produce a "full" backup without having to pull data off the client by consolidating the data you backed up in your most recent full plus all the incremental/differential changes.

Requirement 2 - Full and Incremental in alternate pools
You appear to have not discovered the FullPool, IncrementalPool and DifferentialPool configuration directives. Consult the Bacula manual for more info on these.
They're what you need in order to split backups into different pools by job type.

Requirement 3 - Scalability
First, if you're using Bacula and doing anything of even moderate complexity give up on a small config file right now. The director configuration is going to be big.

What you're doing with JobDef and Schedule directives is the Right Way to handle things, Add definitions as needed to meet your requirements.

If I were you I would not use the backup dates as the naming convention - Call your schedules (and Job defaults) "Group A", "Group B", etc. (or something equally generic).
Document which backup group each server is in, that way you can easily re-balance your backup load my moving a server from one group to another.
You can do this with your date-based names of course, but I find it easier to think of backup groups as an abstract concept. Plus if Group A is bleeding into Group B's backup time frame I can always move all of Group B forward a day by changing the schedule definition, and I don't have to change its name.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.