On Friday 27 March 2009 11:42:18 James Harper wrote: > > 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? > > Did I send you my patch? I've been using that for a few days and it > works perfectly for me, but having thought about it a bit more I can see > that it might not work for others.
Yes, I did see it, and I am concerned about it not being a general solution or the consequences it could have for others. > > My reason for using VirtualFull is so that I can do a Full backup to > disk once a week (or less often) and just do incremental in between. The > advantage of incremental is that they can be run pretty fast and with > much less load compared to full backups, so I can do them a few times a > day. I can then do a virtual full backup to tape, and the tapes become a > disaster recovery solution (maybe also to restore files which have > expired from disk, depending on the retention time of each medium), but > are not generally used to do restores. Yes, this is what Virtual Full is *supposed* to do, and as I said, I think the solution is to have the Virtual Full write into the same Pool as the read Pool, and I believe that this can be done, you just have to point the Next Pool to the same place as your input. This should work, but it is not very logical to requre Next Pool and have it point back to your input, so the main point I was trying to make in my prior email is that I am thinking about changing that -- in the mean time, I think you just need to make sure you are not doing a Virtual Full to tape. > > This is what we do at a few clients with Backup Exec. > > So when I do a restore, I don't want to have to muck around with tapes > which are (hopefully) not on site, I only ever want to use the disk > backups which are always on site. Because I am using virtualfull to > create a tape backup to take off site, I really do want the media to be > in another pool, so the current situation (+ my patch) works perfectly > for me. Yes, well a Virtual Full was not really intented to write a tape for offsite use. If you want to do that, run a Virtual Full, then run a Copy of the Virtual Full and take the Copy offsite. As I have said, I am not happy with the current way Virtual Full works (though I think one can work around it currently), but I am less happy with changing it to do what you have previously suggested. My proposal will resolve the problems I see -- but I need to think it over and ensure all ideas have been discussed before chaning the code ... > > That is different to using virtualfull to 'update' your full backup > based on subsequent incrementals, which I now understand was the > original requirement (I think?) Yes, exactly. > > I think you could get the best of both worlds by introducing the ability > to specify a set of source pools for doing virtualfull backups, and the > destination pool. Eg: > "run job=xxx level=virtualfull pool=tape > sourcepools="disk_incremental,disk_full". This is interesting. Can you be a bit more precise. Is Pool=Tape the output Pool? and why do you want multiple input pools? > The NextPool would go away. Yes, at least in the case of Virtual Full, I think it needs to go away. The original concept was to avoid a deadlock with the read and write Volumes being the same. > Maybe also an option to purge the source jobs automatically too for > where you are consolidating jobs. Uh, I don't quite understand the above sentence ... > > Just some ideas... > I am looking for ideas eventhough it is a bit late :-) ------------------------------------------------------------------------------ _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
