On Thu, Jun 04, 2009 at 09:20:34AM +0200, Christian Gaul wrote: > Bob Hetzel schrieb: > > Greetings, > > > > I've been seeing an issue whereby a volume gets marked in error > > periodically. The last items logged about that volume are typically like > > this: > > > > 02-Jun 11:53 gyrus-sd JobId 83311: Volume "LTO224L2" previously written, > > moving to end of data. > > 02-Jun 11:53 gyrus-sd JobId 83311: Error: Bacula cannot write on tape > > Volume "LTO224L2" because: > > The number of files mismatch! Volume=46 Catalog=45 > > 02-Jun 11:53 gyrus-sd JobId 83311: Marking Volume "LTO224L2" in Error in > > Catalog. > > > > I don't think I have any SCSI errors, but instead the problem seems to be > > related to bacula not properly keeping track of the volume files in some > > rare case. > > > > This time the problem happened not too long after the volume got recycled > > and so I noted one thing about how the tape was used... a backup started on > > another volume and then spanned onto it. Could that be a source of these > > problems? > > > > Here's the pertinent part of the bacula log file--debugging not turned on > > right now but I'm hoping enough got logged to help. If not I'll have to > > turn debugging back on but what level would be good for determining the > > source of that error? > > > > http://casemed.case.edu/admin_computing/bacula/bacula-2009-06-01.log.txt > > > > Bob > >
> To me this looks like an issue reported a couple of times on this list, > once by me and once by another user, whereby Bacula isnt updating the > Volume Files when doing concurrent jobs. > > So far nobody has seemed interested in it. For me and another user it > has "worked" to set the maximum concurrent jobs to 1 on the device.. > Yes, you will have jobs piling on for hours until they get worked off. > > I witnessed this first after upgrading from 2.4.4 to 3.0.0 but have not > been able to track it down myself or i would have made a proper > bugreport for it.. > > Hope that helps a little Hi, we're running bacula 2.2.8, using concurrent jobs = 2 on a disk based set of volumes. I've done several restores from those volumes without any errors, and haven't seen the error you mention in a good 3 months or so since having switched from concurrent jobs = 1 to " = 2", so I'd consider this a "positive" report that the feature actually does work. The problem bug may have been introduced in a later version of bacula. All the best, Uwe -- uwe.schuerk...@nionex.net phone: [+49] 5242.91 - 4740, fax:-69 72 Hauptsitz: Avenwedder Str. 55, D-33311 Guetersloh, Germany Registergericht Guetersloh HRB 4196, Geschaeftsfuehrer: Horst Gosewehr NIONEX ist ein Unternehmen der DirectGroup Germany www.directgroupgermany.de ------------------------------------------------------------------------------ OpenSolaris 2009.06 is a cutting edge operating system for enterprises looking to deploy the next generation of Solaris that includes the latest innovations from Sun and the OpenSource community. Download a copy and enjoy capabilities such as Networking, Storage and Virtualization. Go to: http://p.sf.net/sfu/opensolaris-get _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
