On Wednesday 12 September 2007 05:06, Nick Pope wrote: > On Sep 11, 2007, at 1:26 PM, David Boyes wrote: > >> Couldn't the migrate capability be altered ever so slightly to allow > >> the "migration" of a job without purging the old job from the > >> catalog? This would allow bitwise identical backup(s) to be created > >> without having to create a forking/muxing SD/FD. > >> > >> This, of course, does not create the identical backups at the same > >> instant in time, but it would solve the off-site backup problem with > >> much less effort. > > > > As I said, that wouldn't be sufficient to satisfy our auditors. > > YMMV. In > > our case (which IMHO isn't unusual in the enterprise space), if we > > can't > > stand up and say under penalty of perjury that the bits on volume A > > are > > the same exact bits on volume B, then it's not good enough and we > > stand > > a good chance of seeing jail time. > > In the case of a migrate-without-purge, the bacula blocks would, > presumably, be copied block for block.
No, Bacula always copies record for record. There is no way to guarantee that the blocking factor on the two Volumes is the same, and various critical items are or can be different (Volume name, JobId, Pool, ...). Kern > So your backed up data would > be identical. The metadata Bacula uses to encapsulate your data > would be recreated for the second job, so that would be different. > So maybe the migrate-without-purge feature won't satisfy your > auditors, but that doesn't make the simpler feature pointless. You > seem to be implying it has to be one or the other (sorry if I'm > misreading you here). I think there's a use for BOTH the simpler > feature (especially if it comes quicker) and the full-blown muxing SD. > > > 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) > > > 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. > > > There are some easier ways to deal with some of the symptoms of the > > problem. I think that if we start solving symptoms rather than the > > problem, we're going to waste a lot of effort, particularly testing > > time, on a partial solution that doesn't get Bacula to enterprise > > grade > > solution space. This is major surgery to Bacula; it's going to take a > > lot of testing resources to get this one right. I'd really rather see > > that testing done to get to the final solution. > > I'm not sure I agree that the migrate-without-purge is treating a > symptom. I think it addresses a major shortcoming (fresh offsite > backups) rather effectively. While it may not solve all enterprise- > grade offsite scenarios, it does address many basic offsite backup > scenarios. I don't really agree that the migrate-without-purge is an > interim solution. I think people will use it even when Bacula gets > the full-blown muxing SD. Not everyone is running Bacula in a large > enterprise. > > >> This would allow me to backup to disk at night as usual. Then once > >> the backups are done and the clients are freed up, the copy/migrate > >> job could run and copy the jobs to tape or an offsite pool. The > >> migrate job would not involve the clients, so it wouldn't have to run > >> in the middle of the night. > > > > Assuming the connection between the SD and the offsite server doesn't > > run over the same network...8-) > > Fair point :) In my case, I just need to have a full offsite tapeset > to take offsite and I don't want to wait 6 months for my fullbackups > to migrate to tape (making my offsite backup 6 months out of date). > i do see your point: the simpler solution won't work for large > enterprises. Fair 'nuff. > > -Nick > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bacula-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
