On Oct 8, 2008, at 4:15 PM, Joe Mannuzza wrote:

>
> Dan Langille wrote:
>>
>> On Oct 8, 2008, at 3:57 PM, Joe Mannuzza wrote:
>>
>>> Dan Langille wrote:
>>>>
>>>> On Oct 8, 2008, at 1:11 PM, Joe Mannuzza wrote:
>>>>
>>>>> Dan Langille wrote:
>>>>>>
>>>>>> On Oct 2, 2008, at 1:54 PM, Joe Mannuzza wrote:
>>>>>>>
>>>>>>> Has anyone had issues doing a restore of large sets of data  
>>>>>>> via bacula?
>>>>>>> Specifically, has anyone also noticed the process taxing the  
>>>>>>> CPU?
>>>>>>
>>>>>>
>>>>>> Can you be more specific regarding these processes?
>>>>>>
>>>>>> At what stage of the backup does the CPU get taxed?
>>>>>>
>>>>>> It is normal for the tree building phase to require lots of CPU
>>>>>>
>>>>
>>>>> Dan,
>>>>>
>>>>> Thanks for the response.  I am unsure at what stage it gets  
>>>>> bogged down.  Is there a way to check after the fact?
>>>>
>>>> Not that I can think of.
>>>>
>>>>> Also, there were many backups going on at the same time of the  
>>>>> failure- around 40.  Server info: 2 Xeon 5150 @2.66 gigs, 3 gigs  
>>>>> of RAM.
>>>>
>>>> Is that normal?  Do you usually run 40 concurrent backups?
>>
>>
>>
>>> We don't always have that many going, but from 5:00 Pm to 8:00 or  
>>> 9:00 ish we can have up to 45.  We don't have any problems with  
>>> our backups unless a restore is running at the same time.
>>
>> So you're asking if doing a restore while there are 45 backup jobs  
>> are running might tax the CPU. The answer is yes.
>>
>> How much this will tax the CPU depends upon too many factors to  
>> discuss in this scope.
>>
>>> Is it possible that the de-compression that the Bacula server is  
>>> performing is putting too much load on the CPU (combined with the  
>>> backups)?
>>
>> Decompression?  By bacula-dir?  There is no decompression done  
>> there AFAIK.  Sometimes bacula-fd can do decompression if you are  
>> using software decompression.


> One of the problems we run into is when we try to restore a server  
> with a large amount of HDD space used (well, just around 40 gigs  
> total for 2 disks), it takes all day to complete and goes into the  
> night when the backups are being completed.  By all day I mean from  
> 9:00 am until 8:00 PM.  Should a restore of that size take so long?   
> Is there a way to speed up restores so that they don't take all  
> day?  If we wanted to restore a system with 100 gig used HDD space,  
> what could we do to speed up the process, if anything?   We don't  
> have backups running from 8 AM to 5 PM  except for a few stragglers  
> from the night before (4 at the most, not an issue for us).

Please remember to cc the mailing list.

I am not following the above.  Let's keep it simple.

The length of time it takes to restore data depends on many things:

- how fast your hard drives are
- how much the system is being used at the time
- how fast your network is (for sending data from bacula-sd to bacual- 
fd where it is restored)
- are these many small files or many large files?  Writing 10GB of  
data in 10 files takes far less time than writing the same amount of  
data in 100,000 files.

Those are the just the things I can think of now.

If you can paste us the output of one of these jobs, that will give us  
some context.

-- 
Dan Langille
http://langille.org/





-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users