Re: [ADSM-L] Encrypted files and TSM Deduplication on TSM 7.1

2014-09-02 20:30:34
Subject: Re: [ADSM-L] Encrypted files and TSM Deduplication on TSM 7.1
From: "Sergio O. Fuentes" <sfuentes AT UMD DOT EDU>
Date: Wed, 3 Sep 2014 00:28:37 +0000
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.



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
>otherwise know the contents of the files that are stored, so if the data
>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
>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
>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.
>- Andy
>Andrew Raibeck | Tivoli Storage Manager Level 3 Technical Lead |
>storman AT DOT com
>IBM Tivoli Storage Manager links:
>Product support:
>Online documentation:
>Product Wiki:
>"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2014-08-29
>> From: "Sergio O. Fuentes" <sfuentes AT UMD 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

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [ADSM-L] Encrypted files and TSM Deduplication on TSM 7.1, Sergio O. Fuentes <=