Don't see the purpose of renaming it-- If you just do: exclude.dir e:\data
That has the same effect. It excludes them from backup, the existing backups get marked inactive on the next backup run, and the countdown clock starts for the number of days to keep the last version. If it's a lot of data, I've also done it as a 2-step process to get a more immediate effect: Step 1: Create a management class called BLACKHOLE, with VEREex 1 VERDel 0 RETex 0 RETonly 0 That says don't keep any versions after the files are marked inactive. In dsm.opt add: include e:\data\...\* BLACKHOLE Run an incremental backup (of everything or just that directory is fine). The files should get REBOUND to the BLACKHOLE management class. (You can see that if you open the restore GUI and scroll all the way to the right, it says what mgt class the file is bound to.) >From now on the new BLACKHOLE rules will apply. Step2: Now in dsm.opt, replace the INCLUDE with EXCLUDE.DIR e:\data\ Bounce scheduler. Next backup marks the files as inactive, and KABLAM! Since they are bound to BLACKHOLE (retextra=0 and retonly=0) they go away immediately instead of hanging around longer. Your space totals will be updated the next time EXPIRE INVENTORY runs. Wanda Prather TSM Consultant ICF International Enterprise and Cybersecurity Systems Division -----Original Message----- From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Vandeventer, Harold [OITS] Sent: Tuesday, March 17, 2015 4:32 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Node "cleanup" I've gotten caught in a bill-back hassle with one of our clients. Quick background: 1. Node1 has backed up their data for years. 2. Node2 was created to back up a new server. 3. Some, but not all, data has been COPIED from the Node1 server to the Node2 server. Not moved, just copied. They can't access the data, but refuse to let server admins delete it. 4. This has resulted in "double-billing" because TSM server now has both Node1 and Node2 with the data that was copied. 5. Node1 has to stay in production to backup data that will never be relocated. Will this approach work to clean up TSM DB occupancy for Node1 data? 1. Rename folder E:\DATA to E:\OLDDATA. 2. Place an EXCLUDE.DIR E$\OLDDATA in dsm.opt 3. Stop/start the scheduler. Will TSM resolve E:\DATA (which no longer exists) and all the files in it and its sub-folders as a "deleted files" and expiration processing would remove those files from the TSM DB for Node1? There are sub-folders to OLDDATA, so the syntax for the EXCLUDE.DIR will need to respect that structure. The expire would delete E:\DATA when the "keep the last file version" term has passed. Other folders in E$ will continue to backup from Node1. Thanks for helping out. ------------------------------------------------------------ Harold Vandeventer Systems Programmer State of Kansas - Office of Information Technology Services STE 751-S 910 SW Jackson (785) 296-0631 [Confidentiality notice:] *********************************************************************** This e-mail message, including attachments, if any, is intended for the person or entity to which it is addressed and may contain confidential or privileged information. Any unauthorized review, use, or disclosure is prohibited. If you are not the intended recipient, please contact the sender and destroy the original message, including all copies, Thank you. ***********************************************************************