On Friday 26 August 2005 15:07, David Boyes wrote:
> > > nope .. i want the RECENT backup on tape it's just that i also want
> > > the last 2 backups on HD for quicker restore, in case the
> >
> > tape fails
> >
> > > etc.
> >
> > Now, that doesn't much change what I wrote about bacula not
> > allowing this. But I think your ideas could perhaps
> > contribute to the migration discussion...
> >
> > Basically, what would be needed for something like this is a
> > job copy function and modifying the retention periods for the
> > resulting jobs, I think.
>
> Actually, this is closer to the "volume set" idea I alluded to -- being
> able to define a single volume name representing a "set" of volumes where
> any member of the set would be acceptable to satisfy a mount request for
> backup or restore. It's only moderately related to the migration issue in
> that migration makes the idea of multiple synchronized copies of the data
> much more useful (eg, be able to send the 2nd and subsequent copies to
> different offsites, etc).
I believe I understand your "volume set" idea, but how is this really
different from a pool? Couldn't a current Bacula pool be roughly equivalent
to a Volume Set under your definition?
>
> Once we get migration working, this would be my next big priority issue. I
> think the cleanest way to do this would be to implment some kind of SD
> multiplexor daemon (the real FDs connect to the multiplexor, which
> replicates the incoming data streams to 1...n output devices as if it were
> a FD to each individual SD that is actually managing a device). The SD mux
> would manage the volume sets, ensuring that the sets are synced on backup,
> and selecting an available volume for restore.
>
> Tricky part here is indicating preference for which volumes to use for
> restore if multiple technologies are available. The way the large systems
> world does this is to define the concept of a "management class", which
> encapsulates pool hierarchies, and general policy about data management
> behaviors. We'd have to change the job manager to select a management class
> instead of indicating specific SDs, pools, etc. Might not be a bad thing in
> the long run, but probably seriously traumatic to Bacula in the short term.
>
Yes I would like to divorce a Job from a Storage device, which I have
partially done in 1.37 in that you can specify multiple storage devices and
the SD selects which one to use. A management class might be able to
encapsulate this though.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
