On Wed, Apr 01, 2009 at 09:22:13AM +0100, Kern Sibbald wrote:
> On Wednesday 01 April 2009 10:07:33 Graham Keeling wrote:
> > On Tue, Mar 31, 2009 at 07:33:25PM +0100, Kern Sibbald wrote:
> > > On Tuesday 31 March 2009 16:44:13 Graham Keeling wrote:
> > > > Hello,
> > > >
> > > > A few months ago, I made a bug report about two backup jobs writing to
> > > > the same volume at the same time. This would cause corruption of the
> > > > backups. Via email on this list, I suggested that JobMedia records
> > > > should be created for the volumes from the start.
> > > >
> > > > The bug report is here: http://bugs.bacula.org/view.php?id=1188
> > > >
> > > > Kern's "simple fix" was to check whether the Media's LastWritten and
> > > > FirstWritten database values in the is_volume_purged() function. It now
> > > > returns false if one of them isn't set.
> > > >
> > > > I made another bug report, as this wasn't enough to fix the problem.
> > > > Corruption could very easily happen when FirstWritten and LastWritten
> > > > were set, when the volume retentions ran out.
> > > > Here is the bug report: http://bugs.bacula.org/view.php?id=1208
> > > >
> > > > Kern then had another go at fixing the bug. I think that this was by
> > > > creating JobMedia records for the volumes from the start.
> > > >
> > > >
> > > >
> > > > On upgrading a computer to a newer version of bacula today, I found
> > > > that I had old volumes for which is_volume_purged() would always return
> > > > false because LastWritten was not set. There were no JobMedia records
> > > > for these volumes. This means that the volumes never get purged without
> > > > manual intervention.
> > > >
> > > > Since bacula is now creating the JobMedia records for the volumes from
> > > > the start, it seems as if the FirstWritten/LastWritten checks in
> > > > is_volume_purged() are superfluous and are getting in my way.
> > > >
> > > > If the problem is now fixed properly, can these checks be removed?
> > >
> > > You haven't clearly stated why the checks on FirstWritten and LastWritten
> > > are creating problems.  As it is, I see no reason to remove them
> >
> > I have old volumes that contain nearly a gigabyte of data, and have
> > VolStatus=='Full' or VolStatus=='Used', have LastWritten==0, and
> > VolRetention==0, and have no associated JobMedia records.
> >
> > They never get auto-purged, because is_volume_purged() always returns false
> > for volumes with LastWritten==0.
> 
> It seems to me that LastWritten should be non-zero and that the easiest 
> solution is to run an SQL command that sets LastWritten non-zero for those 
> volumes where it should be.
> 
> If you can point out some logic error in the current code (not just a special 
> case where the catalog seems inconsistent), I'll consider changing it, 
> otherwise the best choice is not to change anything.

Having run a few more tests, I understand what is happening a bit better.

Your first change (the FirstWritten and LastWritten checks in
is_volume_purged()) only protects the volume in the case when the volume has
first been created in the database. In other words, whilst the very first job
is writing to the volume.

Your second change (dummy JobMedia entries with FirstIndex==0 and LastIndex==0)
only protects the volume during subsequent jobs.

My incorrect assumption at the start of this thread was that the second change
meant that the first was no longer needed.




Now, there is still a problem that can happen in current code, I have been
affected by it, and it is as follows:

a) A job begins, creates a new volume and starts writing to it.
b) Something interrupts bacula before 1 GB has been written and any JobMedia
records have been created.

Now you have a volume that contains up to 1 GB of data, has VolStatus=='Used',
has LastWritten==0, and a VolRetention the same as any of your 'good' volumes.
This volume never gets automatically purged.



If the dummy JobMedia records that protect subsequent jobs also protected the
initial job, then the LastWritten check wouldn't be needed in
is_volume_purged(), and the problem wouldn't exist.


------------------------------------------------------------------------------
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel

Reply via email to