On Thu, Jul 22, 2010 at 7:07 AM, Rory Campbell-Lange
<rory AT campbell-lange DOT net> wrote:
> On 21/07/10, Rory Campbell-Lange (rory AT campbell-lange DOT net) wrote:
>> On 21/07/10, Craig Miskell (craig.miskell AT opus.co DOT nz) wrote:
>> > Rory Campbell-Lange wrote:
>> > >On 19/07/10, Rory Campbell-Lange (rory AT campbell-lange DOT net) wrote:
>> > > > I ran a full backup of a volume last week on Bacula v2.4.4 and I
>> > > > have now upgraded to 5.0.2. I'm getting half the throughput last
>> > > > week as I am now.
>> > > >
>> > > > Last week's test volume was a 2.1TB xfs volume and it read/wrote
>> > > > on average at 70MB/s. I am now backing up a 4.4TB ext3 volume and
>> > > > bconsole's status client shows backup running at less than 30MB/s.
>> > > > Hardware compression has been enabled in both cases.
>
>> Spool Size = 250GB                 # maximum spool size for this job
>> Maximum Spool Size = 250GB         # only one job at a time
>> Maximum Job Spool Size = 250000000 # 250GB in bytes
>> Spool Directory = /tapespool       # XFS filesystem preferred?
>
> I am now using a spool to see what is happening for the locally attached
> Coraid storage. The locally attached storage runs at a (contended) write
> of 77MB/s and read of over 100MB/s as confirmed by the tool ddt.
>
> So I now have a Full backup running off local attached storage (Coraid,
> ext3) to fully local storage (HW RAID with BBU, xfs). However bconsole's
> "status client" still shows activity at around 20-30MB/s
> (Bytes/sec=24,363,733) with bacula-fd reading off the target at around
> 20-30MB/s to make a local 250GB file. Incidentally,  bacula-sd
> periodically writes to tape at ~ 100MB/s.
>
> Google searches suggest that there might be a problem with the speed at
> which local spool files are made.
>
> 2006:
> http://www.mail-archive.com/bacula-users AT lists.sourceforge DOT 
> net/msg09171.html
> 2010:
> http://www.adsm.org/lists/html/Bacula-users/2010-06/msg00272.html
>
> Is there a problem with bacula-fd?
>

Have you disabled software compression in your fileset? Also random
filesystem performance even on a raid is not great. While you may be
able to read 500MB/s sequential data if the files needed to backup are
not physically ordered sequentially the rate will greatly reduce. Are
you doing a Full Backup? Is your spool on a different raid than the
source data? If the spool is on the same raid this will cause further
reduced performance because it will be causing more seeks again and
reducing the large sequential operations.

John

------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users