I have looked at your Backup/Recovery code, quite extensive. 1) With the use of a software encryption product (I think it is currently
called VM/Encrypt, Dave, help), and a modified PIPEDDR, I was able to wri te encrypted backup tapes and restore them at our DR exercise last summer. J ust about when DOE decided on a hardware only solution. 2) So true. I was actually thinking of a PIPEDDR type server to run at bo th sides of a DR connection, that acted like a backup server at production, with scheduled jobs that fired off workers to read each minidisk, full-volume, snapshot volume and send compressed data across the net to t he recovery server at the hotsite which would fire off workers to receive ea ch stream and write the data back to disk. I was thinking of a VM based serv er but it could be a linux server with some VM workers to handle snapshot requests and SVM shutdown/xautolog requests from a linux scheduler. But b oth would require more effort than I can give it. (Anyone got a product development team that needs some work?) /Tom Kern /U.S. Dept of Energy /301-903-2211 On Tue, 17 Jun 2008 12:49:39 -0400, Michael Coffin <[EMAIL PROTECTED] om> wrote: >Hi Tom, > >Yep, I have that all covered. This is actually a DR process that I >developed about 8 years ago (and have been improving over the years) >that is a complete "soup to nuts" system, automating both the backups >AND the recovery. The system assumes a "worst case scenario" where >computer center is gone, and all of the people having detailed knowledge >of the system are likewise "gone", it allows someone with virtually no >knowledge about the specifics of the system being recovered and very >minimal mainframe knowledge to fully recover the system. When we >conduct DR drills we typically recruit a management type that has >minimal computing skills and little specific knowledge about the system >(someone we affectionately refer to as the "monkey boy", with the >understanding that a slightly trained monkey could actually complete >this task) to actually conduct the recovery. The programming staff >provides no input to the "monkey boy", instead taking notes of anything >in the documentation that they found unclear and/or any technical >problems that may arise. The entire process is menu-driven and pretty >slick (including a Recovery Monitor that reports what each DDR slave is >doing, what's it's ETA to completion of the current task is, what the >total ETA to full system recovery is, the ability to quiesce and restart >slaves/streams/devices, etc.). > >In 2006 there was a massive flood in Washington DC that required >implementation of this DR Plan. I'm pleased to say it worked without a >hitch, and from the time we got the green light to start spinning tapes >we were back up in running in something like 3 or 4 hours (I think we >had about 20 DDR slaves running simultaneously). While this process >works extremely well, I now want to remove tapes from the process - >there are a number of reasons why this makes sense: > >1. There is a Federal mandate to encrypt all removable media which this >site is subject to, and we don't presently have TS1120 tape >drives/cartridges. > >2. Tapes can be lost and/or damaged (damage used to happen with >ALARMING frequency!), one bad tape and your entire recovery could be >jeapordized. > >Ultimately, I'd like to have our production DASD replicate (either in >realtime or via a nightly batch job) to a remote DASD array using PPRC - >but until such time as I get funding to do that (perhaps never!) I need >to eliminate the darned tapes. :) > >-Mike
