How best to implement a Disaster Recovery Site


I have been asked to set up a disaster recovery site for my work and would like to talk through the different options available with some experts. We are wanting the DR site to be in as near to ready state as possible without over the top spending (realising that in the event of a disaster, it will take our staff time to move to the new building and get themselves sorted out)

I am planning on having two Global Domain controllers at our main site with an Exchange box (all on Win 2003) and 1 Global DC at the remote site with another Exchange box. We are only a small company with 12 members of staff,

We will connect the two sites via a site-site VPN and do daily backups of data from our SAN snapshot at the main site to the NAS at the remote site. To start with this will be via tape, but ultimately we would like unattended backup via the vpn.

What worries me most is the Exchange servers. I take it I can't have them both online at the same time with identical data/mailboxes and am prepared to take over a tape in the event of a disaster. But what is the best way of doing this and how do other people deal with the MX records pointing to these servers? Currently our main MX record held by our ISP points to main site Exchange and the second MX record points to the ISP's server. In the past when we have had problems with our leased line, their server takes over and then pushes mail over to us when we are back up again.


Who is Participating?
JasonLattinConnect With a Mentor Commented:
For our exchange server we use an application called Double Take.

It allows us to have our main exchange server up and have it replicated real time to our disaster recovery site.  You can have it configured to ping the main server, and if the ping does not respond, have it take over exchange responsibilities.  Or you can have it be a manual process where you can tell it when to take over.  We have tested this out in house and it works great.  We actually have real time replication on site as well, so that if we just have hardware issues, the in house replication server can take over.  Then when we fix the main server, it can fail back to the main server.  It also does DNS updates, to update your records on your internal DNS servers for traffic looking for the main server to be directed to the replication server.  As for the MX records for the disaster recovery site, we use MX Logic for filtering our SPAM emails.  Our ISP points to MX Logic.  MX Logic is configured to point to our servers.  We are able to go to MX Logic site and change the IP addresses to our public site, with about a 10 minute turn around time.  

Here are some more links that might help.

Microsoft guide to Exchange DR...

Disaster Recovery from

Petri's site is FULL of helpful Exchange info. I have referred to some of his information a few times over the last few weeks and one of their "how-To's" even got me through an issue that I couldn't figure out because Microsoft left out a step in their documents.
averybConnect With a Mentor Commented:
DR Planning is so much fun.  Ugh. The first thing that you might want to rethink is "prepared to take over a tape in the event of a disaster."  Chances are in the event of a disaster, you will not have a tape since the disaster would most likely involve a good bit of destruction to your facility--or you wouldn't need to fail over to the backup site.  To  be honest--the you part of that statement is also questionable.  The plans I'm putting in place for my firm assume I will not be around to execute them.

By Global Domain Controllers, do you mean Global Catalog servers?  If so, then you probably only want one of them per site.  
This link has lots of information about Exchange and Global Catalog servers--

Print out, so you can have your remote DC seize all the FSMO roles.  Start a DR Procedure Manual Binder.  Store it at the remote site and have electronic copies available to key personnel as well.  Document every button click.  Times like these, calm, collected thinking can be hard to come by.

Depending on how secure things are at the backup site, you might want to consider moving your primary Exchange server to the backup site.  You're still connecting to it over a secure link.  If the bandwidth is there, then that could be a good solution.  You don't need to worry about Exchange recovery since the server was untouched by the disaster.  Obviously you'd have to be prepared to conduct an Exchange recovery in case the backup site was destroyed.

Document any steps necessary to get your Exchange server at the backup site and your ISP talking and add it to your binder.

Your backup plans leave you exposed for up to 24 hours.  If your backup runs at midnight, and your primary site goes belly up at 11:59 pm then you loose an entire day of data.  You might need to do incremental backups during the day and ftp them or something to the backup site to narrow that window down.

If your primary site went away your ISP would hold the email for you until your secondary Exchange server could download it.  There really isn't a reason to change MX records at your ISP in case of disaster.  That arrangement would work fine for the time being.  People sending you email would know nothing of your problems.  

Can't help on the exchange specific issues.
LetterpartAuthor Commented:
Thanks for your answers and links guys.

splitting points.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.