Disaster Recovery

Here's a little bit of a brain stretcher for you guys. I've recently had to come up with a network architecture to support a remote disaster recovery site. The company runs several satellite offices plus a main site which are all different IP subnets connected via a routed WAN infrastructure. There are two NetBIOS domains and an Active Directory across the enterprise. Each site has local DHCP and DNS servers but WINS is at the central site only. The main business apps run on dedicated servers at each site.
The disaster recovery site is to be a replica of the main site and the systems there must synchronise with the live systems during standby operation. Should the main site go down, the standby site has to come on-line within four hours and, to the satellite offices, must "look" (in network terms) exactly like the main site did (i.e. no changes required at the offices to continue operations).
I've produced a design that should work - but how would you do it?
(I'm not telling you my solution just yet because I want your unbiased input)

"brain stretcher " I think is an underestimate for this thread!!

Give us some time to think about this one and we'll get back to you .... if there are any hints you can provide ... please feel free to do so !

Cheers,

I thought this thread might provoke some good debate that would bring up many useful points in the time-honoured firewall.cx fashion.
Hints? Well, the IP network to be used at the disaster recovery site is a good place to begin. The disaster site will obviously need to have the same WAN connections into it that the main site has. But should we have it as a different IP network to everywhere else, and so route traffic to it? Or should we go for a 'LAN interconnect' approach with an additional fibre link between the main site and the disaster site so they can be on the same IP subnet?. If we choose the former things seem obvious on the surface but we have a lot of work to do to move from standby operation to live. And if the latter, system synchronisation is easy but how will the WAN work?
As I say, this isn't a problem as such, I posted it to be a thought-provoker so don't lose sleep over it!

Without having more information, I would go for the fiber LAN interconnection personally. I would give the main site's servers aliases on their NIC's for the network between there and the disaster recovery site. Of course, I'm assuming the fiber is already existing between the main site and the remote. If that isn't the case, I'd go for the WAN approach just to save money.

jwj, what do you mean by

I would give the main site's servers aliases on their NIC's for the network between there and the disaster recovery site

.

And Bishop, does the above statement satisfy your question about the WAN working with the LAN interconnect?

And if the latter, system synchronisation is easy but how will the WAN work?

Actually, I'm not really sure what the Bishop was meaning with his remote site, whether it was just for being a backup in case of the failure of the main site, or if it was a functioning all on it's own and happened to also be the backup site. How we do it where I work is the backup site isn't on our regular network, so our servers either have dual NIC's or aliases to send their back-ups to the remote site through a private, flat network. In the case of the total failure of our main site, we'll move to the alternate location where we'll be able to get things running again.

As long as that remote site has connectivity with your other sites, all you really need to do is backup your important servers to that location. I think that's the most important thing.