Re: [Bacula-users] Backing up > 100 servers

[Kevin K. <sub...@kk...>]

You may want to look into using a script instead of a text configuration file.

Bacula-dir.conf supports include files with the syntax

@<filename>

If you instead use

@|<filename>

then bacula-dir will treat <filename> as a shell script, execute it and use the output from stdout in its configuration.

As for your second question, I would suggest a few changes:

- Do not allow recycling of file volumes. Instead, prune them and then delete the pruned files (you have to use an external shell script to do that). Otherwise, file volumes will never get smaller. Let's say that you have a file volume that holds a full backup with 100 GB. If bacula recycles that volume and puts an incremental backup with 2GB on it, the file will still be 100GB in size.

Of course I'm assuming that you only put one job into each file volume. If you allow bacula to put multiple jobs into the same file volume, you run into a similar issue: you can't recycle the volume until all the jobs on it have expired.

- Do not expect to recycle (or delete) volumes the next day. One of bacula's strongest points is its volume management - take advantage of it and let it tell you when to recycle or delete a volume.

There are a number of disk-disk-tape strategies for bacula. I don't have experience with them, but I'm sure Google will give you a lot of information.

> -----Original Message-----
> From: Stan Meier [mailto:sta...@bi...]
> Sent: Saturday, February 27, 2010 5:47 AM
> To: bac...@li...
> Subject: [Bacula-users] Backing up > 100 servers
> 
> Hello world,
> 
> our company is planning to move to Bacula. Preliminary tests are
> looking fine, but we really don't know how to deal with a few things.
> 
> As for hardware, we got a 24TB raid and access to a working tape
> library with several drives.
> 
> 1. Keeping configuration sane: With more than 120 servers, we need to
> find a way to keep the configuration files readable. Our servers all
> follow some naming scheme, for example, we got "appserver01" through
> "appserver08" or "webcache01" through "webcache04". We think we should
> split client configurations for each server group, so the file
> "clientdefs/appserver.conf" would define all appserver0X clients.
> Furthermore, most of those servers will need a default job performed
> (/etc, /root, /opt and so on). While it's easy to reuse a "JobDefs"
> stanza to actually define all those jobs, isn't there any way to
> "group" those servers? Do we really have to define more than 120 jobs,
> one for each server?
> 
> 2. Backup availability: One plan would be to use a large part of the
> 24TB available as a FilePool (or several). Each job would then write
> it's data to that pool. A Copy job could copy the data to tape later
> on - with the advantage that restores of recent data would be quite
> fast since they would still be sitting on disk. Before running the
> backup the next day, we would simply recycle those file volumes. Is
> that a reasonable strategy?
> 
> Any hints on this would be very appreciated.