On Tue, 21 Aug 2007, Nick Pope wrote: > > 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).
Not quite... The backups happen overnight, which is fine, but that migrate/copy job would probably creep into business hours and squash the slow office link, or worse, still be running when the next night's backup starts. I'm just thinking pie-in-the sky at this point. I tend to work with places that don't have lots of capital, so we have to kludge lots of stuff. While I'm dreaming, I'd love to have a way to push data off to Amazon S3 storage... > 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. How would this migrate work in the example I cited where I'd be migrating to tape, but my most common restores would be coming out of the disk pool? I wish I'd started earlier in this thread, I'm coming from Amanda and there are a few things there worth stealing: -spooling unlimited backups to disk so that if you have tape problems or just can't get someone to change tapes your backups still run -a "smart" scheduler/planner, although I love the fact that Bacula is not so strict about how you design your tape rotation. "smart" meaning that you don't have to manually deal with missed tape loads, or tell it that if you missed a night not to run two incrementals back-to-back, etc. -an option to run native dumps so you can (easily) get things like snapshot support (dump -L on FreeBSD). -a smarter reporting system that can send you the day's job output in one big email and alert you to what tape needs loading next You'll note of course these are all features that benefit changer-less people. :) thanks, Charles > 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
