On Tuesday 24 March 2009 10:52:38 James Harper wrote: > > > It uses the same algorithm as a restore. The way it works now is it > > > takes the most recent Full for the Job. > > > > Does Full == VirtualFull in this context? > > > > I always want my VirtualFull backups to use my 'Disk' pool as a > > source. > > > 'Disk' contains actual Full and Incremental backups. 'Tape' contains > > my > > > VirtualFull backups (because it is the Next Pool in 'Disk'). > > > > I (wrongly, obviously) assumed that because 'Tape' didn't have a next > > pool setting in it, it wouldn't be considered as a source for a > > VirtualFull. > > Kern, > > Do you think that it is valid for a VirtualFull backup to use a prior > VirtualFull backup as a source? > > I think that there is a bug where this is the case, and I don't know > that it's valid anyway. > > I would like to make a change so that when looking for 'source' jobs for > a VirtualFull, only jobs in a Pool that has a Next Pool the same as the > current job pool should be considered. > > So to put it in the context of my previous example: > > 1. Full Backup (Pool = Disk, Next Pool = Tape) > 2. Incremental Backup (Pool = Disk, Next Pool = Tape) > 3. Incremental Backup (Pool = Disk, Next Pool = Tape) > 4. VirtualFull Backup (Pool = Tape - because job pool = Disk and Disk > Next Pool = Tape) > 5. Incremental Backup (Pool = Disk, Next Pool = Tape) > 6. VirtualFull Backup (***) > > For (6), only Jobs with media in the Disk pool are to be considered
I haven't been very happy with Virtual Full because it doesn't easily allow the user to do a Virtual Full and then automatically continue to do backups based on the Virtual Full. This is because the Virtual Full goes into another Pool to avoid trying to read/write the same Volume. Perhaps David Boyes could comment on this problem because he came up with the original idea of requiring a different pool for the Migration (I extended the idea to Virtual Full). In case it is not clear, the problem is identified above when the Virtual Full is complete, the output is written to a different Pool, and hence the next Incremental doesn't see the Virtual Full or gets totally confused about where Volumes are. It seems to me that the proper solution to the problem is for the Virtual Full to be able to write into the same Pool that it is reading from, but it should ensure that the write Volume is different from the read Volume. Unfortunately, it is a bit late in the release to be changing things around. Previously reading and writing from the same Pool wasn't possible, but I believe that with the new volume manager code that I recently implemented, it should work. This was somewhat a roundabout way of answering your question. The more direct answer to your question is: you suggestion has merit. I can see how at least in the current situation you describe, which is already a Bacula abberation, it would improve the outcome. The problem is that I need to think about this a lot more because it would change a rather fundamental way that Bacula currently works, and I am not sure what kinds of surprises it will give us. When I don't fully understand what it will do (current situation) I find it is better to wait. I think that my proposed solution above will resolve your problem by allowing you to keep the Virtual Full in the same Disk Pool, and then would allow you to continue doing Incremental backups -- this was my original idea in implementing Virtual Full -- for the moment, it is just not working correctly. Hopefully my proposal would make your request almost moot. Does that make sense to you? Regards, Kern ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
