From: Mantis B. T. <no...@bu...> - 2010-11-22 21:08:13
|
The following issue has been SUBMITTED. ====================================================================== http://bugs.bacula.org/view.php?id=1666 ====================================================================== Reported By: craigmiskell Assigned To: ====================================================================== Project: bacula Issue ID: 1666 Category: bscan Reproducibility: always Severity: minor Priority: normal Status: new ====================================================================== Date Submitted: 2010-11-22 21:08 UTC Last Modified: 2010-11-22 21:08 UTC ====================================================================== Summary: Bscan recreates jobmedia records unnecessarily, and only creates one Description: When bscan is run on a volume with a job which has hit it's File Retention period, but not the Job Retention period, bscan will create a single new jobmedia record, even though there are existing jobmedia records in the database. Further, this record covers the entire section of the media where the job is, rather than inserting one record per on-media 'file', as is done by the backup job. Consequently, when running a restore from files on that job, there will be entries in the bsr as many times as there are jobmedia records that cover the required fileindexes (2, after a backup and a single bscan; one added for each subsequent bscan). The restore will complete, but often using the newly inserted jobmedia records rather than the more efficient ones from the original backup, which can be very slow due to having to scan the whole tape rather than fast forwarding. The final log for the restore also reports: "warning file count mismatch", and the expected file count differs from the restored file count, which can be concerning to some operators. The attached patch creates jobmedia records in the database equivalent to the original backup, but only if they don't already exist. In creating this patch, I saw what appears to be some oddness in the block numbers inserted into these records by the original backup, which I'll raise in another ticket. As arrogant as it sounds, I think the values inserted by this patch are more correct than the originals. I think that worries me slightly; either there's a true bug in the original record creation, or I don't understand what I'm doing. The patch has been reasonably well tested in some simple cases involving: a) single job on one volume b) three jobs (two clients) on one volume varying from a File Retention purge, missing JobMedia records, through to a full Purge of the original volume. All jobs were small (~30GB or less). I'm not in a position to easily test a backup that spans volumes, although I've attempted to handle that correctly and hope that it will work. Please let me know if you require a contributor agreement be signed for this patch; it could well be too large to just accept, although is still just a patch and is well contained. I'm happy either way. ====================================================================== Issue History Date Modified Username Field Change ====================================================================== 2010-11-22 21:08 craigmiskell New Issue 2010-11-22 21:08 craigmiskell File Added: 0001-Patch-to-make-bscan-do-better-with-jobmedia-records.patch ====================================================================== |