My feeling is that backups are required to do exactly the opposite of this,
i.e., to protect against the accidental "shred -r *" command.

Any backup product that would be able to do this would need, I think, a two
key locking system, voice recognition, and retinal scans from at least one
VP before deleting files from backups.  Anything else just wouldn't be safe
and in the spirit of recovery.  And for situations like the Enron shredding
parties, maybe it should also have a tie to the Judicial branch's computers
for authorization there.

However, if you're going to try to jerry rig it with TSM, I think it would
be too risky to let any volumes from that pool remain (unless collocated).
And if you're going to go through this effort, why bother taking the risk?
I mean, even if you don't KNOW that file was on a certain volume, it might
have been on a dbbackup 20 days ago.

1 Bind the file(s) to a mgmtclass with verdel=0, retonly=0
2 Delete the file(s)
3 Back up again so TSM knows it's (they're) inactive/expired/gone
4 Run expiration to get it (them) out of your current database
5 Create a new copypool
6 Populate it by backing up your primary storagepool to it
7 Create a new primary pool
8 Move all data from your old primary pools to the new primary pool
9 Delete your disk volumes
10 Reformat your disk volumes
11 Redefine your disk volumes
12 Backup the database
13 Send new copypool and the dbbackup offsite.
14 Retrieve ALL volumes that were offsite before this most recent batch
15 Destroy the data old primary and old offsite volumes - overwrite,
degauss, or my favorite, bonfire with a nice old-fashioned crab bake (I
wonder if the crab would taste like plastic?)

Voila, gone, and the rest of your data is still offsite.  Notice, don't
destroy the offsite backups until after you expire, recreate, and offsite
your new copypool, unless the SEC or a Congressional hearing is REALLY
breathing down your neck.  If a disaster happens, ok, OTHER than a legal
disaster, had you destroyed your offsite volumes first, you could be SOL.

Alex Paschal
Storage Administrator
Freightliner, LLC
(503) 745-6850 phone/vmail

** My only explanation is Insanity