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
This is the kind of application I have in mind. A quick backup at
night, and then trickle the data over to another SD at a different site
during the day. The "copymigrate" job could be bandwidth-limited so it
doesn't slow down the links too much.
No tapes need be involved if you have enough disk. If I could make this
work I'd use tapes only for archive.
In a pinch you could sneaker-net the off-site on-disk backups back to
where they're needed on tape or a Rev disk.
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
-------------------------------------------------------------------------
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
