Re: Decommissioned Servers
On May 23, 2008, at 10:37 AM, Richard Rhodes wrote: It's interesting how the CONTACT field gets used for general comments. I've often wished TSM had a general comment section (variable length) where we could keep track of changes made to a node over time. This would be SO helpfull! The DEFine MACHine and INsert MAchine commands might be used to that purpose, Richard Sims
Re: Decommissioned Servers
We attach the date (as in \\nodename\c$\_20080523) to our old filespaces and set a tickler for deleting them. We will also occasionally rename a filespace to force a full backup if a filespace is becoming too scattered on the offsite media. We set the tickler a little past when the last inactive file would have dropped from the renamed filespace, so we don't violate our retention policies. -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Skylar Thompson Sent: Friday, May 23, 2008 9:31 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Decommissioned Servers Richard Rhodes wrote: > "ADSM: Dist Stor Manager" wrote on 05/22/2008 > 12:36:11 PM: >> 3) We put the clients name into a tracking file with the decommission >> date, so we don't forget when 90 days is up. > > We rename the node with a prefix so decommissioned nodes are easy to > spot in a "q node" listing. We would rename nodeX to zzrt_nodeX. > > We also put a comment in the CONTACT node field with the date the node > can be deleted from TSM, and the ticket number of the request that > asked us to retire the node. > > Once a month someone goes through the TSM servers looking at the > retired nodes and deletes appropriate ones. We do something similar with filespaces. We often are migrating to new storage and have both new and old filesystems setup and backed up. When we decommission the old storage, we'll append _old to the filespace. We then have blanket tolerances in our monitoring system for anything that ends in _old, so we don't get alerts when it's no longer being backed up. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- Foege Building S048, (206)-685-7354 -- University of Washington School of Medicine This electronic transmission and any documents accompanying this electronic transmission contain confidential information belonging to the sender. This information may be legally privileged. The information is intended only for the use of the individual or entity named above. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or the taking of any action in reliance on or regarding the contents of this electronically transmitted information is strictly prohibited.
Re: Decommissioned Servers
It's interesting how the CONTACT field gets used for general comments. I've often wished TSM had a general comment section (variable length) where we could keep track of changes made to a node over time. This would be SO helpfull! Rick Timothy Hughes <[EMAIL PROTECTED] IT.STATE.NJ.US>To Sent by: "ADSM: ADSM-L@VM.MARIST.EDU Dist Stor cc Manager" <[EMAIL PROTECTED] Subject .EDU> Re: Decommissioned Servers 05/23/2008 10:12 AM Please respond to "ADSM: Dist Stor Manager" <[EMAIL PROTECTED] .EDU> We do this also put a comment in the CONTACT node field with the date the node can be deleted from TSM, and the ticket number of the request that asked us to retire the node. Richard Rhodes wrote: >"ADSM: Dist Stor Manager" wrote on 05/22/2008 >12:36:11 PM: > > >>3) We put the clients name into a tracking file with the decommission >>date, so we don't forget when 90 days is up. >> >> > >We rename the node with a prefix so decommissioned nodes are easy to spot >in a "q node" listing. We would rename nodeX to zzrt_nodeX. > >We also put a comment in the CONTACT node field with the date the >node can be deleted from TSM, and the ticket number of the request >that asked us to retire the node. > >Once a month someone goes through the TSM servers looking at the >retired nodes and deletes appropriate ones. > > > >- >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. > >
Re: Decommissioned Servers
Richard Rhodes wrote: "ADSM: Dist Stor Manager" wrote on 05/22/2008 12:36:11 PM: 3) We put the clients name into a tracking file with the decommission date, so we don't forget when 90 days is up. We rename the node with a prefix so decommissioned nodes are easy to spot in a "q node" listing. We would rename nodeX to zzrt_nodeX. We also put a comment in the CONTACT node field with the date the node can be deleted from TSM, and the ticket number of the request that asked us to retire the node. Once a month someone goes through the TSM servers looking at the retired nodes and deletes appropriate ones. We do something similar with filespaces. We often are migrating to new storage and have both new and old filesystems setup and backed up. When we decommission the old storage, we'll append _old to the filespace. We then have blanket tolerances in our monitoring system for anything that ends in _old, so we don't get alerts when it's no longer being backed up. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- Foege Building S048, (206)-685-7354 -- University of Washington School of Medicine
Re: Decommissioned Servers
We do this also put a comment in the CONTACT node field with the date the node can be deleted from TSM, and the ticket number of the request that asked us to retire the node. Richard Rhodes wrote: "ADSM: Dist Stor Manager" wrote on 05/22/2008 12:36:11 PM: 3) We put the clients name into a tracking file with the decommission date, so we don't forget when 90 days is up. We rename the node with a prefix so decommissioned nodes are easy to spot in a "q node" listing. We would rename nodeX to zzrt_nodeX. We also put a comment in the CONTACT node field with the date the node can be deleted from TSM, and the ticket number of the request that asked us to retire the node. Once a month someone goes through the TSM servers looking at the retired nodes and deletes appropriate ones. - 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.
Re: Decommissioned Servers
"ADSM: Dist Stor Manager" wrote on 05/22/2008 12:36:11 PM: > > 3) We put the clients name into a tracking file with the decommission > date, so we don't forget when 90 days is up. We rename the node with a prefix so decommissioned nodes are easy to spot in a "q node" listing. We would rename nodeX to zzrt_nodeX. We also put a comment in the CONTACT node field with the date the node can be deleted from TSM, and the ticket number of the request that asked us to retire the node. Once a month someone goes through the TSM servers looking at the retired nodes and deletes appropriate ones. - 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.
Re: Decommissioned Servers
Perhaps our situation is a little different than others, but our concern when a server is decommissioned is that somebody is going to come looking for that data, sometimes weeks later. It has happened before. Sometimes we have decommissioned a server, and an urgent request has come in to do a complete restore of a server the next day. (Craze I know, but sometimes communications fall through the cracks in a large company.) We have a policy to keep client data for 90 days after the server has been decommissioned. One thing we DON'T want to do is have the active files become inactive, or have the inactive versions deleted. One of the previous responders in this thread said to just stop backing the client up, and "do nothing", because the data will still be retained. That will be true of the active version of the files, but the inactive versions will still expire as time goes by. After a couple of months only the active version will be left. While that might be OK, we know from experience that during the last days of the life of a server, data may be deleted or moved around, files may be open, or whatever, and the last backup performed may not be the one the customer wants restored. To us it is worth it to retain the inactive versions, too, so the customer can do a point-in-time restore. Our routine is: 1) We move the client to a special policy domain called "DECOM". This policy specifies 90 day retention of all versions. It also specifies copymode=absolute. 2) We then launch one more immediate backup. Because of copymode=absolute it is essentially a full backup. That gets all the active versions of the data onto the same media, so if anybody asks for a full restore we can do it quickly. 3) We put the clients name into a tracking file with the decommission date, so we don't forget when 90 days is up. 4) When 90 days is up, we delete all the filespaces for the client, then the client itself. If anyone sees a flaw in this scheme please let us know. Best Regards, John D. Schneider Email: [EMAIL PROTECTED] -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Richard Sims Sent: Thursday, May 22, 2008 9:53 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Decommissioned Servers On May 22, 2008, at 9:59 AM, Wimprine, Thomas wrote: > I have a system(s) that have been turned off never to return. I need > to set the backup data that was on them to inactive. Does anyone know > how to make this happen? ... One way is to perform a backup of a same-named, empty file system (which is easy to set up, a number of ways) on a same-type node which masquerades as the original node via Virtualnodename. Richard Sims This e-mail contains information which (a) may be PROPRIETARY IN NATURE OR OTHERWISE PROTECTED BY LAW FROM DISCLOSURE, and (b) is intended only for the use of the addressee(s) named above. If you are not the addressee, or the person responsible for delivering this to the addressee(s), you are notified that reading, copying or distributing this e-mail is prohibited. If you have received this e-mail in error, please contact the sender immediately.
Re: Decommissioned Servers
On May 22, 2008, at 9:59 AM, Wimprine, Thomas wrote: I have a system(s) that have been turned off never to return. I need to set the backup data that was on them to inactive. Does anyone know how to make this happen? ... One way is to perform a backup of a same-named, empty file system (which is easy to set up, a number of ways) on a same-type node which masquerades as the original node via Virtualnodename. Richard Sims
Re: Decommissioned Servers
YeahThat's my thinking on this type of situation also. David Longo wrote: Depends on what you mean. 1. You wan to delete all the backup data as no longer needed. Run on TSM server "Del filespace" for that node and that will delete ALL the data for it. 2. Want to keep the data for some period of time. Do nothing. A node that is no longer backed up will stay in its last state. Then when you are finally ready to delete data, do number 1 above. David Longo "Wimprine, Thomas" <[EMAIL PROTECTED]> 5/22/2008 9:59 AM >>> I have a system(s) that have been turned off never to return. I need to set the backup data that was on them to inactive. Does anyone know how to make this happen? I looked on infocenter and couldn't find anything relevant, am I blind or it just isn't there? Thanks Thomas # This message is for the named person's use only. It may contain private, proprietary, or legally privileged information. No privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. #
Re: Decommissioned Servers
Wimprine, Thomas wrote: I have a system(s) that have been turned off never to return. I need to set the backup data that was on them to inactive. Does anyone know how to make this happen? I looked on infocenter and couldn't find anything relevant, am I blind or it just isn't there? We've approached this problem in two ways. One is to mark all the data inactive before decommissioning the client. We do this by putting "exclude /.../*" in the system options file, and then running a full incremental backup. Sometimes we forget to do this, so we use our monitoring system to remind us to remove the files after their retention period is up. We've setup our monitoring system to alert us if any filespaces haven't been backed up in a certain number of days. By default this is one day, but we can define tolerances on a per filespace basis. We set the tolerance on those filespaces to be equal to the longest retention period for files on that filespace, and will delete the filespaces when we get the email. -- -- Skylar Thompson ([EMAIL PROTECTED]) -- Genome Sciences Department, System Administrator -- Foege Building S048, (206)-685-7354 -- University of Washington School of Medicine
Re: Decommissioned Servers
Depends on what you mean. 1. You wan to delete all the backup data as no longer needed. Run on TSM server "Del filespace" for that node and that will delete ALL the data for it. 2. Want to keep the data for some period of time. Do nothing. A node that is no longer backed up will stay in its last state. Then when you are finally ready to delete data, do number 1 above. David Longo >>> "Wimprine, Thomas" <[EMAIL PROTECTED]> 5/22/2008 9:59 AM >>> I have a system(s) that have been turned off never to return. I need to set the backup data that was on them to inactive. Does anyone know how to make this happen? I looked on infocenter and couldn't find anything relevant, am I blind or it just isn't there? Thanks Thomas # This message is for the named person's use only. It may contain private, proprietary, or legally privileged information. No privilege is waived or lost by any mistransmission. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it, and notify the sender. You must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message if you are not the intended recipient. Health First reserves the right to monitor all e-mail communications through its networks. Any views or opinions expressed in this message are solely those of the individual sender, except (1) where the message states such views or opinions are on behalf of a particular entity; and (2) the sender is authorized by the entity to give such views or opinions. #
Decommissioned Servers
I have a system(s) that have been turned off never to return. I need to set the backup data that was on them to inactive. Does anyone know how to make this happen? I looked on infocenter and couldn't find anything relevant, am I blind or it just isn't there? Thanks Thomas
