-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did you run this with the modify database flag set? This is actually a problem I think should be fixed, and the fix should be backported. Apparently if you search for records without a modify flag, there are situations where the thing can loop forever. I'm not sure where that stands now, but I remember having the same issue.
I seem to recall that more recent versions are much better behaved, but I think if the fixes are relatively easy, a backport to at least 1.38.x is in order. I wonder if one can use new dbcheck against the old DB. Allen Barnett wrote: > Hi, > Thanks to Kern and Arno for pointing me to the dbcheck program (I should > have read the fine manual). I ran dbcheck and was able to eliminate the > orphaned files, but the "eliminate orphaned paths" option ran for about > 24 hours with no sign of letting up! I looked at the source for dbcheck, > but SQL is not my forte. Is there a way to perform the orphaned path > elimination for just a few instances at a time? > > Bacula: 1.38.10 > MySQL: 4.1.20 > RHEL 4, 64-bit > > Thanks, > Allen > > On Wed, 2007-07-25 at 13:54 +0200, Kern Sibbald wrote: >> Hello, >> >> I recommend you read the www.bacula.org -> Support page. It explains the >> best >> way to get support and help. It is also useful, though probably not for >> this >> case, to read the Bugs page as well. I've forwarded your email to the >> bacula-users list in case they have comments. >> >> My recommendation is to read up on the dbcheck program in the manual and run >> it. It *should* be able to correct this problem. If it does not or if the >> problem comes up frequently, or you have questions, you might want to ask >> the >> bacula-users list. >> >> In any future requests, please include the name of the database Engine you >> are >> using. That may also be helpful, though it is probably not needed for the >> current case. >> >> Best regards, >> >> Kern >> >> >> On Wednesday 25 July 2007 13:41, Allen Barnett wrote: >>> Hi, >>> I'm running Bacula 1.38.10 on a Red Hat Enterprise Linux 4 64-bit >>> Opteron box. The last couple of days, I've been getting this message >>> from the nightly catalog backup run. Is there something I need to do to >>> clean up the database(?) Thanks, Allen. >>> >>> 25-Jul 01:12 GLUON-DIR: Start Backup JobId 1086, >>> Job=BackupCatalog.2007-07-24_23.10.00 >>> >>> 25-Jul 01:14 GLUON-DIR: BackupCatalog.2007-07-24_23.10.00 Fatal error: >>> sql_create.c:732 sql_create.c:732 insert INSERT INTO File >>> (FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES (1,1086,1,1,'gB >>> BYSL IGg B A A A cPL8T BAA DiHw BGpwW1 BGpwXz BGpwXz A A C','IV/0N+/T/T >>> +eIAtTB/0d1B') failed: >>> Duplicate entry '27191534' for key 1 >>> >>> 25-Jul 01:14 GLUON-DIR: BackupCatalog.2007-07-24_23.10.00 Fatal error: >>> sql_create.c:734 Create db File record INSERT INTO File >>> (FileIndex,JobId,PathId,FilenameId,LStat,MD5) VALUES (1,1086,1,1,'gB >>> BYSL IGg B A A A cPL8T BAA DiHw BGpwW1 BGpwXz BGpwXz A A C','IV/0N+/T/T >>> +eIAtTB/0d1B') failed. ERR=Duplicate entry '27191534' for key 1 >>> >>> 25-Jul 01:14 GLUON-DIR: BackupCatalog.2007-07-24_23.10.00 Fatal error: >>> catreq.c:424 Attribute create error. sql_create.c:734 Create db File >>> record INSERT INTO File (FileIndex,JobId,PathId,FilenameId,LStat,MD5) >>> VALUES (1,1086,1,1,'gB BYSL IGg B A A A cPL8T BAA DiHw BGpwW1 BGpwXz >>> BGpwXz A A C','IV/0N+/T/T+eIAtTB/0d1B') failed. ERR=Duplicate entry >>> '27191534' for key 1 >>> >>> 25-Jul 01:14 GLUON-DIR: BackupCatalog.2007-07-24_23.10.00 >>> Error: Bacula 1.38.10 (08Jun06): 25-Jul-2007 01:14:27 >>> JobId: 1086 >>> Job: BackupCatalog.2007-07-24_23.10.00 >>> Backup Level: Full >>> Client: "GLUON-FD" >>> x86_64-unknown-linux-gnu,redhat,Enterprise release >>> FileSet: "Catalog" 2006-01-04 00:07:10 >>> Pool: "Default" >>> Storage: "gluon-sd" >>> Scheduled time: 24-Jul-2007 23:10:00 >>> Start time: 25-Jul-2007 01:12:36 >>> End time: 25-Jul-2007 01:14:27 >>> Elapsed time: 1 min 51 secs >>> Priority: 11 >>> FD Files Written: 1 >>> SD Files Written: 1 >>> FD Bytes Written: 473,743,123 (473.7 MB) >>> SD Bytes Written: 473,743,238 (473.7 MB) >>> Rate: 4268.0 KB/s >>> Software Compression: None >>> Volume name(s): t0007 >>> Volume Session Id: 4 >>> Volume Session Time: 1185231255 >>> Last Volume Bytes: 96,074,142,626 (96.07 GB) >>> Non-fatal FD errors: 0 >>> SD Errors: 0 >>> FD termination status: OK >>> SD termination status: OK >>> Termination: *** Backup Error *** > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users - -- ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Systems Programmer II |$&| |__| | | |__/ | \| _| |[EMAIL PROTECTED] - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/AST - NJMS Medical Science Bldg - C630 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGrggcmb+gadEcsb4RAiV6AKDWhhP08RN1+FSciGYQ/lFi/vXS3gCdEBT3 GOT1gt0h9doNWL+Sl9mOEDg= =Ifwd -----END PGP SIGNATURE----- ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
