On Wednesday 26 April 2006 10:35, Arno Lehmann wrote:
> Hi,
>
> On 4/26/2006 6:35 AM, Scott Ruckh wrote:
> > This is what you said Wolfgang Denk
> >
> >>In message <[EMAIL PROTECTED]> you
> >>
> >>wrote:
> >>>I was already using those options in my schedule. It looks like you are
> >>>saying to add the other pool options for each RUN statement. I had not
> >>>tried this. Are you already using this, and is it working?
> >>
> >>Yes, I'm using this. It's working fine for automatically scheduled jobs.
> >>
> >>You still have to be careful if you - for example - manually start an
> >>incremental backup which gets propagated into a full one - then none
> >>of these configuration settings will be consulted, and you must take
> >>care to manually adjust pool, storage etc.
> >>
> >>Best regards,
> >>
> >>Wolfgang Denk
> >
> > Now that I think about it, the Pool is not my problem, but rather the
> > storage. The FULL-Pool was chosen, but it wrote it to the INCREMENTAL
> > Storage Device rather then then the FULL storage device.
> >
> > Am I getting confused? I do not believe your suggestions will resolve my
> > issue.
>
> I think Wolfgang got confused :-)
>
> > I am running a manual FULL right now to get a FULL backup before the
> > Incremental schedule kicks off which I think will fix everything. It
> > would be nice that this would work automatically when a new client is
> > added and the first backup is run.
> >
> > If I am not correct in my thinking, let me know.
>
> I think you're right... a setting like FullStorage, DifferentialStorage
> and IncrementalStorage would be one good solution, but some time ago
> this was discussed and Kern said he didn't see the need for it. As
> nobody else implemented it, it's a feature still missing.
>
> I hope that in the future the python interfce grows to allow all these
> settings.
>
> By the way: I even think that, once you can set all these things via
> python events, the configuration of Bacula can be much simplified
> because you're not foreced to use the flat text configuration files.
> Instead it could be possible to to store almost all configuration
> (except for some job stubs) in a way accessible by python and set the
> jobs up from there. Having all the important settings in a database, for
> example, would allow things like dynamically determining backup levels,
> storage devices to use, file sets and so on. Very interesting IMO. Might
> be a project for someone :-)
>
Yes, this is probably the direction we are headed, but it gives me nightmares
from two standpoints: recovering a broken system (the conf no longer has
everything); enormous complexity possible for resolving support problems.
--
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
