>>>>> On Mon, 5 Mar 2007 20:53:27 +0100, Kern Sibbald said: > > On Monday 05 March 2007 20:08, [EMAIL PROTECTED] wrote: > > On Mon, Mar 05, 2007 at 06:34:08PM +0100, Kern Sibbald wrote: > > > On Monday 05 March 2007 16:57, [EMAIL PROTECTED] wrote: > > > > On Sun, Mar 04, 2007 at 10:28:29PM +0100, Arno Lehmann wrote: > > > > > On 3/3/2007 12:24 PM, Christoph Litauer wrote: > > > > > > a few of my autochanger tapes have VolStatus: Error. This is > > > > > > because the number of files in the catalogue didn't match the > > > > > > number of files on the tape. I don't know why this happend, is it a > > > > > > known bug of version 1.38.9? > > > > > > > > > > Not a known bug, I think. > > > > > > > > I'm also seeing this using Bacula 2.0.1 on RHEL-4 with a jukebox > > > > holding two LTO-3 drives. It's an intermittent problem that I haven't > > > > been able to reproduce reliably, so I haven't opened a bug report on > > > > it yet. > > > > > > > > > Usually these errors happen in two situations: > > > > > > > > Let me add a third: when a job terminates with a "Fatal" error (those > > > > with a job status code of 'f'), rather than the more common "Error" > > > > error (those with a job status of 'E'). > > > > > > > > Here's my situation: I'm backing up both servers and laptops using the > > > > same hardware and software, but with different tape pools. The > > > > servers never encounter this failure condition; it happens to the > > > > laptops about once every week or two. > > > > > > > > After watching the situation for a while, it seems that the failure > > > > pattern is that these file mismatch errors always occur after a fatal > > > > client error, which in turn is caused when a job begins, writes some > > > > data to tape, and is then unable to continue because the client > > > > machine has been shut down or taken off the network. > > > > > > The above is a known bug (at least to some of us) in 1.38.x. It is fixed > > > in 2.0.x > > > > Thanks for the explaination Kern, I wasn't aware that that had been > > corrected. Since I'm currently running version 2.0.1 of the Bacula > > director, storage daemon, and related server bits, can I assume that > > the problem is with the remaining version 1.38.x clients, and that > > upgrading them will eliminate the problem? > > If I remember right, the problem was with the Storage daemon, so it is very > likely already corrected :-) It seems to me that it was Martin that pointed > it out -- perhaps he remembers the exact details.
The case I found was caused by 0 bytes being written to the tape if the FD bailed out too quickly. This generates two consecutive EOF marks on the tape, which looks like end of tape on a setup with TWOEOF=yes. I think it also failed to update the catalog, so would get mismatches on a TWOEOF=no setup as well. __Martin ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
