On Wednesday 26 October 2005 19:01, David Boyes wrote:
> > > Hmm. I don't think that would pass our auditors. If there's a
> > > significant chance that the copies are not identical (and it sounds
> > > like this approach pretty much guarantees that the copies
> >
> > will not be
> >
> > > identical), I don't think it would be sufficient or useful for this
> > > purpose. It does however make implementation easier, as you said.
> >
> > Well, it may not pass your auditors, I cannot argue with
> > that, but I can say that if it doesn't pass, they would
> > probably be horrified to learn that the copies that they are
> > currently getting are not true instantaneous "snapshots"
> > of the system (except the Win32 VSS backups), and so the
> > minor differences produced by this procedure are probably
> > insignificant compared to the inconsistencies within a single backup.
>
> I think you've answered a slightly different question. Right now, what goes
> on the tape is block-for-block identical to what is reported by the FD
> during the scope of that run, however flawed. If I want do parallel copies
> of those tapes at the same time for redundancy or offsiting, etc, then the
> data that goes on the copies of the primary tape needs to be the same
> blocks as what went on the primary tape for each job.
Making an exact copy of a tape is not always possible, because each tape has a
slightly different length and may also have a different number of bad spots
that are automatically handled by the drive. As a consequence, the end of
every tape, will be different (and hence all of the next tape), unless you
force Bacula to stop writing the tape before the end of the tape.
So, in all cases, I would program for two identical copies being different.
>
> Unless I'm missing something, the description you gave would not produce
> that result -- it's effectively N separate backup runs -- so the tape
> copies wouldn't really be the same data, and thus the backups would not be
> interchangable.
You are correct that the tapes would not be identical, so you could not
"blindly" substitute one tape for another. However, since Bacula writes two
jobs, you could use the set of tape from one job or from the other one. This
has the disadvantage that if one tape in each job is bad, there will be a
problem, while if you really had two identical copies of the same tape, you
could use the second identical tape.
>
> > I need to think about it a lot more before I can answer. The
> > current mechanism that I have defined is a "copy" field in
> > the JobMedia record so that Bacula can write as many copies
> > of a file as it wants, and it can then choose what "copy"
> > should be used for the restore. All the details are not yet
> > worked out.
>
> Sounds like that would be workable.
>
> > I think that once Python scripting has matured a bit, a DR
> > manager as you want
> > and describe will be rather "easy" or perhaps I should say "straight
> > forward". All the hooks you need will be there ...
>
> It does look that way.
By the way, I am really unhappy that Bacula cannot at least to some extent
handle autochangers with two drives with different Media Types. Could you
identify for me what the most important combinations are: i.e. a drive that
reads/writes two media types; a drive that reads two media types but writes
only one; a drive that writes two media types but reads only one; or two
drives in a changer that have different media types, but read/write only one
or the other?
For example, with a trivial amount of work, I could modify Bacula to handle an
autochanger with several Media Types, but each drive would have only one
Media Type that it would read/write. Any of the other combinations would be
more work.
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.
Get Certified Today * Register for a JBoss Training Course
Free Certification Exam for All Training Attendees Through End of 2005
Visit http://www.jboss.com/services/certification for more information
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
