On Monday 22 June 2009 17:45:41 Jonathan Bayer wrote:
> Kern,
>
> I assume you are the kern who replied to my bug report.

Yes, there is only one Kern associated with Bacula.

>
> I just posted a message to the list, again about the virtual full
> backups.
>
> I reread the notes on the report I had posted, and saw your last
> comment.
>
> > Yes, of course, it is opening the last VirtualFull, which other that
> > where the input comes, the output is identical to a Full as far as
> > Bacula is concerned. That is how it was designed. I will look at the
> > documentation and modify it if this point is not clear.
>
> Given that the VirtualFull backup is designed to consolidate the
> previous Full backup plus the most recent Differential backup and any
> subsequest Incremental backups, why is it set to open the last
> VirtualFull backup?  

Because the output of a VirtualFull is a Full backup.  Bacula does not 
distinguish the resulting data from a normal Full.

> It seems that the VirtualFull is (or should be) on 
> a different device/media type than the regular backups.  

> So unless the 
> system does a full backup between different virtual full backups, a race
> condition can (and does) occur when two virtual full backups are done
> without any intervening full backup.  Bacula opens (or tries to open)
> the last VirtualFull backup for reading, and then opens (or tries to
> open) the same media for writing.

I don't believe that Bacula will open the last VirtualFull for reading and try 
to open the same media for writing.  This could easily have happened in a 
previous version of Bacula (3.0.0 or earlier) but not the current 3.0.1 
version or later.  If you are imagining a hypothetical situation, I doubt it 
will happen in practice.  If it does then it should be reported as a bug.

>
> I am using the virtualfull backup to make offsite backups.  

It was designed to make Full backups by consolidating old backups.  It was not 
designed for making offsite backups any more than any Full is designed for 
offsite backups.  If you want to use it for offsite backups, that is OK, but 
you will need to tweak the Volume parameters so that Bacula will ignore the 
Volume.

> If Bacula 
> wants to open the last virtualfull, and the backup is offsite, then it
> will hang until I get the last backup and put it back on the system.

Yes, the same thing will happen with any Full backup.

Please read the documentation on this feature.  It is not advertised as a 
means of doing offsite backup any more than any Full backup is.

>
> I am curious as to the decision making process which led Bacula to the
> current behaviour.  Assuming that it won't be changed, would it make
> sense to add one more backup type, a VirtualOffsiteFull, which would
> make a virtual backup and not record it as a full backup. This would
> enable users to make backups for offsite use without this race
> condition.

Currently Bacula does not have the best of all offsite handling.  It is 
possible, but requires a bit of work -- i.e. is not totally automatic.  
Probably the best way to make an offsite backup with Bacula as it stands 
today is to run a Copy job since the copy will not be used unless the 
original backup that was copied is pruned.

Another way, is to make any kind of backup to a Volume and then manually mark 
the volume as offsite -- there are various ways of doing that, but I don't 
have the time to go into it just now, and the bacula-users list can fill you 
in on those details.

Regards,

Kern

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users