To have unique server names and IP addresses in secondary dedicated warm site, or not?

245 pts.
Disaster Recovery
IP address
Network design
I'm not sure which is the lesser of two evils. To go with recovery to a secondary site that emulates production (including exact domains, server names and IP addresses), or to have sedcondary site systems that have unique IP addresses and server names all on the same domain. Anyone know of resources available that discuss pros and cons?

Answer Wiki

Thanks. We'll let you know when a new response is added.

It can be tricky to have the same address range across a WAN, in 2 distinct locations.
Will you be recovering ALL your servers in one fell swoop, or possibly just some of them?
Would you then plan to migrate back to the original (or a new) data center, again phased for at once?
Do most things work properly through DNS or WINS, or are there static IP addresses all over system scripts?


Thanks for your reply. Neither of the two possible outcomes would have same IP addresses on a single WAN. We would either have 1) a WAN that had production AND secondary sites for failover when primary site is down, without duplicate IP Addresses, or 2) a WAN for production, and a physically segregated WAN for testing that could mimic production server names and IP addresses.

I keep hearing that we have been following DNS practices but then we run into an instance where there is a IP address imbedded in an application component.

I want the benefit of having a single WAN that all sites can persist on simultaneously, so we can test DR systems on the network we would use at time of disaster, but wish to avoid all the pre-test analysis and preparation that would be required to prevent potential enterprise transaction traffic/file transfers from bleeding from test into production systems.

Does anyone know of any white papers or industry best practices documentation that discusses this issue?


Discuss This Question: 2  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • petkoa
    Hi Mike, May be I'm not understanding what you need to accomplish, but if you have private IPs, you can setup a NAT gate between main and secondary sites and have same IPs in both - the gate will take care to translate IPs when you synchronize sites, or connect from one site to another. About the DNS - if you split internal from external services, I don't see why you'll have any problems with the naming too... If you have real IPs it's also possible to use NAT scenario. You have to make sure, however, that you external DNS can promptly manage to resolve to the new IPs in a case of accident which requires use of the secondary site (or that your ISPs for both sites can promptly arrange the routing change). BR, Petko
    3,140 pointsBadges:
  • Rprg
    I dont know what tecnology you use for replicating data to the remote site,. Supose you have disc mirroring over a WAN to you DR site and you have identical hardware (servers, mainframe) on both sites. With servers booting from the SAN, you'd have identical IPS, DNS names etc on the DR site. If you want to do a full DR test, all that has to be done is to stop the disc replica, enabling the remote discs, isolating the LAN on the DR site and power on the servers. This would enable you to conduct DR tests without impact on production site. When the test is over, powerdown the servers, enable the replica and test is over. This really cuts down recovery time in an emergency and simplifies DR tests. It also allows you to recover a single server or group of servers in case of a failure in production site. RPRG
    10 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: