All this needs to be on the list.

paul wrote:
> Dan,
> 
> I've done all of that ;-(.   When that didn't work, I dumped the tables, 
> recreated them from scratch, and re-ran the backups.   Still get the 
> failure.
> The problem does appear to be the table 'batch' which is a temporary, 
> transient table - hence hard to repair.   Since I dumped the tables and 
> recreated from scratch, it would seem that there is likely some state 
> outside the tables that is surviving the table dump and re-create and is 
> ending up causing the failure to occur.
> 
> I've put in the timeouts for mysql recommended by 
> http://wiki.bacula.org/doku.php?id=faq  (ref Fixing table 'bacula.batch' 
> doesn't exist).   And I'm trying again.
> 
> Failing that, I think I'll trash the "state" files from the bacula 
> working directory (same page, ref: How to Clear you Console History).
> 
> Other than that, I'm out of ideas.
> 
> Paul
> 
> 
> 
> Dan Langille wrote:
>> paul wrote:
>>> I've been getting this error on some of my backups (not all).   The 
>>> full error is:
>>>
>>> 26-Dec 01:00 Arwen-dir JobId 11: Fatal error: Can't fill Path table 
>>> Query failed: INSERT INTO Path (Path) SELECT a.Path FROM (SELECT 
>>> DISTINCT Path FROM batch) AS a WHERE NOT EXISTS (SELECT Path FROM 
>>> Path AS p WHERE p.Path = a.Path): ERR=Table 'batch' is marked as 
>>> crashed and should be repaired
>>>
>>> 26-Dec 01:00 Arwen-dir JobId 11: Error: Bacula Arwen-dir 2.4.2 
>>> (26Jul08): 26-Dec-2009 01:00:34
>>>   Build OS:               x86_64-pc-linux-gnu debian lenny/sid
>>>   JobId:                  11
>>>   Job:                    Arwen_XP64_Backup_Set_2.2009-12-25_20.33.10
>>>   Backup Level:           Full
>>>   Client:                 "Arwen_XP64" 2.4.2 (26Jul08) 
>>> x86_64-pc-linux-gnu,debian,lenny/sid
>>>   FileSet:                "Arwen_XP64" 2009-12-25 20:33:35
>>>   Pool:                   "Backup_Set_2" (From Job resource)
>>>   Storage:                "Backup_Set_2" (From Pool resource)
>>>   Scheduled time:         25-Dec-2009 20:33:26
>>>   Start time:             26-Dec-2009 00:14:57
>>>   End time:               26-Dec-2009 01:00:34
>>>   Elapsed time:           45 mins 37 secs
>>>   Priority:               16
>>>   FD Files Written:       139,974
>>>   SD Files Written:       139,974
>>>   FD Bytes Written:       18,201,877,756 (18.20 GB)
>>>   SD Bytes Written:       18,228,549,111 (18.22 GB)
>>>   Rate:                   6650.3 KB/s
>>>   Software Compression:   39.6 %
>>>   VSS:                    no
>>>   Storage Encryption:     no
>>>   Volume name(s):         Backup_Set_2_0003
>>>   Volume Session Id:      6
>>>   Volume Session Time:    1261630416
>>>   Last Volume Bytes:      185,551,543,549 (185.5 GB)
>>>   Non-fatal FD errors:    0
>>>   SD Errors:              0
>>>   FD termination status:  OK
>>>   SD termination status:  OK
>>>   Termination:            *** Backup Error ***
>>>
>>> I'm running a rotating set of 3 pools on a monthly cycle.   This 
>>> happens ONLY with the 2nd pool and only with 2 of the jobs.   I 
>>> thought at first this might be a MySQL timeout, but this job was only 
>>> 45 minutes in length while another job that takes 28 hours doesn't 
>>> hit this problem.   And this job with one of the other pools doesn't 
>>> hit this error.
>>>
>>> I've tried running bscan to correct the catalog, I've tried dumping 
>>> the entire catalog and redoing the backups.   Still get the error.   
>>> Result is that I can't do any incremental backups of this job since 
>>> the job is never marked as having a full backup.
>>>
>>> This problem was introduced, I think, by running out of space in 
>>> root.   This problem has since been resolved - root is now running at 
>>> 46% utilization.
>>>
>>> Any thoughts on a repair strategy?
>>
>> I think the relevant error is: Table 'batch' is marked as crashed and 
>> should be repaired
>>
>> I would:
>>
>> - stop bacula
>> - do a backup of the database
>> - find out how to repair a MySQL database table and do so
>> - run dbcheck
>> - hope
>>