FORUMS: list search recent posts

Is using BruPE compression on LTO 5 and 6 a safe option?

COW Forums : Archiving and Back-Up

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
Dean Tyson
Is using BruPE compression on LTO 5 and 6 a safe option?
on Jun 14, 2018 at 6:41:04 am

Hi everybody,

As above, is using BruPE compression on LTO 5 and 6 a safe option?

Apart from the extra time needed, what are the down sides about using compression on tapes?

I have had bad archives in the past and had to use the manual restore options.
Can this also still be done with compressed tapes?

Thanks in advance.

Return to posts index

Tim Jones
Re: Is using BruPE compression on LTO 5 and 6 a safe option?
on Jun 14, 2018 at 4:58:21 pm

Data compression in the computing world is NOT like the data compression that you associate with transcoding.

When you "compress" media by transcoding, you are actually losing data (fidelity). It is unfortunate that the media world has chosen to call this "compression" since it is far more than simple compression and should always be referred to as "lossy" since you are losing data (fidelity) in the resulting file. Once you transcode something to a lesser format, there is no way to recover the information that was lost during the initial transcode.

In the Data world, we use compression that is known as "lossless". This means that when you compress the data, you get back 100% of what you put in when you decompress the data. Imagine if your bank backed up your records with a lossy algorithm and you discover that your $30,000 bank account now only has $300 because the back restored their data after a system glitch ...

Additionally, the compression used in the tape world is known as adaptive in that the software performing the compression (whether in the application or the drive's firmware) is aware of the result of the compression algorithm and can recognize when the compression process is not working on the data supplied.

When you use an LTO drive (all the way back to LTO-1), you are using ALDC - Adaptive Lossless Data Compression. This means that only data that IS compressible is compressed (Adaptive), and you get back 100% of what went through the compression algorithm (Lossless) when you restore that data.

Taking notice of that statement - "data that IS compressible", the bulk of the files that we process in a M&E environment are already compressed. That means that the drive is going to pass most data through to the tape as it was received. This is why, when you are reading the specifications for various tape technologies, you should ONLY pay attention to the "Native" capacity and performance values. This means that you should expect to get:
  • 1.5TB on an LTO-5 tape
  • 2.5TB on an LTO-6 tape
  • 6TB on an LTO-7 tape
  • 12TB on an LTO-8 tape

The magical numbers that are used by most of the manufacturers all are based on a mythical 2:1 or 2.5:1 compression of the data that you are writing to the tape. Even a normal business data server providing email and business document storage doesn't achieve 2:1, let alone 2.5:1. We see normal business data hitting the 1.3:1 or 1.4:1 on average on a good data run.

So far as BRU PE is concerned, we leave the compression decision up to the drive as it is far more aware of the incoming stream. Also, since the drive has hardware dedicated to the compression task, the result is NO slow down of your data speed when writing or reading a tape. The compression switch that you see in the Preferences only applies if you are creating BRU archives on disk. We then use the LZOP compressor to compress the data that is added to the BRU container file. Because this IS dependent on your CPU and RAM speeds, you may notice a slow down when writing archives to disk. But, this has no bearing on archives written to tape.

Tim Jones
CTO - TOLIS Group, Inc.
BRU ... because it's the RESTORE that matters!

Return to posts index

Dean Tyson
Re: Is using BruPE compression on LTO 5 and 6 a safe option?
on Jun 15, 2018 at 6:08:58 am

Thanks very much for this info!

Very good to know....

Return to posts index

<< PREVIOUS   •   VIEW ALL   •   PRINT   •   NEXT >>
© 2018 All Rights Reserved