Ohhhhhhhh, let's just "cut to the chase". Forget tape, forget disk, forget DR.
Just buy Business Continuity Insurance then if all is lost you just collect. Of course, this assumes your insurer has not also experienced the same interruption. or worse still that you are not so big that you trigger another financial collapse. But don't worry there is always the bail out.. No, this is not a political comment. On Fri, Jun 25, 2010 at 9:34 AM, Scott Rowe <scott.r...@joann.com> wrote: > We do DR restore from tape, and we restore over 20TB of data in < 12 > hours using 8 3592-E06 drives. After I have all the mainframe data > restored I get to wait for another day or two for the rest of the > platforms to be ready to go. > > >>> R.S. <r.skoru...@bremultibank.com.pl> 6/25/2010 5:47 AM >>> > Joel C. Ewing pisze: > > On 06/23/2010 02:56 AM, R.S. wrote: > >> Schwarz, Barry A pisze: > >>> Doesn't anyone exercise the DR plan anymore? If so, without > reading > >>> the backups? > [...] > > Yes, really! PTAM to a remote secure vault, for transfer to > appropriate > > DR site in event of a disaster. > > Provocation succesful! <g> > > > > We would never consider using mass tape restores with only DFSMShsm > or > > DB2 Utility facilities, as that WOULD take days. Generating > full-volume > > DR dumps with FlashCopy for later staging to 3590-H carts involves a > > system disruption of only a few seconds, and restoring all the 100's > of > > DASD volumes at DR from 3590-H drives with DASD and tape under FICON > > channels takes about 2 hours - and we then get to do some > administrative > > tasks and twiddle our thumbs waiting on availability of the > > non-mainframe servers. > 2 hours ? Maybe in your case. > Let's do the math: 3592J1A drive, speed approx 30MB/s. You need 2 hours > > to restore 216000 MB. 20 hours to restore 2TB, 200 hours to restore > 20TB. You can divide the time by the number of drives, but it does NOT > > scale linearly. > So, for 20TB and 4 tape drives you can assume 50 hours. > Not to mention that: > a) your scenario requires short outage - unacceptable for many > businesses open "24x7x365". Even if you do "setlog suspend-resume" > method. YMMV. > b) Flashcopy DOES AFFECT performance. It can be unacceptable, YMMV. > > BTW: There are other PiT methods which allow make consistent copy > without any disruption. > > > > It all depends on the nature of your business, > OF COURSE! > It also depends on the budget your business is willing to spend on DR > scenario. IT responsibility is to honestly inform what they can get for > > such scenario and what can be done after spending additional money. > > -- > Radoslaw Skorupka > Lodz, Poland > > > -- > BRE Bank SA > ul. Senatorska 18 > 00-950 Warszawa > www.brebank.pl > > Sd Rejonowy dla m. st. Warszawy > XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, > nr rejestru przedsibiorców KRS 0000025237 > NIP: 526-021-50-88 > Wedug stanu na dzie 01.01.2009 r. kapita zakadowy BRE Banku SA (w caoci > wpacony) wynosi 118.763.528 zotych. W zwizku z realizacj warunkowego > podwyszenia kapitau zakadowego, na podstawie uchway XXI WZ z dnia 16 > marca 2008r., oraz uchway XVI NWZ z dnia 27 padziernika 2008r., moe ulec > podwyszeniu do kwoty 123.763.528 z. Akcje w podwyszonym kapitale > zakadowym BRE Banku SA bd w caoci opacone. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > > > > CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains > confidential and privileged information intended only for the addressee. > If you are not the intended recipient, please be advised that you have > received this material in error and that any forwarding, copying, > printing, distribution, use or disclosure of the material is strictly > prohibited. If you have received this material in error, please (i) do > not read it, (ii) reply to the sender that you received the message in > error, and (iii) erase or destroy the material. Emails are not secure > and can be intercepted, amended, lost or destroyed, or contain viruses. > You are deemed to have accepted these risks if you communicate with us > by email. Thank you. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- George Henke (C) 845 401 5614 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
