Greetings, We do a couple things that no one else has mentioned:
1) We move the client to a special policy domain called DECOM. This policy domain is set to 90, 90, 90, 90, mode=absolute. The reason is our typical policy domains don't keep very many versions of deleted files, and don't keep them back for very many days. If we didn't change the policy, and the client sat for 30 days without a backup, eventually all but the last active version of the file would expire, in other words, you would have only one version of each file, and that seems dangerous to us. What if the most recent version was corrupt, or wasn't the version that the customer needed to restore? Most customers don't understand the concept of versions; if we say we are keeping a decommissioned client's backups for 30 days, we need to be keeping more than just one version of the files for 30 days. 2) We perform one more backup, to rebind everything to the new policy domain. The reason we force it to be a full (mode=absolute) is so that if a customer needs us to do a full restore on the client, the last backup will most likely be on the same piece of media, and the restore will go more quickly. (We have had a couple situations where a box was decommissioned before everybody was quite finished with it, and it had to be restored in a hurry. Sad but true.) 3) Then we take it out of the schedule, track the date it was decommissioned, etc. like everybody else does. Best Regards, John D. Schneider Sisters of Mercy Health Systems -----Original Message----- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Timothy Hughes Sent: Tuesday, September 23, 2008 10:23 AM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Decommission Procedure We - remove the association - in the Contacts we put the date it was retired, and the date it's backup is to be deleted tim goc wrote: >... and i make a phone call and regardless of the answer i delete everything :-) > >On Tue, Sep 23, 2008 at 1:13 PM, Richard Rhodes ><[EMAIL PROTECTED]> wrote: > > >>We . . . . >>- remove the association >>- rename the node from <node> to zzrt_<node> >>- in the Contacts we put the date it was retired, and the date it to be >>deleted >> >>Once a month we go through the retired nodes and delete those that are >>eligible. >> >>Rick >> >> >> >> >> >> Shawn Drew >> <[EMAIL PROTECTED] >> CAS.BNPPARIBAS.CO To >> M> ADSM-L@VM.MARIST.EDU >> Sent by: "ADSM: cc >> Dist Stor >> Manager" Subject >> <[EMAIL PROTECTED] Decommission Procedure >> .EDU> >> >> >> 09/22/2008 12:17 >> PM >> >> >> Please respond to >> "ADSM: Dist Stor >> Manager" >> <[EMAIL PROTECTED] >> .EDU> >> >> >> >> >> >> >>When a Node is decommissioned we typically >>- lock the node >>- remove it from the schedules >>- A script periodically checks for old file systems (Based on retention) >>and identifies file systems ready to be removed >>- We remove the expired filesystems (and the last active versions) then >>remove the node >> >>Mr Sims recently suggested changing the MAXNUMMP to 0 to allow restores >>but not backups. >> >>What are some other decommission procedures out there? I'm trying to >>find the best way to do this so the decommissioned nodes will be obviously >>distinguishable from the active nodes. >> >>Regards, >>Shawn >>________________________________________________ >>Shawn Drew >> >> >>This message and any attachments (the "message") is intended solely for >>the addressees and is confidential. If you receive this message in error, >>please delete it and immediately notify the sender. Any use not in accord >>with its purpose, any dissemination or disclosure, either whole or partial, >>is prohibited except formal approval. The internet can not guarantee the >>integrity of this message. BNP PARIBAS (and its subsidiaries) shall (will) >>not therefore be liable for the message if modified. Please note that >>certain >>functions and services for BNP Paribas may be performed by BNP Paribas RCC, >>Inc. >> >> >> >>----------------------------------------- >>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. >> >> >> > > > >-- > >Murray Walker - "And now, excuse me while I interrupt myself." > > 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.