On Aug 21, 2007, at 8:25 PM, Charles Sprickman wrote: > 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
OK, so you would back up to disk in the data center as usual. Then, when the disk backup is done, you can spawn a copymigrate job to copy the data down to the tape drives over the slow link. This is a perfect example where the migrate-without-purge job copying is "good enough" and full-blown parallel backups to multiple pools would not be needed (unless I'm missing something). I guess the point I'm making is that I'd vote for a simpler version of the job copying feature that would work in a serial fashion using a very slightly modified migrate job if we could get it much sooner than the parallel muxing SD that could send jobs to multiple places at once. Now this is all premised on a huge assumption: that a basic migrate/ copy-without-purge would be MUCH simpler/quicker to implement than a muxing SD that could copy to multiple pools at once. This may not be the case. -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
