On Sun, 11 Dec 2005, Kern Sibbald wrote:
The bscan problem that I found caused it to generate a JobMedia record in the database that had an end FileIndex one less than it should have been. This was the last record on a Volume, and the record was continued on the next Volume. When Bacula constructed a bsr, the "optimization" code had this one off problem, so when the restore job ran, the last record (partial) record on the first tape was ignored. When the restore job got the second tape up, after reading the first (partial) record, it realized that the first part of the record from the first Volume was not there, so my insanity check code aborted.
That sounds about right. Perhaps it needed larger tape spools to trigger? AB ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
