Back before I got into the Software industry, I worked for a public utility in Chicago. My first foray into DR was pushing for data-comm fallbacks at our remote sites. At first we got questioned, but finally we got them approved. Then I brought up the "dead pool" test idea, and was laughed at. Well then April 13, 1993 occurred, when the tunnels below the loop flooded, cutting the power to our building. We were able to get our DR system up and running in about 18 hours with the remote locations online within 24 hours. While the network DR was "appreciated" the "dead test" idea wasn't considered for at least 6-8 years, well after I left the company. ============================================== Wayne Driscoll OMEGAMON DB2 L3 Support/Development wdrisco(at)us(dot)ibm(dot)com ==============================================
IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> wrote on 05/30/2013 02:28:44 PM: > From: Charles Mills <charl...@mcn.org> > To: IBM-MAIN@listserv.ua.edu, > Date: 05/30/2013 02:30 PM > Subject: Re: [IBM-MAIN] To Backup or Not to Backup Data - That is the question > Sent by: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> > > You are dead right of course. > > Disasters don't come on schedule, neatly tied up in a bow. > > A good thing might be a brainstorming session on "what are our > implicit disaster-related assumptions?" and then questioning those > assumptions. > > Charles > Composed on a mobile: please excuse my brevity > > "Staller, Allan" <allan.stal...@kbmg.com> wrote: > > >Although very few shops actually do this, IMO the procedure should be: > > > >Management walks in the room and says " You, you, and you are dead > as of "time/date". The rest of you go recover as of that time/date." > >The "dead people" cannot be consulted with during the DR exercise. > "You, you, and you" should be different during each iteration of the test. > >After the fact, procedures/documentation are analyzed and updated > based on the results. > > > >In too many cases, I have seen "staged" recoveries, whereby the > data is all snapshot'ed at the end of a "cycle" and neatly tied up > in a package. > >The same "crew" is used repeatedly and becomes very familiar with > all of the procedures, and actually tests nothing new. > >All that is proven in this case is your applications can run on > other compatible hardware. > > > >I have deliberately ignored the data questions, as your > configuration is nothing like mine. > > > >Just my $0.02 USD worth. > > > >HTH, > > > ><snip> > >I am looking to see how other shops are currently doing Backups for > DR and OR. I think this will be valuable for the archives. > ></snip> > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
