On Fri, 12 Oct 2007, Arno Lehmann wrote: Doh ! I knew it was simple ! I looked at the original package startup scripts and they don't start the file daemon as user bacula. So my single file restore seems to have worked just fine when the file daemon runs as root.
I agree that sqlite is probably not the best for large databases, but a) it is what the original packages were built for (one argument against pre-packaged software - cf FreeBSD's ports system) and b) I've seen MySQL database hosed by a server crash. That said, I've been pretty conservative with my bacula sqlite database, dumping it to ascii input every week. Thanks again very much for your help. Dirk > Hi, > > 12.10.2007 22:03,, Dirk Kleinhesselink wrote:: >> My apologies if this has a simple solution, but I couldn't find anything >> with a (quick) search: >> >> I've been running bacula 1.38.x for quite awhile and it's been >> very nice, except for the massive amount of time the database >> attr spooling takes - mine is huge due to the tremendous number of >> files my users create with their data. My 1.38 setup was packaged and >> built against sqlite (2.8?) and I decided to upgrade bacula and switch >> to sqlite3. So I built bacula-2.2.4 enabling sqlite3, used the >> upgrade sqlite script to go from 9 to 10, dumped the sqlite database, >> imported that into sqlite3 and setup to run the new bacula. > > If you see performance problems, SQlite is probably not the best > catalog backend for you. MySQL and PostgreSQL deliver a better > performance, I believe. > >> The database >> seems OK and so I went to test by doing a restore. Well, the restore >> seems to have located the file on the tape, but couldn't write into >> the scratch area I setup to dump it into. My packaged 1.38 bacula >> setup was configured to run as user bacula, group bacula and so I >> ran my new daemons also as user bacula, group bacula. I haven't had any >> restore issues with the 1.38 setup, generally I restore into scratch >> areas and all ownership, permissions have come back OK. >> >> I'm running on linux - is there something I've missed building/configuring >> my new 2.2.4 bacula daemons ? The daemons aren't and weren't suid. > > The FD should run as user root as it typically needs to be able to > access all files on your system. Otherwise, you'll find you have to > set up permissions in a way that I can only describe as a nightmare. > > As a quick work-around, you might consider changing the permissions of > your scratch restore area to allow the FD write access. > > Arno > > ------------------------------------------------------------------------- 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
