> 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. > If this could be intergrated into one mirroring system (which would > either run in parallel or serially while storing data), it would simply > the configuration and it would remove the tweaking of schedules to make > sure each server has enough time to do its local and remote backup > (especially full backups are a PITA). By making the process synchronous (the SDmux write does not complete until all the normal SD writes complete), your backups are automatically throttled to the speed of the slowest device, but are focused on media integrity. If you want speed, back up to disk pools (use one primary pool with a disk copypool) and then migrate to tape using the migration process that's already in the package. > > On a side note, when I look at the implementation below you have to slow > down the muxing SD to match the 10mbit fiber line thats used for the > offsite backup. Perhaps its possible to offer the option to replay the > backup from primary SD to the secondary... but that would mean the SD > keeps working after the backup blocking new jobs... See above. > Or perhaps a mechanism to trigger the mirroring after the backups on the > primary SD are done? That way backups would procede normally and when > done, the data is spooled to the offsite or secondary storage. Spooling is a special case of writing to disk-based pools. With migration, the existing spooling code (IMHO) should be deprecated in favor of D2D2T migration. If you don't do the copies in parallel, there is a period of time when only one copy of the data exists. Wouldn't pass our auditors, or (IMHO) most commercial auditors these days. Thus the mux. > (TBH I'm using hard disk storage so I don't know if this will fly with - > manual? - tape changers) See above. Back up to disk (with disk copy pool) then migrate to tape. Performance would be limited to how fast your operators can change tapes, but since that's not inline to the backup, your backup time doesn't change. Of course, it is an incentive to get tape mount automation, but that's a no-brainer anyway; tape autoloaders are getting affordable even for the smallest shops these days. ------------------------------------------------------------------------- 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
