Bacula-users

Re: [Bacula-users] restores not working

2010-03-24 12:37:27
Subject: Re: [Bacula-users] restores not working
From: "Jonathan R. Dundas" <jonathan.dundas AT gmail DOT com>
To: Bacula-users AT lists.sourceforge DOT net
Date: Wed, 24 Mar 2010 11:35:01 -0500
On Wed, Mar 24, 2010 at 8:32 AM, Matija Nalis <mnalis+bacula AT carnet DOT hr> 
wrote:
>>> It is probably not hung, but just very, very slow.
>>
>> Yes. You probably need a LOT more ram and to tune mysql's parameters.
It appears so!  I've spent a large amount of time tweaking MySQL
actually, it must be RAM.

> (Before you ask, we've had to upgrade because there were [and still
> are in 5.0.1, although somewhat rarer] bugs with director stopping
> working -- otherwise we would've downgraded back to 3.0.x)
We had similar problems but as best I could figure at the time they
were issues with MySQL Redhat distro RPM's.  The MySQL database would
just be hung, and have to be killed and restarted.

> We'd try tweaking key_buffer (and converting to InnoDB and tweakings
> innodb_buffer_pool_size), join_buffer_size, max_heap_table_size,
> tmp_table_size, sort_buffer_size, read_buffer_size, read_rnd_buffer_size
> but in the end we've had to reduce retention to just a few weeks in order
> to make the restoration happen in reasonable times (ie. getting the file
> selection in less than 10 minutes).
On a modest Dell rackount with an E4500 2.2GHz CPU, 1GB of RAM & 2
raid1 SAS disks, retention 5 weeks, about 20 clients and about 100mil
rows in File, the restore query for 'building directory tree' would
still not be done after 24 hours with 5.0.x, whereas for 3.x.x the
time to do this was not noticable.  Maybe 2 min?

>> Even with 48Gb ram, a few restores on our system (~255 million File
>> records: up to 4 million files on some full backups but nost are under
>> 100k entries) could take an hour to get past the "building directory
>> tree" stage.
wow.

>> It's a _lot_ faster with postgresql and moderate tuning (My other gripes
>> about the changeover notwithstanding, those are annoyances, not
>> showstoppers)
I am in the middle of repopulating our database with bscan into a
postgres database hoping to find the same speed increase.  I've given
up on recovering the database or solving the problem with using MySQL.

> As it is, it is *much faster* for us if we need to restore one file
> to do a complete restore of whole server and then delete 99.999% of
> the files, than to use the file catalog to select few files to
> restore.
I wish I had that avenue, but a few of our servers have a TB of user
data, which makes it not viable for us.

------------------------------------------------------------------------------
Download Intel&#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users