We have hundreds of retired servers, both from a server consolidation
project and general server rollover. we decided we requred acces to the
backups and archives on the retired servers, so exports and backup sets
wouldn't work. Also, by keeping the data in the normal pools we keep
redundancy (primary and copy pool) and DR issues covered.
We thought about moving the nodes into their own domain, but decided not to
because most domains use default management classes and we weren't sure how
to keep the policies straight in one domain holding retired servers from
many domains. We thought about a separate retired domain for each
production domain, and rejected it. Finally we decided to simply rename
the nodes. All retired nodes are given a prefix of "zzrt_". For example,
node "someserver" becomes retired node "zzrt_someserver". Normal policies
are allowed to expire inactive versions. We put a comment in the contact
field for when the active versions can be deleted and the node removed.
This is anything but ideal . . . . but I think we found that this was true
for any method. Many if not most of the sql queries we run against the tsm
db have logic to exclude any nodes that are like 'zzrt_%'.
I think a cleaner method would be a separate tsm server for just retired
nodes . . . . . but that has obvious drawbacks also.
If there was one thing I really wish in all this was a comments field. The
only place we found to put comments about a node is in the contacts field.
I wish there was another field where we could enter comments.
I am interested in how others handle this also.
Rick
John Naylor
<John.Naylor@SCOTTISH-SOUT To: ADSM-L AT
VM.MARIST DOT EDU
HERN.CO.UK> cc:
Sent by: "ADSM: Dist Stor Subject: Long term
data retention for retired clients
Manager"
<ADSM-L AT VM.MARIST DOT EDU>
07/14/2005 05:27 AM
Please respond to "ADSM:
Dist Stor Manager"
Hi out there,
Just wondering what the consensus is on the best way to retain TSM client
data that has to be kept for many years (legal requirement) after the
client box is retired.
I have consideredf various approaches
1) Export
2) Backup set
3) Create a new domain for retired clients which have the long term
retention requirement
I see export and backup sets as reducing database overhead, but being less
easy to track and rather unfriendly if you just need to get a subset of
the data back
The new domain would retain great visibilty for the data and allow easy
access to subsets of the data, but you would stiil have the database
overhead.
Does the choice just depend, on how often in reality you will need to get
the data back ?
Thoughts appreciated
John
</p>
**********************************************************************
</p>
The information in this E-Mail is confidential and may be legally
privileged. It may not represent the views of Scottish and Southern Energy
Group.
</p>
It is intended solely for the addressees. Access to this E-Mail by anyone
else is unauthorised. If you are not the intended recipient, any
disclosure, copying, distribution or any action taken or omitted to be
taken in reliance on it, is prohibited and may be unlawful. Any
unauthorised recipient should advise the sender immediately of the error in
transmission. Unless specifically stated otherwise, this email (or any
attachments to it) is not an offer capable of acceptance or acceptance of
an offer and it does not form part of a binding contractual agreement.
</p>
Scottish Hydro-Electric, Southern Electric, SWALEC, S+S and SSE Power
Distribution are trading names of the Scottish and Southern Energy Group.
</p>
**********************************************************************
-----------------------------------------
The information contained in this message is intended only for the
personal and confidential use of the recipient(s) named above. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are hereby
notified that you have received this document in error and that any
review, dissemination, distribution, or copying of this message is
strictly prohibited. If you have received this communication in error,
please notify us immediately, and delete the original message.
|
