Here are the results after moving the postgres database to another disk: Initial jobs were like the ones at the end of my earlier report, involving the directories with c 4,000 files. 93 seconds first try (277kb/s) 20 seconds 2nd try (1679kb/s)
Then I switched to the one I used at the beginning of my earlier reports (c. 1,000 files) 42 sec first try (578 kb/s) 20 sec 2nd try (2427 kb/s) I'm not sure what to make of this. The 93 second run may have been slow because bacula was busy doing setup on a nearly empty database. It definitely was slowed by another process (evolution) having a seizure and using all the CPU for quite awhile (30 seconds?) On the other hand, my first backup of that directory in my previous report (with catalog on same drive) was 92 seconds, which is close to 93. The second set of runs had times of 64 and 13 the first time around. The disk my catalog is on is probably slower, as raw hardware, than the earlier disk. I had significant problems migrating the catalog. bconsole showed the old jobs when I did a status dir, even when I had the old database shutdown and the director references to it commented out. Here's what I did: dumped schema only from the old postgres cluster. created bacula datase and user on the new cluster. pg_restore to populate that database. Edit director file to point at new database. run. Is there a better way to do this? Have I messed things up by this switch? Ross ------------------------------------------------------------------------- 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
