On 3/5/2012 9:45 AM, Alan Brown wrote:
> On 05/03/12 14:24, Gael Guilmin wrote:
>> To gain space on the LT0.
> Don't bother.
>
> 1: Compression maxes out at about 30MB/s
>
> 2: LTO has inbuilt hardware compression which is "good enough" and a
> _LOT_ faster than any CPU you can throw at the task.
>
> The _only_ use for compression is on slow WAN links and when writing to
> disk - and for the latter I'd consider using compressing FSes such as
> ZFS in preference to using Bacula compression.

Additionally, Bacula compression is performed by the FD, and in many 
cases the client machines being backed up, laptops, etc., are not very 
capable. Using filesystem compression moves the compression task to the 
SD. The same goes for encryption.

And "good enough" is exactly the point. It is possible that a  high 
performance server could encrypt/compress faster than the LTO drive's 
embedded hardware. Also, consider that, since Bacula performs 
compression on the FD, it already makes use of multiple cores when 
backing up multiple clients simultaneously. Certainly, if you backed up 
enough clients in parallel then the net compression rate would exceed 
the LTO drive's hardware compression rate. But why bother? The limit is 
still the raw write speed of the drive/media. As long as the drive's 
hardware compression/encryption can keep the tape spooling, it is fast 
enough. If it is not fast enough for the application, then additional 
LTO drives are needed.



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users