Kern Sibbald wrote: > On Wednesday 12 September 2007 05:06, Nick Pope wrote: > >> On Sep 11, 2007, at 1:26 PM, David Boyes wrote: >> >>> Also, there is still a period of time where only one copy of the >>> backed-up data exists; all the easy solutions to this problem don't >>> address that requirement. >>> >> This is the major drawback of the simpler solution (again, doesn't >> invalidate its usefulness in other scenarios) >> > > It may invalidate it for some, but it will be *extremely* useful for a lot of > people and will in fact give us an archiving capability. >
It certainly would be useful. This auditing problem, it seems to me, could be alleviated in a simpler manner. A volume-to-volume Verify job should satisfy auditors that copies are bitwise identical. I believe that would be MUCH simpler to implement than multiplexed SDs. Probably easier than a normal filesystem-to-volume Verify job. If absolutely necessary to simultaneously write multiple copies, then why not just allow a single SD to write each record to multiple devices during the backup job? If those devices need to be in different locations, then one or more devices could be NFS shares or iSCSI devices. Multiplexing SDs sounds like a complicated nightmare. But then, that's just an opinion. > >>> If we could get away with that, we'd just >>> duplicate the tapes outside of Bacula and be done with it. >>> >> If I do that, I can't track the copied volumes with the Bacula >> catalog. One might foresee Bacula at some point enforcing a minimum >> number of duplicate copies, etc. >> >>> 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. > A "MasterMediaId" field in the media record might work. If blank, then the volume is a master volume. Otherwise, it contains the media id of the master volume that this volume is a copy of. Nothing need be stored for the copy except its media record. When the copy is later used, catalog lookups would pull info using for the volume pointed to by the MasterMediaId field. If the master has been purged, then the copy is invalid. There would (in any case) need to be some means to upgrade a copy to master, since the whole point of a copy is in case the master is destroyed or goes missing. ------------------------------------------------------------------------- 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
