Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Policy Domain's and Management Classes
- Thread starter swasser
- Start date
ProbablyDown
MIS
Your node can only use the management classes in the domain to which the node is registered.
You can set different domains' 'standard' management class to different retentions if you want, the effect being that if management class is changed, the nodes registered to that domain active data will be rebound to the new retention. Also, if you increase the retention, you will naturally have more data/media to manage.
What is it you are trying to do?
You can set different domains' 'standard' management class to different retentions if you want, the effect being that if management class is changed, the nodes registered to that domain active data will be rebound to the new retention. Also, if you increase the retention, you will naturally have more data/media to manage.
What is it you are trying to do?
- Thread starter
- #3
I was tasked recently with changing our retention settings from 33 days to keeping everything for 2555 days or seven years. I have a feeling this wrecked havoc on our media management. At this time i am not getting media back as vault retrieve or media going to dr. So it then came back to me that we only need to retain data for this time frame on specific servers. So i created a separate policy domain for them and configured it accordingly and wanted to ensure that management classes were separate per policy domain.
ProbablyDown
MIS
Everything?? Even O/S data?
What I would do is create a different management class in the same domain for 2555 days, then, find out the exact data they want to keep for that long and use include statements to direct the data to the correct management class. For instance, have the default retention set to the 33 days for, say, the o/s stuff and create a new management class 7_YEARS (with retention of 2555), but then have an include statement like:
include C:\mycriticaldir\* 7_YEARS
Since it is simple to install an o/s and configure TSM, you end up saving $$ in media, yet you meet the requirement (sometimes government mandated) of storing that particular data for 7 years.
If it is just a few servers and for a certain period of time, I would just set up an archive copygroup with a 7yr retention, archiving the select data through a schedule that you can run a couple of times - or annually if that is the need, and use "-archmc=7_YEARS" in the schedule if the default management class isn't 7 years.
I would only do this if this is something you don't need everyday as archiving tends to drive up the tsm database usage, and if there are tons of files, and the schedule is running daily you will have a whole new set of problems.
What I would do is create a different management class in the same domain for 2555 days, then, find out the exact data they want to keep for that long and use include statements to direct the data to the correct management class. For instance, have the default retention set to the 33 days for, say, the o/s stuff and create a new management class 7_YEARS (with retention of 2555), but then have an include statement like:
include C:\mycriticaldir\* 7_YEARS
Since it is simple to install an o/s and configure TSM, you end up saving $$ in media, yet you meet the requirement (sometimes government mandated) of storing that particular data for 7 years.
If it is just a few servers and for a certain period of time, I would just set up an archive copygroup with a 7yr retention, archiving the select data through a schedule that you can run a couple of times - or annually if that is the need, and use "-archmc=7_YEARS" in the schedule if the default management class isn't 7 years.
I would only do this if this is something you don't need everyday as archiving tends to drive up the tsm database usage, and if there are tons of files, and the schedule is running daily you will have a whole new set of problems.
- Status
Similar threads
- Locked
- Question
- Locked
- Question