[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] [Bacula-users] Copy jobs in Bacula version 3.0.0
Arno Lehmann wrote:
> 16.12.2008 16:49, Josh Fisher wrote:
>> Kern Sibbald wrote:
>>> I've been discussing with Eric how we might handle Copy jobs in our
>>> development version. Currently, Copy jobs are implemented, and they work
>>> much like Migration jobs (share 99% of the code). The difference is that
>>> Migration jobs purge the original backup job and keep only the Migrated data.
>>> With a Copy Job, the original backup job remains and there is a
>>> second "identical" job that contains the copied data. The only difference
>>> between the original and the Copy job is that they will be in different
>>> Now this poses a few problems for doing restores such as:
>>> 1. It is possible that a simple restore will choose JobIds from both the
>>> original and the Copy Job.
>>> 2. There is no easy mechanism for the user to select whether he/she wants to
>>> restore from the original backup or the Copy (or Copies).
>>> So for the moment, the situation is not really satisfactory (one of the
>>> reasons the code is not yet released).
>>> We have a number of ideas for different ways to solve the above problems, many
>>> have already been discussed on the mailing lists, and we will probably
>>> implement a number of the ideas put forward, either before or after the
>>> release (depending on the time we have and the complexity of the proposal --
>>> e.g. using the Location table and Costs ...).
>>> A few things seem obvious:
>> Maybe, but I am still trying to understand. :) My thought is that a
>> Copy job is just that, a copy of a real Backup job, or in other words, a
>> "backup of a backup",
Hmmm. Bad choice of words, perhaps. It is a redundant copy, identical to
the original except with respect to the volumes used and the pool, yes?
>> as for example an offsite backup. So I am inclined
>> to think that to "restore" from a Copy job is to restore the Backup job,
>> rather than the client machine. In this scenario, nothing at all would
>> change about the client restore job. Instead, a restore from a Copy job
>> would restore the original Backup job. A client would always be restored
>> from an "original" Backup job, though the "original" may actually have
>> been restored from a Copy.
> The idea is to not need to do two restores, but only one.
I failed to explain what I meant by a "restore" of a Copy job. Since the
two are identical except for Catalog entries, it should be possible to
"promote" the Copy job to a Backup job. When the client restore job is
completed, the "promoted" job could be demoted back to a Copy job. So
new functions would be "Promote Copy job to Backup Job" and "Demote
Previously Promoted Copy job". The idea is that the client restore code
would not need to change at all. The user's choice would be whether or
not to promote the Copy job before running the restore job. The idea is
that the client restore code might not need to be changed at all.
>> My reasoning is that a Copy job would never
>> be needed unless the original Backup job was somehow lost,
> Theoretically, I agree, but as we all know things tend to go wrong in
> real life, so Bacula should offer the tools to handle such situations
> where the original job is no longer available. See Pais's and Ulrichs
> example of how they use copy jobs to implement disk-to-disk-to-tape
> backups with different volume retention times for disk and tape.
>> in which case
>> there would be no need to ask the operator which to restore from.
>> Perhaps my reasoning is flawed, though, because I'm not sure I "get it".
> Not flawed as such, but I guess you missed some important things :-)
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you. Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.