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
|
