ADSM-L

Re: To Collate or Not to Collate? - UPDATE

2003-01-15 15:32:04
Subject: Re: To Collate or Not to Collate? - UPDATE
From: "Pearson, Dave" <DCPearson AT SNOPUD DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Wed, 15 Jan 2003 12:30:36 -0800
It depends on the size of  your library too.   We don't Collocate and we had a 
Disaster Recovery test and it was successful.  We had time on our hand too with 
the 36 hours time limits


David C. Pearson
IS Production Support Analyst
System & Network Service
Snohomish County PUD # 1

        -----Original Message-----
        From:   Theresa Sarver [SMTP:tsarver.IFMC AT SDPS DOT ORG]
        Sent:   Wednesday, January 15, 2003 12:25 PM
        To:     ADSM-L AT VM.MARIST DOT EDU
        Subject:        Re: To Collate or Not to Collate? - UPDATE

        Yikes!  Okay, point(s) taken...Copypool set back to collate @ node 
level!  

        Thanks again;
        Theresa

        >>> Rene.Lambelet AT NESTLE DOT COM 01/15/03 02:18PM >>>
        Hi, I fully agree. Specially after the experience of restoring one 
single
        destroyed tape in primary pool that implied mounting 85 copy tapes!!

                        René LAMBELET
                        NESTEC  SA
                        GLOBE - Global Business Excellence
                        Central Support Center
                        Information Technology
                        Av. Nestlé 55  CH-1800 Vevey (Switzerland) 
                        tél +41 (0)21 924 35 43   fax +41 (0)21 703 30 17   
local
        UBS-Nestec, Bussigny
                        mailto:rene.lambelet AT nestle DOT com 

                        This message is intended only for the use of the 
addressee
                and may contain information that is privileged and confidential.


        -----Original Message-----
        From: Cook, Dwight E [mailto:DWIGHT.E.COOK AT SAIC DOT COM] 
        Sent: Wednesday, January 15, 2003 8:05 PM
        To: ADSM-L AT VM.MARIST DOT EDU 
        Subject: Re: To Collate or Not to Collate? - UPDATE


        Allen makes a critical implied statement of YOU MUST TEST YOUR RECOVERY 
PLAN
        !
        If not and you have to use it and it doesn't go smooth...
        Personally, I classify myself as probably being at the lowest place on 
the
        earth... and even if something were to initially miss me, it would
        undoubtedly/eventually settle on top of me! ! !
        So... you request the test and state its requirement as to ensure
        functionality.
        If management says "no", make sure and put together a few things on what
        ~might~ go wrong like potentially 36 hours of nothing but tape mounts &
        dismounts to restore just a single server (if like in Allen's case 
where 800
        tapes were required)
        Then make sure and save all the e-mails (print out and lock in a 
fireproof
        safe) so you can mount a defense later ;-)

        Dwight

        -----Original Message-----
        From: Allen Barth [mailto:allen.barth AT DB DOT COM] 
        Sent: Wednesday, January 15, 2003 12:31 PM
        To: ADSM-L AT VM.MARIST DOT EDU 
        Subject: Re: To Collate or Not to Collate? - UPDATE


        Glad you found it!

        However, regarding the collocation=no issue on copypools....

        Having done TSM DR recoveries at an offsite location a few times, let me
        share my experiences.   When I started with TSM I had one copypool with
        colloc=no.  We then did our first DR recovery test where my goal was to
        recover the TSM server and ONE other AIX client.  The base os (AIX) was 
to
        restored via sysback, user filesystems via TSM.   Originally this 
required
        the ENTIRE copypool (800+ tapes back then) to be sent from the vault to
        the DR location as TSM provides no command to see which vols would be
        needed for a client node restore (hint, hint, IBM).   Since then I've 
been
        able to put an SQL query together to get that info but it takes quite a
        while to execute.  This trims down the number of tapes, but the number 
of
        tapes was still quite large(100 +).  Furthermore, the number of tape 
mount
        requests during the restore was astronomical, as tapes were requested
        multiple times.  After re-thinking TSM and DR needs, I now have a
        separated stgpool tree for unix data.   Collocation is enabled for both
        primary and copypools.  At the last DR test, the number of tapes needed
        from the vault was further reduced to around 40, and the restore process
        took significantly less time.   Let's not forget to factor in the time
        required for physical tape processing (mount delay, seek time, rewind,
        unload).   This can add up to significant wall time.

        Regards,
        Al