On Thu, Jul 22, 2010 at 7:07 AM, Rory Campbell-Lange <r...@campbell-lange.net> wrote: > On 21/07/10, Rory Campbell-Lange (r...@campbell-lange.net) wrote: >> On 21/07/10, Craig Miskell (craig.misk...@opus.co.nz) wrote: >> > Rory Campbell-Lange wrote: >> > >On 19/07/10, Rory Campbell-Lange (r...@campbell-lange.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@lists.sourceforge.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
