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

Re: [Bacula-devel] Virtual Full time/date bug?


On Monday 13 October 2008 18:50:53 Graham Keeling wrote:
> On Mon, Oct 13, 2008 at 06:34:16PM +0200, Kern Sibbald wrote:
> > On Monday 13 October 2008 16:56:34 Graham Keeling wrote:
> > > First:
> > > a) Set the time forward a year, to be 2009.
> > > b) Run a Full backup.
> > > c) Run an Incremental backup.
> > > d) Set the time to be the real time again.
> > > e) Try to run an Incremental backup.
> > >
> > > The last incremental backup fails. The log says:
> > > ... JobId 4: Fatal error: Cannot find previous jobids.
> > >
> > > OK, that is fair enough.
> > > But since there were no previous jobs, I would have expected it to be
> > > promoted up to a Full backup.
> > >
> > > This promotion happens when you run an
> > > Incremental without having any other jobs at all, so I don't really
> > > understand why it doesn't in this case.
> >
> > This is a Virtual Full Job.  That means that it never contacts the
> > client, and if it were promoted to a Full, it would contact the client. 
> > I think the current behavior is correct, though I will change the Error
> > message to say:
> >
> > "No previous Jobs found."
>
> Sorry, but this isn't a Virtual Full that I'm running. It is an
> Incremental.

After looking at this, I think it is just a manifestation of the fact that 
your database is screwed up.  Depending on exactly what SQL is used by Bacula 
in the numerous different calls it must do, Bacula can get different 
non-sense results.  For example one call can ask for the most recent Full 
then look for a Incrementals and if the dates are not logical, then Bacula is 
going to get confused. 

If you can show that something bad happens when the dates are correct, then 
I'll take a look at it, otherwise, I am not convinced it is worth the 
effort -- what it does now is to fail, which is what it probably should do. 
If we "correct it" to do what you request, the results probably would not be 
any more satisfactory -- particularly because at some point things are going 
to blow up. If we took the huge performance hit to run insanity checks on the 
data, it would fail anyway.

Best regards,

Kern

>
> > > Secondly:
> > > Continuing from the first five steps as set out above...
> > > f) Run another Full backup.
> > > g) Run another Incremental backup.
> > > h) Run a Virtual Full backup.
> > >
> > > This seems to work fine, but when I do a 'list jobs' and check the
> > > dates, the Virtual Full has now got the start time of the Incremental
> > > that was created in step (c) above.
> > > 'list jobs' looks like this (tidied up a bit for ease of reading):
> > >
> > > +-------+-------+---------------------+-------+----------+----------+
> > >
> > > | JobId | Name  | StartTime           | Level | JobFiles | JobBytes |
> > >
> > > +-------+-------+---------------------+-------+----------+----------+
> > >
> > > | 3     | tserv | 2008-10-13 15:30:31 | F     |      533 |  774,718 |
> > > | 4     | tserv | 2008-10-13 15:31:08 | I     |        7 |  304,512 |
> > > | 1     | tserv | 2009-10-13 15:29:19 | F     |      532 |  751,430 |
> > > | 2     | tserv | 2009-10-13 15:30:12 | I     |       11 |  308,112 |
> > > | 5     | tserv | 2009-10-13 15:30:12 | F     |      533 |  868,913 |
> > >
> > > +-------+-------+---------------------+-------+----------+----------+
> >
> > If you mess up your Start Time, then when Bacula looks at the records, it
> > is going to assume that the database is correct and get "incorrect"
> > results. Given the time stamps above, I would say that it did the right
> > thing; it set the Virtual Full to the time of the last Incremental
> > backup.
>
> ...
>
> > > I put some debug in in order to dump the .bsr file from the Virtual
> > > Full, so I can confirm that it did use the 2008 jobs. So the problem
> > > appears to be that it is just setting the date wrong.
>
> I think it did the wrong thing, as it consolidated the 2008 backups, and
> set the time to the last 2009 backup.
> The right thing would have been either:
>
> a) consolidate the 2008 backups, and set the time to the last 2008 backup,
> or b) consolidate the 2009 backups, and set the time to the last 2009
> backup.
>
> Actually, I don't really understand why it is changing the time on the
> Virtual Full at all. Is there a reason why it can't just keep the real time
> that the Virtual Full started?
>
> Thanks,
> Graham.
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel



-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-devel mailing list
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilotco.