Hello,
On 5/5/2006 3:49 PM, Bill Moran wrote:
On Fri, 5 May 2006 14:47:12 +0200
Kern Sibbald <[EMAIL PROTECTED]> wrote:
Hello,
Thanks for your thoughts.
When I was first researching the kind of basic organization I wanted for
Bacula, I took a look at Amanda, read a bit on their email list, and talked
to a user who had used Amanda, which basically from what I understand works
much like that. That is Amanda figures out what has to be done then does it.
Well, the person I talked to about Amanda and a number of other users
complained the most about precisely that feature. Now, it doesn't mean that
it is a bad feature, but it means that the issue is rather complicated to
implement in a way that will please everyone (I certainly didn't know how to
do it). As a result, I decided to do it the "traditional way".
That's interesting to know. It pretty much validates my concerns, I
suppose.
That said, I have often thought of adding directives to guarantee that certain
levels are performed at specified intervals (i.e. Differental at least once a
week, ...). In the future, I could see adding some additional resources such
as your Policy idea (cool) that along with some basic scheduling information,
might decide more appropriately or rather dynamically what level to run when.
Most adminstrators will still want considerable control over exactly when
certain backups run to avoid interferring with users or to reduce network
congestion ...
Theoretically, there could be additional configuration to moderate
usage. Such as directives to limit bandwidth usage to different amounts
at different times of day. Or a directive to indicate that a specific
system is only available for backup at certain periods. To really do
it correctly would probably be _very_ complex.
I was thinking that an interesting interim step might be a front-end
program that allows you to enter the business logic (servers, data
importance, etc) and then generates a configuration from that input
that would work with the current Bacula. I'm frightened of the SWAT
problem (i.e. the SWAT config tool for Samba is really nice, but
once you've used it you can never manually edit the smb.conf file
again!) So the tool would have to store extra config data in "magic"
comments (or something) so the admin would still have the ability
to manually adjust the config. I only wish I had time to work on
this.
I mentioned something similar to that a few days ago on bacula-devel,
IIRC. The idea is to allow more extensive job control from python
events. Then, for example, do the following:
Set up a full backup job to run every few hours. At job setup a python
event is triggered. The python script then decides how to modify that job:
Set the backup level according to a policy, and after consulting the
catalog which jobs still exist on tape,
set the storage device and pool according to the backup level and
archiving needs,
or even fail the job, silently, i.e. without causing notification
messages or "Job cancelled" catalog entries.
Given such a python event script job setup could be much easier, too,
because you could store the relevant configuration in a database, for
example, and invent a user-friendly interface for it.
If python fails or is not available in case of a desaster you wouldn't
loose much, only disk or tape space :-)
All relevant information for restores would be in the catalog as usual, too.
Arno
On Friday 05 May 2006 14:32, Bill Moran wrote:
My reason for writing this is to share my thoughts with the Bacula
community before I move on to another project and forget all this.
The other day, I was documenting the backup procedure here, and how
it fit in with our DRP and business policy. As I was trying to
document our Bacula config and explain how it reflected our business
policy, I got to wondering, "Why do all backup softwares work this
way? Isn't the job of sofware to translate human stuff into computer
stuff for us?"
For example, imagine the following fictional software config for a
(yet non-existent) backup software:
Policy {
Name = "CriticalData"
Acceptable Loss = 4 hours
Archive = 6 months
}
Policy {
Name = "ConfigData"
Acceptable Loss = 1 day
Archive = 3 months
}
Client {
Name = FileServer
Default Policy = None
Policy {
Name = "CriticalData"
Dir = /home
}
Policy {
Name = "ConfigData"
Dir = /etc
}
}
Now, the backup software would automagically generate a schedule that
ensured that data on /home was backed up at least every 4 hours, and
that it was retained for at least 6 months, while ensuring that data
in /etc was backed up daily, and retained for three months. The rest
of the data on the server is not backed up (in this example).
Granted, there's a lot of detail missing from the example config.
The system would need to be told what its options were as far as
media and pools and the like, but I think it describes what I've been
thinking for the last few days: that the config _could_ be closer to
the business logic in structure than the application logic.
On the flip side, there are disadvantages. This kind of config might
abstract the process too much, and take too much control away from the
administrator. I've always been a big fan of software that is easy to
use, but has an "advanced" option that allows you to control the nitty
gritty details, should you want to. It's possible that creating such
a high level of abstraction as I'm describing would make advanced
control too difficult, or impossible.
Anyway, those are my thoughts. Hopefully I've described it in a way
that others can understand. Hopefully its useful information that
someone will find inspiring or something.
And Bacula kicks ass, just in case anyone was wondering :) This is
not intended to be a complaint about Bacula's config or anything, I'm
very happy with Bacula and how it works. I just thought I'd share my
thoughts.
--
Best regards,
Kern
(">
/\
V_V
--
IT-Service Lehmann [EMAIL PROTECTED]
Arno Lehmann http://www.its-lehmann.de
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
