>> >> i read somewhere, thats this problem is solved in newer versions of >> >> bacula (think it was 2.2.*).
> > The thought of upgrading the whole environment to > > a 2.+ release is more that I could cope with right > > now! > I only have about 10 clients, but I did the whole thing in about 35 mins > the other day. I've been using the version provided by BlastWave, which > provides an easy update mechanism. They also provide the SMF information > used in Solaris 10 instead of an init script. For Linux, I've just been > using the RPMs that are already available. 1.38.11 is a little bigger of > an upgrade than 2.0.3 to 2.2.5 (which is what I did), but the upgrade > from 1.38.11 to 2.0.3 (that is when I switched to the CSW packages) was > pretty painless too. We use Solaris, Linux, HP-UX, FreeBSD and Windows - so upgrades are painful. However - I have now upgraded the server to 2.2.5 and it talks to old FD's on all the clients (except HP-UX) fine. I will of course get around to upgrading all the FD's in due course. However ... while the 2.2.5 restore code is clearly using seek() to get to the right place in the volume (file) - which takes about 1 day off the restore time - it still reads really really slowly. I can only assume this is caused by the fact the files are NFS mounted - I just can't understand why it would be so slow when writing the volumes is very fast! Your thoughts welcome - thanks. -- Cheers Jules. ------------------------------------------------------------------------- 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
