Arno Lehmann wrote: > 13.01.2009 14:27, Bastian Friedrich wrote: >> when manually recycling a (used) volume with >> "update volume=xxx VolStatus=Recycle" >> this volume will be accepted for overwriting. Nonetheless, Jobs that have >> been >> written to that volume will NOT be removed from the catalog. This results in >> invalid data, as the catalog will still contain data about volume content >> that is no longer there. > > I never tried that, but I'll take your word for it... > >> Would you regard that as a bug?
I wouldn't, no. It's an expected consequence of doing things that way. You're manually declaring the volume recyclable but not telling Bacula to drop the data about the jobs stored on it. I could see a possible argument for having Bacula automatically purge jobs stored on a volume when it is manually set to Recycle, but I don't consider that *not* doing so is a bug. In fact, I personally would not vote in favor of such an auto-purge feature, for several reasons. What if you mistakenly change the status of the wrong volume, and backup jobs that you still need are purged before you can correct the mistake? At the same time, I would not agree with removing the ability to manually set a volume to Recycle, either. True, most of the time, most users will never need to do so. But I can see the potential for legitimately wanting to do so. (See below.) Now, the above all said, I can see a situation in which (perhaps due to a change in storage policy or an infrastructure change that has rendered a large number of stored jobs obsolete) you might want to manually recycle a large number of volumes, but don't want to sit at the console twiddling your thumbs while Bacula purges each volume. There are a number of ways you might choose to address this. One of the more drastic approaches, in the case where ALL saved jobs are now obsoleted, would be to drop all the applicable tables, then manually set all volumes to Recycle status. But it will be rare that you will want to do this. So I suggest that the issue could be addressed in the following manner: First, explicitly document that the "update volume status = Recycle" operation does not purge job data associated with the volume and thus may leave the backup system in an internally inconsistent state unless further work is done to clean up the orphaned jobs, that this operation should not be used routinely as a method for manually recycling individual volumes without performing subsequent catalog cleanup, and that the 'purge jobs volume' command should normally be used instead. Second, add a new console command 'Purge recycled volumes', which will go through the Media table, check each recyclable volume against the job tables, and purge all jobs found to be associated with volumes marked Recycled. Let us suppose that my backup media and the size of my catalog database are such that it takes Bacula around five minutes to completely purge all jobs on a volume from the database. During those five minutes, system load may be high enough to make it difficult to get anything else done due to sluggish console response. I certainly won't be able to get anything else done in that particular bacula console session, because the console is busy waiting for the purge to complete. So, suppose I make an infrastructure change or a storage policy change that obsoletes 40 volumes. If I use "purge jobs volume..." to individually purge each volume, I'm going to spend most of the next three and a half hours sitting around twiddling my thumbs, but I'm never going to have enough downtime in between purge operations to let me get anything much useful done on anything else. If the change described above is made, I instead change each of those 40 volumes to "Recycle" status, which takes me about ... let's say 20 minutes. (Much less, if we extend the 'Update volume' command to add the ability to make batch changes to a list of volumes, as we previously did with the 'Delete job' command.) I then issue the 'Purge recycled volumes' command, and I go away and work on something else for three hours. By the time I come back, it's all done. -- Phil Stracchino, CDK#2 DoD#299792458 ICBM: 43.5607, -71.355 [email protected] [email protected] [email protected] Renaissance Man, Unix ronin, Perl hacker, Free Stater It's not the years, it's the mileage. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
