ADSM-L

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

2014-08-29 14:28:05
Subject: Re: [ADSM-L] Encrypted files and TSM Deduplication on TSM 7.1
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 29 Aug 2014 14:26:01 -0400
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_Storage_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
>
<Prev in Thread] Current Thread [Next in Thread>