ADSM-L

Re: [ADSM-L] Decommission Procedure

2008-09-23 12:34:43
Subject: Re: [ADSM-L] Decommission Procedure
From: "Schneider, John" <John.Schneider AT MERCY DOT NET>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 23 Sep 2008 11:33:13 -0500
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:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Timothy Hughes
Sent: Tuesday, September 23, 2008 10:23 AM
To: ADSM-L AT VM.MARIST DOT 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
><rrhodes AT firstenergycorp DOT com> 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
>>            <shawn.drew@AMERI
>>            CAS.BNPPARIBAS.CO
To
>>            M>                        ADSM-L AT VM.MARIST DOT 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.

<Prev in Thread] Current Thread [Next in Thread>