On Wednesday 12 September 2007 18:10, Josh Fisher wrote: > 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.
I'm not convinced that volume to volume verify would be very easy to implement. > > 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? About 95% of the code already exists to do this. However, I haven't yet worked out how to handle multiple copies in the catalog, which is what the simple copy will permit, then I can proceed with the write multiple copies. > 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. Oh, it wouldn't even be very hard to have one SD send the data to a second SD. A mux SD may be really nice, but it may not be necessary -- more thought needed here. > > >>> 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. I need to think about this more to respond. For the moment, I'm planning just to mark a Copy job as a copy job, so when doing a restore, which looks for Backup jobs, all Copy jobs will be automatically ignored until we add new code that knows how to deal with them. > > > > ------------------------------------------------------------------------- > 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-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- 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
