You are very welcome! On Thu, Mar 19, 2009 at 11:20 AM, Rainer Wolf <rainer.w...@uni-ulm.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.w...@uni-ulm.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.w...@uni-ulm.de >>> kiz - Abt. Infrastruktur Tel/Fax: ++49 731 50-22482/22471 >>> Universitaet Ulm wwweb: http://kiz.uni-ulm.de >>> >>>