Make sure that they are asking questions that meet their needs.  For the disk 
based data, the disks are as secure as the OS and data center.  If that is not 
secure enough then there is either an issue with physical security or as 
suggested disk encryption will be needed.  Consider whether the data is more 
secure on the TSM server than the node.

Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Joerg Pohlmann
Sent: Saturday, June 20, 2009 6:57 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] A Challenge?

Hi Guenther. Delete the filespaces for the node in question, then remove
the node - the completion of these processes/commands showing in the
activity log is what you can provide to your customer. The assurance that
the data is gone can be given in the form of the DRMDBBACKUPEXPIREDAYS
having elapsed and/or the volume history for database backups showing that
the database backups go back only to a date after the filespace deletion/
node removal. Assuming that the tapes returned from offsite have been
reused, there is now no "normal" way of getting the data back with TSM or
other OS-based utility. The only thing left over is the residual data issue
- the customer's data could have remnant traces of bytes of their data on
any tape volume or disk drive where, in the case where the disk drives and
tape volumes fell into the wrong hands, the customer's data could be
identified, given huge amounts of time, money, and computing resources. The
only realistic way to remove the residual data issue is to go with drive
level encryption on a DS8000 and tape encryption on LTO4 or TS1120/1130.

Hope this helps.

Joerg Pohlmann
250-245-9863


"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU> wrote on 2009-06-20
01:32:20:

> Hi *TSMlers,
>
> given the following scenario:
> - one TSM Server
> - a lot of filesystem clients (mostly AIX/RH EL)
> - daily backup goes to a disk pool (some kind of cache) then to
sequential
> access file volumes
> - copy pool is on LTO2-tapes, residing in IBM 3583 libraries
>
> This ist working pretty will till now.
>
> Now the challenge:
> One special customer requests us to provide detailed information
(logfiles or
> something similar) about shredding all his backup data. I thought of
using
> the shred-feature introduced with TSM 5.4.
> But that does not work for sequential access volumes, nor does it for the
> copy_pool.
> And on the ramdom access disk pool it works only if i switch off
thecache=yes
> parameter.
> So i am some kind of stuck .. am I missing something?
> Any hints on this?
>
> regards Guenther
>
> --
> Guenther Bergmann, Am Kreuzacker 10, 63150 Heusenstamm, Germany
> Guenther_Bergmann at gbergmann dot de


This e-mail (including any attachments) is confidential and may be legally 
privileged. If you are not an intended recipient or an authorized 
representative of an intended recipient, you are prohibited from using, copying 
or distributing the information in this e-mail or its attachments. If you have 
received this e-mail in error, please notify the sender immediately by return 
e-mail and delete all copies of this message and any attachments.
Thank you.