Is it possible to delete and shred a file from backup?

[opeth]

From time to time data that should not be backed up to a certain server is backed up by accident (user left file on a share or something). I am trying to figure out a way to delete the file and shred it.

Currently using colocation and we have ways of getting it done on the VTL/Tapes, but I am really looking at the directory container storage pools now and I cant think of a good way to accomplish this.

 

[dicowins]

use DELETE FILESPACE then expire inventory essentially I beleive when you do this you are actually deleting the active version entries of the files/Directories in the DB then expiration expires the inactive versions in DB. In reality the data is still on tapes but is marked as blank space according to DB. So nothing required on tapes (The data is there but marked as blank space according to DB so cant be restored unless you do a full restore of a DB backup that "knew" which tape and location the files were on.

 

[dicowins]

Maybe it also worth explicitally excluding any other drive letters from backups/archives using include/exclude statement.

 

[opeth]

Well i need to delete on a per file basis, and the space where the file was needs to be scrubbed (security thing)

 

[dicowins]

You can specifically delete files as in "delete archive /usr/tsm/FILE.txt" but thats still technically on tape the only way to get rid of is make sure everythings encrypted so switch on encryption in which case for someone to retrieve the data they would need the server security keys and the tape and an old copy of the database which had recorded the original position of the file and on which tape a tad extreme. They have to install keys retore DB checkin tape and KNOW the filename and directory of file. Of course as above if you FILTER out using the include / exclude statement any other drive letters you wouldnt backup the file in the foirst place or of course theres teach the person creating the files in the wrong place to use his local drives to save Files!

 

[opeth]

Still have to scrub the space due to requirments. I can inform people all day long but i still need a procedure and accidents happen.

 

[dicowins]

really the resources required get the data back off the tape especially then to try and decrypt would be monumental. The data would be overwritten next time reclamation runs the data is moved off and tape becomes scratch and then when filled up again it would be overwritten of course this could take time. You could move the rest of the data off the tape so it becomes a scratch tape and is available for overwriting to speed things up. Also when the Databases that have expired and reused the record of where the data was will eventully be impossible to recover the data. Really to all intents and puposes if you have encrption in place and keys unless someone steals the key db backups and knows the tape ITS on and the location and the fuilename ITS virtually impossible to get the file back. or you could of course move data off that tape that isnt that file after deleting and expiring the file and then checkout the tape snd destroy tape. I dont know anyone or company however secure would require such extreme measures unless its to Hide something that was illegal or of national security really youd need to be gchq to even stand a chance to decrypt the data even with the tapes.

 

[marclant]

Still have to scrub the space due to requirments. I can inform people all day long but i still need a procedure and accidents happen.

You are looking for this: https://www.ibm.com/support/knowled...com.ibm.itsm.srv.doc/c_mngdata_shredding.html

Note, that shredding applies only to data in storage pools that have been explicitly configured to support shredding. And only random-access disk pool can be set for shredding.

Container pools do not support shredding, but there's not really a need given the way the data is stored.
- files are broken in chunks
- chunks are stored
- duplicate chunks are referenced, not stored again

So for a given file, TSM keeps track of which chunks are needed to make up that file. Once you delete the backup of that file, TSM deletes the references to those chunks. If other files reference the same chunks, these chunks are not deleted, but it's still not possible to get the file that was deleted, because it's impossible to know which one of the billion chunks on the server used to make up that file.

So your options are to continue to use a directory container pool if you are satisfied that deduplicated data cannot be reconstructed after the file and references are deleted. Or for sensitive data, setup a disk storage pool with shredding.