> 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-) ------------------------------------------------------------------------- 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
