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 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 ...
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
-------------------------------------------------------
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
