On Tue, 21 Aug 2007, Nick Pope wrote: > > 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?
It depends... Think of a case where you've got equipment in a datacenter. It's unattended, so your tape backups are back at the office which may have a fairly slow link. It would be very, very handy to have the data sent both to a box with a bunch of big disks in the datacenter (for quick recovery) as well as to a tape drive at the office (more of an offsite emergency use only sort of thing). Charles > 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 > ------------------------------------------------------------------------- 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
