[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


16.12.2008 16:49, Josh Fisher wrote:
> Kern Sibbald wrote:
>> Hello,
>> 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 
>> Pools.
>> 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",


> 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.

> 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 :-)


Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

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.