A complete backup takes several days so I didn't run the compressed backup to
completion. But if I use examined files as a gauge it's wasn't as bad as 8x.
It took 16 hours to process 300,000+ files with compression enabled and only 4
with it disabled.
Derek
On Jul 1, 2010, at 18:57, "James
>
> I've seen a very significant slow in backup speed by enabling gzip
compress,
> 32MB/s (without gzip) vs 4MB/s (with gzip). The server I'm backing
up has
> lots of CPU 24x2.6ghz so the compression time shouldn't be a huge
factor. Is
> this normal for bacula or is there an optimization I'm mi
Hi,
On Thu, 01 Jul 2010, Derek Harkness wrote:
> Sorry I miss spoke in the original post. I'm backing up a server which
> has 24x2.6ghz cpus and is barely using any of them.
Sorry, on reflection, you were quite clear. I misread :-)
Gavin
---
On 07/01/10 15:27, Derek Harkness wrote:
> Sorry I miss spoke in the original post. I'm backing up a server which has
> 24x2.6ghz cpus and is barely using any of them. I bacula server is much
> smaller, only 4 cpus. It looks like bacula has a single threaded compress
> engine which appears to
Sorry I miss spoke in the original post. I'm backing up a server which has
24x2.6ghz cpus and is barely using any of them. I bacula server is much
smaller, only 4 cpus. It looks like bacula has a single threaded compress
engine which appears to bottle neck the whole process. For most backup
On Thu, 01 Jul 2010, Derek Harkness wrote:
> I've seen a very significant slow in backup speed by enabling gzip
> compress, 32MB/s (without gzip) vs 4MB/s (with gzip). The server I'm
> backing up has lots of CPU 24x2.6ghz so the compression time shouldn't be
> a huge factor. Is this normal for
On 01.07.2010 / 10:05:06 -0400, Derek Harkness wrote:
> I've seen a very significant slow in backup speed by enabling gzip compress,
> 32MB/s (without gzip) vs 4MB/s (with gzip). The server I'm backing up has
> lots of CPU 24x2.6ghz so the compression time shouldn't be a huge factor. Is
> thi
