On Tuesday 16 December 2008 00:17:40 Marc Schiffbauer wrote:
> * Kern Sibbald schrieb am 15.12.08 um 21:52 Uhr:
> > Hello,
>
> Hi Kern,
>
> > I've been discussing with Eric how we might handle Copy jobs in our
> > development version.
>
> [...]
>
> > 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.
> >
> > 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.
> >
> > 3. The restore command should allow the user to select any Copy job or
> > jobs.
>
> 1..3 ACK!
>
> > I am proposing to change the current way that Copy jobs are handled.
>
> [...]
>
> > 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.
>
> This is just what I thought before reading your proposal to this:
> So ACK!
>
> > 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.
>
> Some thoughts on this:
> * How can you be 100% sure that 5 is a copy of 1?
> On a really fast machine two Origian jobs might be created within the
> same second... not?
Bacula created the job so it knows it is a copy.
>
> * How can the copy-job (c) be associated to the real Copy (C)?
> Especially if there are two or more copies of the original.
Again, Bacula did the work, so it knows.
>
> * Will a Copy of a Copy be possible? How will this be done then?
Currently it is possible and can lead to additional problems. However, with
the proposed change unless we explicitly allow copies of copies they will not
be allowed. I imagine that once we understand all the ramifications we will
permit copies of copies.
>
> * There should always be a "real" association between the Origianl and a
> Copy that will always make it clear which job is a copy of what job.
> This might be done only by connecting the JobIds somehow, right?
Yes, that is already done by Bacula.
>
> * How about adding a new Table that is used to store these
> associations? That way it will be possible in the future to have
> more complex dependencies between jobs like
> * Copies of Copies
> * More than one Copy of an Original
> * VirtualFullBackups (sorry i do not know the current state of
> these) might work this way...
It is not necessary at the current time -- KISS is our golden rule -- it keeps
us out of trouble.
>
> Table "JobAssociations"
> +-------+--------------+---------------------+
>
> | JobId | AssocJobId | AssocTime |
>
> +-------+--------------+---------------------+
>
> | 5 | 1 | 2008-12-15 20:41:05 |
> | 6 | 2 | 2008-12-15 20:41:50 |
>
> +-------+--------------+---------------------+
>
> This will tell us clearly that Job 5 is a Copy of Job 1 and Job 6
> is a Copy of Job 2 given the Facts that Job 5 and 6 are of Type "C".
Bacula created the job so it knows it is a copy already without the table.
>
> This might sound a bit too much for what should be done right know,
> but OTOH it might make future features easier to implement if
> different jobs can have a direct association to each other.
For the moment only Migration Jobs and the Migrated Job and Copy Jobs and the
Copied Job need association and they have it.
>
> > 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.
>
> It just tells that there actually *is* a copy. But how do you
> determine which copy is choosen if you have more than one copy and
> want to know which copy has been made at which time?
Review what I wrote above -- I showed an example. Unless you want a very long
output time, we probably will not show when the copy was made, but that can
probably be done if really necessary. I think the other parameters we will
show such as Location/Cost, Media Type, Storage, (possibly Pool) are more
important.
Best regards,
Kern
>
> [...]
>
> > Any comments?
> >
> > Best regards,
> >
> > Kern
>
> -Marc
------------------------------------------------------------------------------
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
|
