Thank for your explanation, Andrew. In trying to architect a new service, we're having to architect for both deduplicable and non-deduplicable data. Encrypted data would generally fall into the non-deduplicable category, especially if it's 3rd party encryption with no transparent decryption. I just needed to understand in what scenarios we would recommend one over the other.
Thanks! SF On 8/29/14 2:26 PM, "Andrew Raibeck" <[email protected]> wrote: >Hi Sergio, > >The statement in the Admin Guide refers to data encrypted by the TSM >client. It is as you surmised, via include.encrypt. The TSM server does >not >otherwise know the contents of the files that are stored, so if the data >is >in some encrypted state by a 3rd party, the TSM server is not aware of >this, and it could be eligible for deduplication. How effective >deduplication will be with such data depends on how well this encrypted >data lends itself to being deduped. > >Thus the statement does not apply to data encrypted by a 3rd-party tool, >i.e., if the data has already been encrypted. HOWEVER, there are some >other >issues to understand and consider! > >Some encryption software handles encryption and decryption transparently. >That is, data will be stored on disk in an encrypted state; and when read >back by an authorized user, will be presented in its unencrypted state. >This type of software protects the data from theft of the physical asset >or >from unauthorized users. With one exception, when TSM reads the data, it >will be presented to TSM in its unencrypted state and backed up thus >(unless you use TSM client encryption). > >The one exception is files that are encrypted with Microsoft Windows EFS >(Encrypted File System). In this case, TSM uses the Microsoft EFS APIs to >back up and restore the data in its encrypted form. That is, the data is >NOT backed up or restored by TSM in its unencrypted form. > >Of course, if the files are statically encrypted, such that they appear >encrypted to any other application that tries to open them (there is no >transparent decryption), then TSM will back them up in that form, and has >no awareness of them being encrypted. > >Regards, > >- Andy > >__________________________________________________________________________ >__ > >Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead | >[email protected] > >IBM Tivoli Storage Manager links: >Product support: >http://www.ibm.com/support/entry/portal/Overview/Software/Tivoli/Tivoli_St >orage_Manager > >Online documentation: >https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli >+Documentation+Central/page/Tivoli+Storage+Manager >Product Wiki: >https://www.ibm.com/developerworks/mydeveloperworks/wikis/home/wiki/Tivoli >+Storage+Manager/page/Home > >"ADSM: Dist Stor Manager" <[email protected]> wrote on 2014-08-29 >11:34:50: > >> From: "Sergio O. Fuentes" <[email protected]> >> To: [email protected] >> Date: 2014-08-29 11:35 >> Subject: Encrypted files and TSM Deduplication on TSM 7.1 >> Sent by: "ADSM: Dist Stor Manager" <[email protected]> >> >> Here's an excerpt from official TSM documentation for TSM Server 7.1 >> as a limitation for deduplication: >> >> Encrypted files >> The Tivoli Storage Manager server and the backup-archive client >> cannot deduplicate encrypted files. If an encrypted file is >> encountered during data deduplication processing, the file is not >> deduplicated, and a message is logged. >> >> Can we get more information on this statement? How does TSM know >> that it has encountered an encrypted file? Is it based solely on >> include.encrypt options from the client? Will it look at the object >> metadata to see if it's encrypted? Will it try to post-process an >> encrypted file? In other words, if a file is encrypted say, using >> bitlocker or some third-party app, will TSM know not to process >> those objects for deduplication with the identify procedures? >> What's the overhead in calculating this scenario out? Has anyone >> tested this with TSM server 7.1? >> >> Thanks! >> Sergio
