Thanks for the info about this technote. I'm glad to know there are other people who have to deal with this issue!
However, I believe this technote has errors. * The sections (A1-A4) that explain how to LOCATE the tape that contains a particular file backup version are correct and useful. * Sections D-E that explain how to CLEAN UP the contaminated files contain errors and will not work in many cases. The idea in B-D is to rebind the contaminated file to a new management class. The first problem is that when a security spill occurs, the security officer will usually delete the contaminated files from the hard drive right away. You CANNOT rebind a file that doesn't exist. So the first instruction in D should say, "If the contaminated file does not still exist on the hard drive, create a dummy file of the same name in the same path". OTHERWISE the files will not rebind. On the other hand, if the contaminated file IS still on the hard drive, when the backup is run in D, the new management class will rebind all backup versions and cause the INACTIVE backup versions to be deleted, but NO management class ever removes the ACTIVE backup of an active file. The active backup of the contaminated file will remain valid, and migrate to the new tape.. The backup should be run FIRST against an existing file to cause rebinding, then the file should be deleted, then a backup run a SECOND time to inactivate the last copy. The problem with E is that it the syntax as shown does not reconstruct aggregates. If the misclassified file is small enough to live in an aggregate, it will get copied to the new tape by the MOVE DATA. The correct syntax is: MOVE DATA vvvvvvv RECONSTRUCT=YES. Here is what I believe to be the correct procedure for items D-E; if anybody can correct my interpretation, please respond. When we get a concensus on the correct procedure I'll try to find sombody who can correct the technote. D: Run a backup 1. Since the file was misclassified, you may have already DELETED it from the hard drive. In this case, use NOTEPAD and create a dummy file of the same name in the same path. 2. Open the Backup/Archive GUI, click BACKUP, select the file, and back it up. This causes all file backup versions to be bound to the new management class. 3. VERIFY that the file is bound to the new management class: o Open the Backup/Archive GUI, click RESTORE o From the top menu, pull down VIEW-> Display active/inactive versions o In the file tree, navigate to the file in question. o In the right pane, scroll to FAR right and check the management class: it should say mmmmmmmmmm, where that is the name of your new management class, for ALL versions of the file in question. 4. NOW delete the file (or the dummy file of the same name) from the hard drive. 5. Open the Backup/Archive GUI and run ANOTHER incremental backup of the DIRECTORY where the file used to be. This will cause all versions to be marked inactive. 6. Verify that everything worked as it should. o Open the Backup/Archive GUI, click RESTORE o From the top menu, pull down VIEW-> Display active/inactive versions o In the file tree, navigate to the file in question. o In the right pane, all the versions of the file should be GONE. 7. From the TSM server, enter: EXPIRE INVENTORY. This starts a background process; wait until the background process completes to proceed. E: Move Data Corrected syntax: MOVE DATA nnnnnn RECONSTRUCT=YES ================================================================= -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Neil Schofield Sent: Wednesday, November 10, 2004 9:26 AM To: [EMAIL PROTECTED] Subject: Re: How to remove a single file from a TSM backup tape volume Nancy I've used the unsupported DELETE OBJECT and would endorse the statement Richard makes in his Quick Facts - namely that it does not update all the necessary tables to fully remove the object from the TSM server. When I subsequently ran an AUDITDB on the database, inconsistencies were flagged up for that OBJECT_ID. I was using it to delete TDP for Oracle backups that the RMAN catalogue had 'forgotten' about, but with a file system client, I would recommend following the advice in IBM technote # 1166278. Regards Neil Schofield Yorkshire Water Services Ltd Are you drinking enough water? Find out more on our new website designed for children, http://www.cool-fuel.com The information in this e-mail is confidential and may also be legally privileged. The contents are intended for recipient only and are subject to the legal notice available at http://www.keldagroup.com/email.htm Yorkshire Water Services Limited Registered Office Western House Halifax Road Bradford BD6 2SZ Registered in England and Wales No 2366682