[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


Hi,

15.12.2008 21:52, Kern Sibbald wrote:
...
> 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 ...).

I'd like to see those used, but you probably guessed that :-)

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

Agreed.

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

Agreed.

> 3. The restore command should allow the user to select any Copy job or jobs.

Definitely.

> I am proposing to change the current way that Copy jobs are handled.  Below is 
> partial output from a list of Jobs run (a Copy regression test):
> 
> +-------+--------------+---------------------+------+-------+----------+-----------+-----------+
> | 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 | B    | F     | 7020     | 
> | 2     | CopyJobSave  | 2008-12-15 20:38:32 | B    | I      | 999     | 
> | 6     | CopyJobSave  | 2008-12-15 20:38:32 | B    | 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     | 
> +-------+--------------+---------------------+------+-------+----------+-----------+-----------+
> 
> JobIds 1 and 2 are original full backups. 
> JobIds 5 and 6 are copies of the original JobIds 1 and 2 respectively.
> JobIds 3 and 4 are the jobs that ran the Copy jobs.
> 
> Notice that JobIds 5 and 6 look identical to their original jobs 1 and 2 
> despite the fact that they were actually run at the time of job 3 and 4.
> 
> 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     | 
> +-------+--------------+---------------------+------+-------+----------+-----------+-----------+

Difference spotted immediately :-)

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

Go that way... the changes don't count here, IMO, as the code is not 
released for exactly that reason.

> A restore might go like the following:
> 
> It might go something like this:
> 
> restore 
> (chose option 5 -- current for full restore)
> 
> The following JobIds are selected for restore:
> 
>  1, 2
> 
> These JobIds have copies as follows:
> 
> JobId      Copy JobId    Media Type    Date   Location ....
> ====================================
> 1            5                 Disk   ...
> 2            6                 Disk
> 
> 
> To use a copy, select JobId, Copy JobId

Make this "... select pairs of JobId, Copy JobId [Job Id, Copy JobId] 
..." to make it more clear that the user can select several pairs, and 
that the pairs are separated by white space only, no commas.

> 2,6
> 
> The following JobIds have been selected for restore:
> 1,6
> 
> 
> ===
> 
> A more complicated example might be:
> 
> restore 
> (chose option 5 -- current for full restore)
> 
> The following JobIds are selected for restore:
> 
> 1, 2, 3, 4
> 
> These JobIds have copies as follows:
> 
> JobId      Copy JobId    Media Type    Date   Location ....
> ====================================
> 1            5                 Tape   ...
>               7                 Disk  (second copy of job 1)
> 2            6                 Disk
> 3            8                 Tape
> 4            None
> 
> 
> To use a copy, select JobId, Copy JobId

See my above comment - here it's obvious, in my opinion, that better 
user guidance is required.

> 1,7 2,6
> 
> The following JobIds have been selected for restore:
> 7,6,3,4
> 
> 
> 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. 

I prefer that.

> Any comments?

Implement both?

Arno

> Best regards,
> 
> Kern
> 
> ------------------------------------------------------------------------------
> 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@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel
> 

-- 
Arno Lehmann
IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück
www.its-lehmann.de

------------------------------------------------------------------------------
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@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.