You are very welcome!
On Thu, Mar 19, 2009 at 11:20 AM, Rainer Wolf <rainer.wolf AT uni-ulm DOT
de>wrote:
> Hi Wanda ,
> thanks a lot for this detailed clarification and your additional idea !
> - it makes all sense and is quite comprehensible now
>
> Rainer
>
> Wanda Prather schrieb:
>
>
> 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
>>>
>>>
|
