Re: To Backup or Not to Backup Data - That is the question
On Fri, 31 May 2013 20:09:33 -0500, Mike Schwab wrote: We don't have enough DASD at the hot site for that. You don't have enough DASD at your hot site to run the business? Then what is it good for? -- Tom Marchant On Thu, May 30, 2013 at 7:44 PM, Jeffery Swagger wrote: Yes, this! Prereq: The company must have a DR manager of which one of his responsibilities is to ensure the families of those who leave are taken care of. Here I'm thinking of natural disasters like hurricanes. Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
It is enough to get Tier 0, 1, and some 2 going. Then wait for more dasd to be installed and raise the CPU limits when we need it. On Mon, Jun 3, 2013 at 9:35 AM, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Fri, 31 May 2013 20:09:33 -0500, Mike Schwab wrote: We don't have enough DASD at the hot site for that. You don't have enough DASD at your hot site to run the business? Then what is it good for? -- Tom Marchant -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Walt Farrell wrote: Or human disasters, Tom. Someone deletes a data set, and because the DASD is mirrored everywhere, all your online copies are gone instantly. Oh, and if you didn't have any real backup copies of the DASD, then all copies of that data set are gone. The same goes for peer to peer tapes too. I have a hard time to convince my management and storage guys that I really need a SECOND set of SMF data. One set to do write and if RC=00 everywhere, repeat on second SMF set. This is because when we get a channel error resulting in 613 abend or so, every errors and halfwritten records written on the local site are also repeated at the other site. I then sit with two sets of useless SMF data residing at 2 sites. I made a breakthrough when I asked them to switch off local tapes so I can reread my SMF tapes from remote site to prove that the second set at remote site are ALSO damaged. Then only they see the need for duplicate SMF tapes. I got my extra SMF tapes with recovery procedures simplified. ;-) Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
On Thu, 30 May 2013 19:09:57 -0500, Walt Farrell walt.farr...@gmail.com wrote: That's one reason that IBM recommends using RACF's duplexing of it's database, rather than depending on hardware mirror copies, and also recommend taking nightly backups of the database. When an administrator makes a mistake it can save a lot of hassle. And, if RACF itself makes a mistake, there's a good chance that only the primary (or the duplex) copy will be damaged. But if you were depending on the hardware mirroring they're all broken. H. Maybe. We once had a situation where a test system IPL failed. Looked like MCAT. All systems active on the same shared MCAT were o.k. Tried another system - IPL failed. Same at secondary and tertiary sites. Crit1 - we couldn't have any production system fail, because it looked like we couldn't bring it back up. Anywhere. After some SADump analysis by ISC it turned out the MCAT was o.k, but the environment was compromised due to LE issue in the linklist (LPA maybe) - was back in 2.10 - z/OS 1.1 so-called LE upward compatibility feature rollout ... :(. So all that good intent may go down the toilet for no obvious reason. I'm sure RACF or any other component can be an innocent victim as much as MCAT. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
W dniu 2013-05-30 20:44, Lizette Koehler pisze: 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. Currently I have the following processes in Place. Any suggestions or guidelines for this analysis will be appreciated. 2 EMC VMAX arrays (could be Hitachi or IBM). 2 Geographically dispersed Data Centers (one VMAX in each) So in my hypothetical setup I have Prod VMAX is Snapping my Prod data within the VMAX Prod VMAX is Replicating to the Secondary (Dev and Text) VMAX (SRDF/A) My Secondary VMAX (Dev and Test) is Snapping the Replicated data I have weekly backups to Tape I have DFHSM doing backups/ML2 tapes are shipped to secondary site. So do I have overkill? . As usual, we should stat from the basics: - budget constraints - business needs - RTO, RPO - uwanted events: disaster, HW failure, SW error, human mistake, other (human/terrorist attack, whatever) - coincidence of events, disaster diameter (area affected) - staffing - other systems (there are no mainframe-only shops nowadays) IMHO in case of 2 datacenters the reasonable scenario should look like: - 2 VMAXes with SRDF/S or /A (matter of distance, performance needs and disaster diameter) - 2 tape systems, one per datacenter, all tapes duplicated (offline copy for human and SW errors, number of copies/generations depends) -- Radoslaw Skorupka Lodz, Poland -- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2013 r. kapita zakadowy BRE Banku SA (w caoci wpacony) wynosi 168.555.904 zotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Agreed! snip Yes, this! Prereq: The company must have a DR manager of which one of his responsibilities is to ensure the families of those who leave are taken care of. Here I'm thinking of natural disasters like hurricanes. Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? Staller, Allan said the following on 5/30/2013 3:09 PM: 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. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Staller, Allan wrote: Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? Zero! [1] You're dreaming, but do this 'change /week/weekend/' and ask again for better answers. ;-) :-D;-D:-D Groete / Greetings Elardus Engelbrecht [1] - It is already hard to get ALL your users AND network staff to co-operate for ONE day / FEW hours of DR exercise without customers having to moan... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Makes for a more realistic test. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Friday, May 31, 2013 12:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To Backup or Not to Backup Data - That is the question Alan, In a company I worked for they would have shot the people, Crazy company. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
In a company I worked for they would have shot the people, Crazy company Makes for a more realistic test. An interesting business model, with certain historical precedents. “Depend upon it, sir, when a man knows he is to be hanged in a fortnight, it concentrates his mind wonderfully.” [Dr. Samuel Johnson] “… it is a good thing to kill an admiral from time to time to encourage the others. ” [Voltaire] Bill Fairchild Franklin, TN - Original Message - From: Charles Mills charl...@mcn.org To: IBM-MAIN@LISTSERV.UA.EDU Sent: Friday, May 31, 2013 8:22:59 AM Subject: Re: To Backup or Not to Backup Data - That is the question Makes for a more realistic test. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Ed Gould Sent: Friday, May 31, 2013 12:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To Backup or Not to Backup Data - That is the question Alan, In a company I worked for they would have shot the people, Crazy company -- 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
Re: To Backup or Not to Backup Data - That is the question
W dniu 2013-05-31 14:57, Elardus Engelbrecht pisze: Staller, Allan wrote: Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? Zero! [1] You're dreaming, but do this 'change /week/weekend/' and ask again for better answers. ;-) Not true. I know company which do this on schedule. Actually the best solution is it doesn't matter which of ours dataceneters is primary. And the difference between good DR scenario and the above is matter of organization, not technology solutions. -- Radoslaw Skorupka Lodz, Poland -- Treść tej wiadomości może zawierać informacje prawnie chronione Banku przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne działanie o podobnym charakterze jest prawnie zabronione i może być karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorised to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. BRE Bank SA, 00-950 Warszawa, ul. Senatorska 18, tel. +48 (22) 829 00 00, fax +48 (22) 829 00 33, www.brebank.pl, e-mail: i...@brebank.pl Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców KRS 025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2013 r. kapitał zakładowy BRE Banku SA (w całości wpłacony) wynosi 168.555.904 złotych. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
In 3d746.4478793e.3ed90...@aol.com, on 05/30/2013 at 03:25 PM, Ed Finnell efinnel...@aol.com said: Wish we had a Cloud! Be careful what you wish for; you might get it. I suggest that you consult your legal staff about the ownership of your data before putting the family jewels in someone else's hands. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
In f66e9ee737492b448738e797fdb828ed1d225...@kbmexmbxpr02.kbm1.loc, on 05/30/2013 at 07:09 PM, Staller, Allan allan.stal...@kbmg.com said: 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. When NSF did that they also pulled a few tapes. These are lost/unreadble. -- Shmuel (Seymour J.) Metz, SysProg and JOAT Atid/2http://patriot.net/~shmuel We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
These have been great points. So to summarize. For Mainframe 1) Plan for both OR/BC and DR conditions. This includes testing as often as the company allows. Paper tests only satisfy a minimal requirement but does not show the plan will actually work or how long the plan will take to get the systems back up. 2) Replication is great unless there is data corruption. 3) DFHSM Backup/Dumps could be a good supplement to protect against data corruption (Multiple Gens for critical files) 4) Tape is excellent for offsite storage in case there is not a secondary DR site owned by the business 5) Make sure not only critical application/system files are there at the DR site, but also include things like SMF data, LOGREC, DCOLLECT, and other miscellaneous but not often thought of files. Depending on where these files are located (DASD vs. DISK) you may be okay. 6) No plan is foolproof. 7) The company would benefit from having a full time VP of DR. (Or some high position). Assigning this process to a Supervisor of Operations probably will not be sufficient as they are very busy with day to day chores. I have seen that some of the management teams that are responsible for Storage (which might be both Open Systems and Mainframe) think that both areas can use a similar type of DR or OR/BC plan. I can see some overlap, but I do believe the way the Mainframe does backup and recovery for these areas is different than a midrange or open systems backup and recovery. So when management starts reading all of these DR or OR/BC papers by Symantec or Dell or other vendors, they start to think the Mainframe is the same. This discussion is helping to show how these functions are different. Did I miss anything? Thanks. Lizette -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Marchant Sent: Thursday, May 30, 2013 2:16 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To Backup or Not to Backup Data - That is the question On Thu, 30 May 2013 11:44:32 -0700, Lizette Koehler wrote: So do I have overkill? . Software disasters can be the hardest ones to plan for. What do you do if one of your critical applications has a program change that causes it to start corrupting data? How long will it take before it is noticed? This can be a lot harder than a hardware failure. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
SHARE is a valuable resource of 'what I missed'. My fave was the Fat boys tried to plug a three phase printer into a 43xx. Blew the T05 cans out of the socket boards! In a message dated 5/31/2013 9:43:19 A.M. Central Daylight Time, stars...@mindspring.com writes: vendors, they start to think the Mainframe is the same. This discussion is helping to show how these functions are different. Did I miss anything? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Any presentations on the Hurricane Katrina scenarios? One company shut down their Miami data center and transferred operations to New Orleans. 3 days later Miami was still without power and New Orleans shut down. On Thu, May 30, 2013 at 3:03 PM, Ed Finnell efinnel...@aol.com wrote: There were several Chicago stories at SHARE and others. Still remember the Ryder presentation after Hurricane Andrew. They even had 'Helper' teams for families that had damage or were displaced. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
We don't have enough DASD at the hot site for that. On Thu, May 30, 2013 at 7:44 PM, Jeffery Swagger jeff...@comcast.net wrote: Yes, this! Prereq: The company must have a DR manager of which one of his responsibilities is to ensure the families of those who leave are taken care of. Here I'm thinking of natural disasters like hurricanes. Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? -- Jeff -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
There was a big lesson, probably already told here. A bank had a back-up site in Denver. Everything moved smoothly, except one overlooked detail. The people involved in the DR, had cell phones with New Orleans area codes. The C/O was under 30-50 feet of water. No calls in or out. It was written up in Disaster Recovery Magazine. It's the unforeseen that crunches you in the butt! Nobody even thought about it until Katrina. Your technical plan may be perfect; it can all fall apart on people and logistical problems. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Mike Schwab mike.a.sch...@gmail.com Sender: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Date: Fri, 31 May 2013 20:07:31 To: IBM-MAIN@LISTSERV.UA.EDU Reply-To: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU Subject: Re: To Backup or Not to Backup Data - That is the question Any presentations on the Hurricane Katrina scenarios? One company shut down their Miami data center and transferred operations to New Orleans. 3 days later Miami was still without power and New Orleans shut down. On Thu, May 30, 2013 at 3:03 PM, Ed Finnell efinnel...@aol.com wrote: There were several Chicago stories at SHARE and others. Still remember the Ryder presentation after Hurricane Andrew. They even had 'Helper' teams for families that had damage or were displaced. -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- 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
To Backup or Not to Backup Data - That is the question
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. Currently I have the following processes in Place. Any suggestions or guidelines for this analysis will be appreciated. 2 EMC VMAX arrays (could be Hitachi or IBM). 2 Geographically dispersed Data Centers (one VMAX in each) So in my hypothetical setup I have Prod VMAX is Snapping my Prod data within the VMAX Prod VMAX is Replicating to the Secondary (Dev and Text) VMAX (SRDF/A) My Secondary VMAX (Dev and Test) is Snapping the Replicated data I have weekly backups to Tape I have DFHSM doing backups/ML2 tapes are shipped to secondary site. So do I have overkill? . With the stability of the EMC VMAX I am not sure I would need 3-6 copies of data I am not sure that the weekly backups are required with this configuration The main intent was to ensure if there was corrupted data, there would be a copy of the data that might not be corrupted somewhere. So, the questions What do you do for your shops for DR and OR/BC (Operational Recovery/Business Continuity). How do you ensure you have a prior copy of data in-case of corruption? How to you plan for a DR TEST vs. a True DR condition? How do you handle your DB2/IMS/CICS databases for transition during DR TEST or REAL event? And how often do you do a DR test (Paper or validation IPL? How do you know if you are taking to many backups (for the Just IN Case issue) that is just stealing cycles from valid workload? Do your DBAs take their own backups, and how do you ensure that you are not overlapping with them? I am not going to ask about the infrastructure (VTAM, Servers, Network backbone, DNS connections) I think that is too much to deal with. Not all shops have this configuration, so I am looking for general guidelines (and I have been reading white papers on DR until my head spins). Until I there is a failure -it is not clear if a proper and efficient Backup/DR Plan that will cover a majority of managements concerns. And all of the tapes that are shipped offsite are encrypted, so another layer to deal with. Any thoughts or considerations. Thanks Everyone in advance. Lizette -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
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
Re: To Backup or Not to Backup Data - That is the question
Yeah after losing a data center and DR to Semtek it changes your perspective. Wish we had a Cloud! Well the tertiary cold site kicked in and they were back on the air in about a week. YMMV... In a message dated 5/30/2013 2:09:46 P.M. Central Daylight Time, allan.stal...@kbmg.com writes: 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
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
Re: To Backup or Not to Backup Data - That is the question
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
Re: To Backup or Not to Backup Data - That is the question
There were several Chicago stories at SHARE and others. Still remember the Ryder presentation after Hurricane Andrew. They even had 'Helper' teams for families that had damage or were displaced. In a message dated 5/30/2013 2:52:55 P.M. Central Daylight Time, wdri...@us.ibm.com writes: 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
On Thu, 30 May 2013 11:44:32 -0700, Lizette Koehler wrote: So do I have overkill? . Software disasters can be the hardest ones to plan for. What do you do if one of your critical applications has a program change that causes it to start corrupting data? How long will it take before it is noticed? This can be a lot harder than a hardware failure. -- Tom Marchant -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
On Thu, 30 May 2013 16:15:42 -0500, Tom Marchant m42tom-ibmm...@yahoo.com wrote: On Thu, 30 May 2013 11:44:32 -0700, Lizette Koehler wrote: So do I have overkill? . Software disasters can be the hardest ones to plan for. What do you do if one of your critical applications has a program change that causes it to start corrupting data? How long will it take before it is noticed? This can be a lot harder than a hardware failure. Or human disasters, Tom. Someone deletes a data set, and because the DASD is mirrored everywhere, all your online copies are gone instantly. Oh, and if you didn't have any real backup copies of the DASD, then all copies of that data set are gone. That's one reason that IBM recommends using RACF's duplexing of it's database, rather than depending on hardware mirror copies, and also recommend taking nightly backups of the database. When an administrator makes a mistake it can save a lot of hassle. And, if RACF itself makes a mistake, there's a good chance that only the primary (or the duplex) copy will be damaged. But if you were depending on the hardware mirroring they're all broken. -- Walt (former RACF Designer) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Yes, this! Prereq: The company must have a DR manager of which one of his responsibilities is to ensure the families of those who leave are taken care of. Here I'm thinking of natural disasters like hurricanes. Second: A real DR test would include actually running the business from the DR site for at least a week and then *bringing it back home*. How many institutions have actually tried that? -- Jeff Staller, Allan said the following on 5/30/2013 3:09 PM: 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. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: To Backup or Not to Backup Data - That is the question
Alan, In a company I worked for they would have shot the people, Crazy company. Ed On May 30, 2013, at 2:09 PM, Staller, Allan wrote: -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
