As said before, the Run= directive in the Job resource ought to be
used to create two more-or-less identical Jobs targeting different
media.
It is said in the documentation that the Since= parameter (which
does the steering of differential/incremental backups) can be passed
on from the originating job to the cloned job. So this makes that
both jobs use the *SAME* Since-value. But is this the *CORRECT*
Since-value???
At first I did not even think about this matter. After I found out
that a job that creates a clone cannot be migrated later on (see my
other msg) I experimented with a third job. The idea is easy: if
a job that saves valuable data must not contain a Run= directive,
then just create a job that does not save valuable data and does
only contain the necessary Run= directives?
Like this one:
Job {
Name = CallTheOthers
Fileset = EmptySet
Pool = VolatilePool
Run = "BackupJob Pool=SysBack"
Run = "BackupJob Pool=MirrBack"
}
Well, this does work.
Later I found out that I could do just the same with the Schedule
resource. Actually the only difference between the Run= directive
and an appropriately crafted Schedule ressource is the ability to
pass over the Since value.
So I came to think about the Since value. Which Since value would
be the correct one?
If we want mirroring, then we must guarantee that all data is
saved redundant, to both instances. We may have overlaps but we
must not have gaps.
Now from the documentation, bacula produces the Since value by
querying the database for the start time of the last sucessfully
completed job of appropriate level. (This is only partly true -
otherwise some things that I am currently trying to do would work,
but they do not. More on this later.)
But this makes so much clear, that if we run two identical ("cloned")
jobs, the Since value will most likely derive from the job that did
start LATER. Which is the wrong one for the matter of mirroring,
because then the time between the start of the earlier and the start
of the later job is covered by only one instance.
In this case we would have to guarantee that both jobs start at
the same time. But: the idea of mirroring is that we write to
*different* tapes, and to make sure that we have different
tapes they must be in different Pools. Different Pools are different
ressources which are individually allocated, so there is just no
way to guarantee they are always available at the same time!
Which leads us to the bottomline, unless we should find out something
different, that what we get at best are *mostly redundant* backups.
And, to say it frankly, "mostly redundant" is *not* redundant.
We could now experiment with running both jobs on different
Priorities so to guarantee a defined execution sequence, and to
use two identical filesets with different names so to make sure
which Since value gets selected, and possibly we would come to a
solution that can be logically verified.
But at that point it is far cheaper to run the whole backup just
twice, totally independent on each other.
Now this all is true for ordinary filespace backups, and actually
there isn't so big a trouble with ordinary filespace data. Even if
you have a faulty tape, if you have backed up often enough you may
get away with a small couple of lost files, as most of the backups
is redundant anyway.
There is at least one case where it is *not* easy. That is redo logs
of a database: if you loose one piece of a log, you have lost the
whole database from that point on.
So you want to save these logs twice. And you cannot save them
independently, because you have to delete them after they are saved.
Further ideas welcome. There are good solutions for the special case
of redo logs (because they usually are a plain sequence), but I was
looking for a general one-fits-all mirroring solution and found that
it is not a just-switch-on matter.
rgds,
PMc
--
..having tossedaway Microsoft(tm) already in 1991!
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
