Compression algorithms work by removing repeating patterns in the data.
Encryption also works by removing repeating patterns in the data.

So you are correct that no matter what type of drives you are using, the
drives are unlikely to be able to do any significant amount of compression
on encrypted data.

Thus you should turn on compression in the client as well as encryption.
The client is smart enough to compress first, then encrypt.  If you don't
turn on compression first, you will use up twice as much tape on the TSM
server end (assuming avg. compression ratio of 2:1) The biggest drawback of
doing this is that it will slow down your backups, and especially slow down
restores.

Regardless of what combination of encryption/compression you use, whether
client or drive, or how many of those options you have turned on, you won't
have any problems doing a restore.  Everything that was done to the client
data during backup, will get undone, correctly, in order, during a restore.

If you have compressalways yes, the client sends the data even if it detects
that compression makes the data grow some.
If you have compressalways no, if the client detects that compressing the
data makes it grow, it will stop compressing and resend the data
uncompressed.  That will be a bit slower, so you have the option to use it
or not use it.

The statistics will be misleading, no matter what you do, because:.
-The TSM server only knows/records how many bytes the client sends to it.
-The TSM server only knows./records how many bytes it sends out to the tape
drive, it doesn't know how much the drive may or may not compress it on the
other end of the cable.

So (ignoring encryption for a minute):
Assume you are using the 3592 500 GB cartridges, and your data compresses
2:1.

If the client is not doing compression:
The client sends 500 GB of data to the server disk pool during a backup, and
the TSM server later migrates out to the tape drive, which compresses the
data 2:1.
The client stats (in accounting records or the activity log) will show 500GB
of data sent to the server.  Q OCC will show 500GB of data for that client.
Migration stats will show 500GB of data migrated.  But your 500GB cartridge
will only be half full.

If the client is doing compression at 2:1:
The client backup sends 250GB of data across the network to the server disk
pool.  The TSM server later migrates that data out to the tape drive, which
is unable to compress the data again.  The client stats will show 250 GB of
data sent to the server.  Q OCC will show 250GB of data for that client.
Migration stats will show 250GB of data migrated.  But your 500 GB cartrdige
will still be half full.

For capacity planning purposes, you just need to keep in your head whether
your data gets compressed when it's going out to tape.  If you have a
mixture of clients that are compressing and not compressing, it's nearly
impossible to make a capacity planning estimate, you just have to track your
growth from week to week.

Now here's an additional idea that might make life easier:

If your customers are worried about transmission of the data to the TSM
server, they need to encrypt at the client level.  But if their worry is
about the vulnerability of data once it's on tape, just use the encryption
in your TS1120 drives.  It's very easy to set up application-managed
encryption.  The keys stay in the TSM data base, you never need to know what
they are.  You can even encrypt at the storage-pool level.  (Some of my
customers only encrypt their copy pools which are going offsite.).  And the
tape encryption is done with an extra processor & buffer in the drive, so it
doesn't slow down reads or writes.

W






On Wed, Mar 18, 2009 at 11:34 AM, Rainer Wolf <rainer.wolf AT uni-ulm DOT 
de>wrote:

> Hi All,
>
> we normally recommend 'not using TSM Compression' becaus the
> fantastic 3592-drives are doing the compression very well and fast.
>
> If users want to encrypt their data with the tsm-client I tend to
> recommend also using compression because data would be first get compressed
> and then get encrypted (on the client).
> This should help save some space on the tapes but it is only an assumption
> and possibly compression is not essential.
>
> my question is
> If I have a 10GB file and this would appear (without Client-compression and
> without
> client-encryption) as 6GB on the tape (after the hardwarecompression) ...
>
> ... is it possible to say something about what happens if I set up
> TSM Encryption (AES128) and send this file again - now encrypted ?
> Wil this data  appear
>  more at around 6GB,  more at around 10GB, somewhere between  ?
> Or is it something completely unpredictable ?
> Statistics would be also interesting
>
> If it is more at 10GB it makes sense using TSM client-compression just to
> save space.
> Because of the recently discussed problems with restoring
> tsm-compressed data that is aleady compressed by any software
> then the comressalway-Option shouldn't also be used there
> to avoid problems at restore-process ?
>
> thanks in advance for any hints
> Rainer
>
>
> --
> ------------------------------------------------------------------------
> Rainer Wolf                          eMail:       rainer.wolf AT uni-ulm DOT 
> de
> kiz - Abt. Infrastruktur           Tel/Fax:      ++49 731 50-22482/22471
> Universitaet Ulm                     wwweb:        http://kiz.uni-ulm.de
>