Thanks Wanda... you always have great recommendations.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Tuesday, March 17, 2015 10:21 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] !RE: Node "cleanup"
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 AT VM.MARIST DOT EDU] On Behalf Of
Vandeventer, Harold [OITS]
Sent: Tuesday, March 17, 2015 4:32 PM
To: ADSM-L AT VM.MARIST DOT 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.
***********************************************************************
|
