We do not have the luxury of using the production IP addresses in the event of a disaster. We will have to use whatever addresses our DR vendor provides just like during a test. The DNS entries will have to be changed for a real disaster, but for testing, we have the testers use the test IP addresses directly. All TCPIP stacks at the DR site are modified to use the vendor IP addresses after we have done the restore, this includes OS/390, z/VM and multiple linux service machines. The same applies to all of the mid-range systems (Sun, RS/6000) and Intel systems.
If your vendor can supply you with your production IP addresses in the event of a real disaster, then you could keep your production and test IP configurations in separate directories in each linux server, then during a test copy the test directory into the /etc/sysconfig/network directory and restart the linux server. If a disaster occurs during your test, you can restore your production IP settings by replacing the test configuration with that safe backup of production settings. If you are not testing with your latest backups, and a disaster strikes in the middle of your test, then you will need to get the latest available backups and do the restore all over again. If you are using your latest backups, just tell your users that you are now the production system. /Tom Kern --- Michael MacIsaac <[EMAIL PROTECTED]> wrote: > Has anyone addressed the issue of how to do a planned DR test? Here are > the assumptions: > -) There is a production z/VM+Linux LPAR at the primary data center. > -) There is a DR site where the production LPAR volumes, etc. are > replicated. > -) A planned DR test is necessary. > > In a real disaster, the DR site will use the same IP/DNS as the production > site which by definition is down. However, to do a planned DR test, > different networking information is required so as to not conflict with > the primary site. So how do you tell: > (1) z/VM - bring up TCPIP with this alternate networking information, and > (2) Each Linux to come up with alternate networking information. > Then the DR site can be tested. > > The contingency of a real disaster occuring during the DR test must be > addressed. At that time the DR test must be abandoned and the DR site must > be brought online with the real network information (so modifying the > Linux networking info in the DR site file systems is not a good option). > > I can see how you can address (1) - maintain a second TCPIP service > machine - say TCPIP2. Bring up z/VM without AUTOLOG and manually bring up > TCPIP2. But how to address (2)? Is anyone doing this? > > "Mike MacIsaac" <[EMAIL PROTECTED]> (845) 433-7061 __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
