Bacula-users

Re: [Bacula-users] [Bacula-devel] Copy jobs in Bacula version 3.0.0

2008-12-16 06:28:36
Subject: Re: [Bacula-users] [Bacula-devel] Copy jobs in Bacula version 3.0.0
From: Ulrich Leodolter <ulrich.leodolter AT obvsg DOT at>
To: bacula-devel AT lists.sourceforge DOT net
Date: Tue, 16 Dec 2008 12:26:08 +0100
Hello,

On Tue, 2008-12-16 at 12:41 +0200, Pasi Kärkkäinen wrote:
> On Mon, Dec 15, 2008 at 09:52:39PM +0100, 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 ...).
> > 

first solution should be simple (seen from the users side)
media selection for restore
 5: Select the most recent backup for a client
should not require job selections.

i thought about sql order by based on PriorJobId,  currently
there is no order in uar_last_full and uar_last_diff.
selection is a bit more complicated for the incr jobs.

const char *uar_last_full =
   "INSERT INTO temp1 SELECT Job.JobId,JobTdate "
   "FROM Client,Job,JobMedia,Media,FileSet WHERE Client.ClientId=%s "
   "AND Job.ClientId=%s "
   "AND Job.StartTime<'%s' "
   "AND Level='F' AND JobStatus='T' AND Type IN ('B','C') "
   "AND JobMedia.JobId=Job.JobId "
   "AND Media.Enabled=1 "
   "AND JobMedia.MediaId=Media.MediaId "
   "AND Job.FileSetId=FileSet.FileSetId "
   "AND FileSet.FileSet='%s' "
   "%s"
   "ORDER BY Job.JobTDate DESC,Job.PriorJobId ASC LIMIT 1";

assumptions:
  JobId's are incremented over time.
  only original backup jobs have PriorJobId=0

> > A few things seem obvious:
> > 
> > 1. Any restore where Bacula automatically selects the jobs to be restored 
> > (e.g. a restore to the current state -- #5 on the restore prompt menu) 
> > should 
> > be done by default using the original backups.
> >
> 
> .. if they're still available. 
> 
> I'm using Bacula to backup to disk, and then after the backup-to-disk job I 
> copy from disk
> volumes to tapes. 
> 
> Backups are stored on disk volumes for X days, and after that disk volumes 
> are recycled/reused.
> Backups are stored on tapes for much longer time before they're recycled.
> 

same way i am using it

one question about that:

what happens to Job.PriorJobId when the original job is recycled and
completely removed from Catalog?


> > 2. If a job has been copied, Bacula should probably display an information 
> > message during the restore that indicates that the JobIds to be used have 
> > Copies.
> >
> 
> Yep.
>  
> > 3. The restore command should allow the user to select any Copy job or jobs.
> > 
> 
> Definitely.
> 
> > 
> > I propose that we modify the Jobs to look like the following:
> > 
> > +-------+--------------+---------------------+------+-------+----------+-----------+-----------+
> > | JobId | Name         | StartTime           | Type | Level | JobFiles | 
> > +-------+--------------+---------------------+------+-------+----------+-----------+-----------+
> > | 1     | CopyJobSave  | 2008-12-15 20:38:28 | B    | F     | 7020     | 
> > | 5     | CopyJobSave  | 2008-12-15 20:38:28 | C    | F     | 7020     | 
> > | 2     | CopyJobSave  | 2008-12-15 20:38:32 | B    | I      | 999     | 
> > | 6     | CopyJobSave  | 2008-12-15 20:38:32 | C    | I      | 999     | 
> > | 3     | copy-job     | 2008-12-15 20:41:05 | c    | F     | 0        | 
> > | 4     | copy-job     | 2008-12-15 20:41:50 | c    | F     | 0        | 
> > | 8     | RestoreFiles | 2008-12-15 20:42:39 | R    | F     | 7020     | 
> > +-------+--------------+---------------------+------+-------+----------+-----------+-----------+
> > 
> > Now here, JobIds 5 and 6 no longer appear to Bacula like they are Backup 
> > jobs, 
> > rather they are marked as Type=C (i.e. a Copy job), and so they will never 
> > be 
> > considered for restoration by default.  I've give the Copy control jobs the 
> > Type 'c' to distinguish them from the real copy -- they exist just to 
> > record 
> > the actual time the copy was made.
> > 
> 
> Looks good.
> 
> > Now by modifying the restore code in Bacula, we should be able to provide 
> > features that allow the user to know that there is a Copy of JobId 1 (i.e. 
> > 5) 
> > and a copy of JobId 2 (i.e. 6) and allow him/her to choose which copy to 
> > use.
> > 
> > In my opinion, this would simplify future handling of Copy jobs allowing a 
> > lot 
> > more flexibility and avoiding confusion.  However, it will cause some minor 
> > changes (nothing serious, I believe) for users already using the new code.
> > 
> 
> That's not a problem.. something we need to deal with.. being beta-testers:)
> 
> > 
> > Note, instead of selecting pairs (original Job, Copy), since all the jobids 
> > are unique, you could simply just type in the desired jobids.  For the 
> > above 
> > example: 7,6,3,4. 
> > 
> > Any comments?
> > 
> 
> Thanks for working with this!
> 

I agree!

Ulrich

> -- Pasi
> 
> ------------------------------------------------------------------------------
> 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
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-devel

-- 
Ulrich Leodolter <ulrich.leodolter AT obvsg DOT at>
OBVSG


------------------------------------------------------------------------------
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
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users