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.
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).
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...
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.
(TBH I'm using hard disk storage so I don't know if this will fly with -
manual? - tape changers)
Regards,
Berend Dekens
David Boyes wrote:
>
>> Item 8: Implement Copy pools
>> Date: 27 November 2005
>> Origin: David Boyes (dboyes at sinenomine dot net)
>> Status:
>>
>> What: I would like Bacula to have the capability to write copies
>> of backed-up data on multiple physical volumes selected
>> from different pools without transferring the data
>> multiple times, and to accept any of the copy volumes
>> as valid for restore.
>> [snip]
>>
>> Notes: I get the idea, but would like more details on the precise
>> syntax of the necessary directives and what they would do.
>
> I think there's two areas where new configuration would be needed.
>
> 1) identify a "SD mux" SD (specify it in the config just like a normal
> SD. The SD configuration would need something like a "Daemon Type =
> Normal/Mux" keyword to identify it as a multiplexor. (The director code
> would need modification to add the ability to do the multiple session
> setup, but the impact of the change would be new code that was invoked
> only when a SDmux is needed).
>
> 2) Additional keywords in the Pool definition to identify the need to
> create copies. Each pool would acquire a Copypool= attribute (may be
> repeated to generate more than one copy. 3 is about the practical limit,
> but no point in hardcoding that).
>
> Example:
> Pool {
> Name = Primary
> Pool Type = Backup
> Copypool = Copy1
> Copypool = OffsiteCopy2
> }
>
> where Copy1 and OffsiteCopy2 are valid pools.
>
> In terms of function (shorthand):
>
> Backup job X is defined normally, specifying pool Primary as the pool to
> use. Job gets scheduled, and Bacula starts scheduling resources.
> Scheduler looks at pool definition for Primary, sees that there are a
> non-zero number of copypool keywords. The director then connects to an
> available SDmux, passes it the pool ids for Primary, Copy1, and
> OffsiteCopy2 and waits. SDmux then goes out and reserves devices and
> volumes in the normal SDs that serve Primary, Copy1 and OffsiteCopy2.
> When all are ready, the SDmux signals ready back to the director, and
> the FD is given the address of the SDmux as the SD to communicate with.
> Backup proceeds normally, with the SDmux duplicating blocks to each
> connected normal SD, and returning ready when all defined copies have
> been written. At EOJ, FD shuts down connection with SDmux, which closes
> down the normal SD connections and goes back to an idle state.
> SDmux does not update database; normal SDs do (noting that file is
> present on each volume it has been written to).
>
> On restore, director looks for the volume containing the file in pool
> Primary first, then Copy1, then OffsiteCopy2. If the volume holding the
> file in pool Primary is missing or busy (being written in another job,
> etc), or one of the volumes from the copypool list that have the file in
> question is already mounted and ready for some reason, use it to do the
> restore, else mount one of the copypool volumes and proceed.
>
>
> -------------------------------------------------------------------------
> 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-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
-------------------------------------------------------------------------
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
