On Aug 20, 2007, at 12:48 PM, David Boyes wrote: >> I would like to second this. Right now I have duplicates of >> everything >> to first do a local backup and 7 hours later another backup of the > same >> data (but without the scripts and longer runtime) to an offsite > storage >> to mirror the data. > > In our shop, this wouldn't be sufficient to satisfy the auditors. The > contents of the systems could have changed, and thus the replica is > not > a provably correct copy.
It seems that an interim step that involves less effort is possible. 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. I'm certainly not discounting the need for a muxing SD, but if we got the copy/migrate-without-purge capability much faster, would it meet many people's needs? 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. Just a thought... -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-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
