Alex, I cannot agree more strongly. As an IT professional, it has been
the whole end of my exertions to prevent exactly this. I like working
with WDSF/ADSM/TSM because it makes it very hard to lose data.
If you don't want it restored, don't back it up, or perhaps the activity
that those files document (e.g. at Enron) should not take place at all.
But once it's backed up, I as a professional Backup Administrator have a
moral obligation to protect it. I work to protect data against a
multitude of disasters: fire, flood, accidental erasure, building
collapse, software malfunction, equipment failure, computer viruses,
malicious hackers. The Enron debacle has taught us that "Corruption" is
yet another disaster.
But the other part of my responsibility for people's data is to NOT go
pawing through it. The CEO should simply delete his naughty pix,
quietly, and they WILL eventually go away, unnoticed by me, and
protected from anyone else by good security systems. That is, unless
there's a court order, or if he's stupid enough to ask me to shred them,
which brings them to my attention and opens up a whole new moral
Pandora's Box. I hope never to be placed in that position. Even in a
two-key system we really do hold both keys, as the systems programmers.
Technically, it is more difficult than simply erasing and writing over
disks and tapes. You've got to throw the media into a vat of acid. A
magnetic tape or disk can be recovered several generations back. The
answer, "Do nothing and let TSM expire it on its own," is not much
riskier than any extraordinary measures short of that vat of acid, so
why bother?
Thank you, Alex, for raising this thread to a new level - the moral
level.
Roger Deschner University of Illinois at Chicago rogerd AT uic DOT edu
======I have not lost my mind -- it is backed up on tape somewhere.=====
On Wed, 20 Feb 2002, Alex Paschal wrote:
>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
>
>
>-----Original Message-----
>From: Scott Foley [mailto:sfoley AT NETDOCUMENTS DOT COM]
>Sent: Wednesday, February 20, 2002 2:49 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: How do you Shred a document from TSM?
>
>
>We have the need to be able to completely delete (shred) a document. Once
>shredded, it can't be restored. I need to be able to remove it from all the
>tape pools, disk pools, off site tapes, off site databases, archive tapes
>etc.
>
>Is this possible? If I delete the document from the database (how is this
>done), how do I then delete it from the seven backup databases that are
>stored off site? I do not want to wait a week until they are replaced with
>new database backup tapes. Is deleting it from the database enough? Is
>there anyway to get the document off of a tape (or disk pool) once removed
>from the database? Once a tape is assigned to a scratch pool, but not used,
>can it be returned to its previous status or is it effectively erased?
>
>Thanks for any help,
>
>Scott Foley
>Part time TSM admin
>
|
