On Tuesday 11 September 2007 19:26, 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. > > 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. If we could get away with that, we'd just > duplicate the tapes outside of Bacula and be done with it. 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. > > 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. > > > 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-)
So that it is clear, I like the idea of having a special SD that is a mux SD, or at least specify someplace that the particular Job can be muxed. This resolves one of the major problems that has slowed this down: how to keep normal non-muxed jobs efficient. Adding muxing adds a significant amount of overhead and complicates the code significantly ... ------------------------------------------------------------------------- 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
