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" <storman AT US.IBM DOT COM> 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 |
>storman AT us.ibm DOT com
>
>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" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2014-08-29
>11:34:50:
>
>> From: "Sergio O. Fuentes" <sfuentes AT UMD DOT EDU>
>> To: ADSM-L AT VM.MARIST DOT EDU
>> Date: 2014-08-29 11:35
>> Subject: Encrypted files and TSM Deduplication on TSM 7.1
>> Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
>>
>> 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
|
