> > > The related > > > problem is how Bacula handles multiple locations where the file can be > > > found, and how Bacula prioritizes restores. I have some interesting > > > ideas on that when/if Kern gets time to think about the design for > > > this > > > stuff. > > > > That certainly seems like the main challenge to the copy job. > > Yes, I don't really know how to handle this in the best way at the moment, > but > implementing the simple change to Migration to do a Copy certainly is the > first step.
My thoughts on this would be to make the SD-MUX a a totally separate daemon with perhaps it's own DB. And the mux logic be left completely out of the Director. In the director you would create a pool and sd defininitons specific for the SD-MUX. You may have a volume mux-001. The director would connect to SD-MUX and request volume mux-001, and the SD-MUX would quietly translate this to mean both file-001 and tape-001 and would write to both. On recovery, it would pull the data from whichever volume is avaiable, if both are available, one with a higher priority set in the config might be selected. just a theory, maybe it can spark a good practical idea. -- Kenny Dail <[EMAIL PROTECTED]> ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
