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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
