[Bacula-users] Multiple Clients Using Disk Example
In the Bacula manual there is a wonderful example of how to set up pools for backups to disk using the default three level schedule. However, the example configuration file only uses one client. I was wondering if the same configuration works for multiple clients, or if there is something else to consider. For example, the sample file has one job per volume for each of 6 volumes in the differential pool, one for each week in a month (with some slack). If I were to try to run 10 clients on this would it fill that pool on the first week after 6 had backed up? What would happen to the other four, would baucla die horribly, or overwrite the volumes it just created, or create more volumes? Similarly, I seem to need a new client entry and a new job entry for every machine I want to back up. Many of the machines to be backed up will change every 4 months or so, and they all will have the same configuration, so is there any way to condense the amount of configuration that needs to change? i know about JobDefs, but is there any BatchJob, say, or a similar ClientDefs? Thanks, Kyle Marsh - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Multiple Clients Using Disk Example
Thanks,
On 6/8/07, Arno Lehmann [EMAIL PROTECTED] wrote:
Hi,
For example, the sample file has
one job per volume for each of 6 volumes in the differential pool, one
for each week in a month (with some slack). If I were to try to run
10 clients on this would it fill that pool on the first week after 6
had backed up? What would happen to the other four; would baucla die
horribly, or overwrite the volumes it just created, or create more
volumes?
When I deploy a disk-based backup scenario, I usually don't bother with
volumes for a certain weekday, or anything like this. Rather, I estimate
the amount of space needed (per pool, obviously), and set up the pool to
take that amount of data (using limits on the volume size, volume
number, plus enabling automatic labeling).
Bacula will create, fill and recycle volumes as necessary and as set up.
It usually doesn't die horribly, and it overwrites volumes only once
they are out of their retention time. The worst that can (and does,
sooner or later) hapen is that Bacula asks for a new volme, which simply
shows that my estimate wasn't good enough or that the data grew faster
than could be expected. Then it's either time to create more volumes (as
available space permits) or to shorten the retention times (as policy
permits).
So if I understand you, what you do is create an pool for each level
of backup and estimate how much space that will take, then pick a
reasonable maximum size for each volume and divide the estimated pool
size by that to get the number of volumes, rather than put each backup
it its own volume like the example does. That seems good.
For reference, what have you found to be reasonable sizes for disk
volumes? If, as I suspect, the optimal size depends on the overall
size of each job, could you give some examples or a rule of thumb?
Many of the machines to be backed up
will change every 4 months or so, and they all will have the same
configuration, so is there any way to condense the amount of
configuration that needs to change? i know about JobDefs, but is
there any BatchJob, say, or a similar ClientDefs?
No, unfortunately not. But you can rather easily create a template which
is semi-automatically populated with the individual information. An
example I invented recently could look like this:
Put this into an executable text file:
#!/bin/bash
SED=/usr/bin/sed
SUBST=-e s/TEMPLATE/$1/g -e s/PASS/$2/g
catEOF | $SED $SUBST -
Client{
Name=TEMPLATE-fd
Password=PASS
# all the usual stuff that never changes
}
I called this unix-templ and execute:
[EMAIL PROTECTED]:~/some-config ./unix-templ test pass
Client{
Name=test-fd
Password=pass
# all the usual stuff that never changes
}
which you could paste into your configuration or redirect into an
included file.
Similar scripts for other configuration sections are equally simple...
Indeed...I think I will write a script that takes the client data and
appends it in the necessary formats to files that are then included
where needed. That seems like the best idea in this case. I'll have
to look up includes -- I have yet to run across them in the manual.
Also, I'm not sure if it helps here, but is there any sort of variable
system in the bacula configuration? I think not, but it may turn out
useful if there is.
Also, IIRC the upcoming version 2.2 (now in beta testing) allows to use
script output as the configuration file, so you could use a main script
that dynamically generates all the necessary information, taking it, for
example, from a database. Adding a client could be done using a simple
front-end to your database, and then reloading the DIR.
What do you mean here by using script output as the conf file? How is
this different from what I plan on doing above except with a database,
which I could implement if I felt so inclned? Do you mean that 2.2
will ship with a script which generates the configuration files rather
than requiring them to be written out by hand?
Thanks for the help,
~Kyle
Arno
Thanks,
Kyle Marsh
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
[Bacula-users] Multiple Clients Using Disk Example
For some reason this didn't post the first time, so here it is again. In the Bacula manual there is a wonderful example of how to set up pools for backups to disk using the default three level schedule. However, the example configuration file only uses one client. I was wondering if the same configuration works for multiple clients, or if there is something else to consider. For example, the sample file has one job per volume for each of 6 volumes in the differential pool, one for each week in a month (with some slack). If I were to try to run 10 clients on this would it fill that pool on the first week after 6 had backed up? What would happen to the other four; would baucla die horribly, or overwrite the volumes it just created, or create more volumes? Similarly, I seem to need a new client entry and a new job entry for every machine I want to back up. Many of the machines to be backed up will change every 4 months or so, and they all will have the same configuration, so is there any way to condense the amount of configuration that needs to change? i know about JobDefs, but is there any BatchJob, say, or a similar ClientDefs? Thanks, Kyle Marsh - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
Re: [Bacula-users] Multiple Clients Using Disk Example
Hi,
On 6/8/2007 7:27 PM, Kyle Marsh wrote:
For some reason this didn't post the first time, so here it is again.
ah, here we go :-)
In the Bacula manual there is a wonderful example of how to set up
pools for backups to disk using the default three level schedule.
However, the example configuration file only uses one client. I was
wondering if the same configuration works for multiple clients, or if
there is something else to consider.
It's too late and too warm here for me to go over the example now :-)
but I will resent a more abstract solution...
For example, the sample file has
one job per volume for each of 6 volumes in the differential pool, one
for each week in a month (with some slack). If I were to try to run
10 clients on this would it fill that pool on the first week after 6
had backed up? What would happen to the other four; would baucla die
horribly, or overwrite the volumes it just created, or create more
volumes?
When I deploy a disk-based backup scenario, I usually don't bother with
volumes for a certain weekday, or anything like this. Rather, I estimate
the amount of space needed (per pool, obviously), and set up the pool to
take that amount of data (using limits on the volume size, volume
number, plus enabling automatic labeling).
Bacula will create, fill and recycle volumes as necessary and as set up.
It usually doesn't die horribly, and it overwrites volumes only once
they are out of their retention time. The worst that can (and does,
sooner or later) hapen is that Bacula asks for a new volme, which simply
shows that my estimate wasn't good enough or that the data grew faster
than could be expected. Then it's either time to create more volumes (as
available space permits) or to shorten the retention times (as policy
permits).
Similarly, I seem to need a new client entry and a new job entry for
every machine I want to back up.
Yes.
Many of the machines to be backed up
will change every 4 months or so, and they all will have the same
configuration, so is there any way to condense the amount of
configuration that needs to change? i know about JobDefs, but is
there any BatchJob, say, or a similar ClientDefs?
No, unfortunately not. But you can rather easily create a template which
is semi-automatically populated with the individual information. An
example I invented recently could look like this:
Put this into an executable text file:
#!/bin/bash
SED=/usr/bin/sed
SUBST=-e s/TEMPLATE/$1/g -e s/PASS/$2/g
catEOF | $SED $SUBST -
Client{
Name=TEMPLATE-fd
Password=PASS
# all the usual stuff that never changes
}
I called this unix-templ and execute:
[EMAIL PROTECTED]:~/some-config ./unix-templ test pass
Client{
Name=test-fd
Password=pass
# all the usual stuff that never changes
}
which you could paste into your configuration or redirect into an
included file.
Similar scripts for other configuration sections are equally simple...
Also, IIRC the upcoming version 2.2 (now in beta testing) allows to use
script output as the configuration file, so you could use a main script
that dynamically generates all the necessary information, taking if, for
example, from a database. Adding a client could be done using a simple
front-end to your database, and then reloading the DIR.
Arno
Thanks,
Kyle Marsh
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
--
IT-Service Lehmann[EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
