it looks like no one from the bacula-users uses verify jobs, here is my problem, since upgrading to 2.2.0 all verify jobs reports OK:
>> 05-Sep 18:32 backup-dir: Start Verify JobId=2111 Level=Catalog >> Job=vclient.2007-09-05_18.32.27 >> 05-Sep 18:32 backup-dir: File: /opt/ic3s/etc/sendmail/t.mailertable >> 05-Sep 18:32 backup-dir: st_ino differ. Cat: 2305637 File: 2305642 >> 05-Sep 18:32 backup-dir: st_size differ. Cat: 1456 File: 1406 >> 05-Sep 18:32 backup-dir: SHA1 digest differs. >> 05-Sep 18:32 backup-dir: File: /opt/ic3s/etc/sendmail/t.mailertable.db >> 05-Sep 18:32 backup-dir: st_ino differ. Cat: 2305642 File: 2305637 >> 05-Sep 18:32 backup-dir: SHA1 digest differs. >> 05-Sep 18:32 backup-dir: File: /opt/ic3s/etc/sendmail/t.mailertable.old >> 05-Sep 18:32 backup-dir: st_ino differ. Cat: 2305641 File: 3515685 >> 05-Sep 18:32 backup-dir: File: /opt/ic3s/etc/apache/apache.base >> 05-Sep 18:32 backup-dir: st_size differ. Cat: 8581 File: 8583 >> 05-Sep 18:32 backup-dir: SHA1 digest differs. >> 05-Sep 18:32 backup-dir: New file: /opt/ic3s/etc/apache/.apache.base.swp >> 05-Sep 18:36 backup-dir: Bacula backup-dir 2.2.0 (08Aug07): 05-Sep-2007 >> 18:36:10 >> Build: x86_64-unknown-linux-gnu debian 4.0 >> JobId: 2111 >> Job: vclient.2007-09-05_18.32.27 >> FileSet: IX-Server-Verify >> Verify Level: Catalog >> Client: vclient >> Verify JobId: 2069 >> Verify Job: Start time: 05-Sep-2007 18:32:29 >> End time: 05-Sep-2007 18:36:10 >> Files Examined: 12,874 >> Non-fatal FD errors: 0 >> FD termination status: OK >> Termination: Verify OK >> after upgrading the bacula-dir and bacula-sd to 2.2.0, i have run a InitCatalog without problems, but with unbelievable speed: files MB time 12.873 352 00:00:14 the last InitCatalog with 2.0.3: files MB time 12.873 352 00:05:44 is this the effect of "Batch insert enabled: yes" ? my clients are still 2.0.3 Best regards Thomas Kern Sibbald schrieb: > Hello, > > Now that we have just released version 2.2.1, as Murphy's law dictates, we > have a couple of more important bugs that seem to affect only older systems. > > One is a problem building with older PostgreSQL versions > The other is a Director critical crash caused by new code that supports > certain older "brain damaged" OSes (including Win32). > > Note: the above problems only affect a small number of systems. Any recent > version of Linux, Solaris, FreeBSD should have no problems. > > Normally, I would just release a couple of patches, but the problem affects > the current Win32 Bacula servers, so we *must* release a new Win32 binary. > > Bottom line: I'm very likely going to make a release of version 2.2.2 at > least > for Win32, and either a patch or a full release for the source code. > > IMO, there is no reason to make new releases of the rpms unless one of the > released rpms fails, which I think is unlikely. > > Question: does anyone feel that the 2.2.2 release should have anything other > than Eric's PostgreSQL configure fix, my Director crash fix, and Scott's > new .spec files (already committed)? > > Regards, > > Kern > > ------------------------------------------------------------------------- > 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-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- 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-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
