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:stan.meier AT billigmail DOT org]
> Sent: Saturday, February 27, 2010 5:47 AM
> To: bacula-users AT lists.sourceforge DOT net
> 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.
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
