Tips and Tricks

Domain Controllers and Disaster Recovery

It's really easier than you think.

• By Don Jones
• 09/01/2003

First, keep in mind that every DC has a completely identical copy of the entire AD database. I know, that seems pretty obvious, but it has some subtle implications. Suppose you’re using AD-integrated DNS zones. Every single DC has a copy of the DNS zones, including those DCs that aren’t even running DNS (at least in a 2000 Domain). Because every DC is identical, there’s really no need to back them all up. Even if the worst case occurs—for me, that’d be a meteor hitting my stack of servers—you could just rebuild the DC, promote it to be a domain controller, and it’ll get the AD database from its fellows. Of course, to avoid that meteor scenario, you should make sure that at least a couple of DCs are physically separated. That way, a fire in one data center won’t take out all of your resources.

We know that not all DCs are created equal. Some DCs have those special Flexible Single Master Operations (FSMO) roles, like the PDC Emulator, and some DCs host a replica of the Global Catalog (GC). But even if one of those special DCs crashes, you won’t lose any data so long as at least one other DC exists in the domain. You can transfer or seize FSMO roles and configure an alternate DC to host the GC—any way you slice it, though, you don’t lose any data.

You still need backups, of course. Backups can be used to restore accidentally deleted AD objects, and they’re invaluable for off-site recovery purposes. Several of the companies I work with rent off-site space and have a plan to recreate practically their entire IT infrastructure in that space, in the event that something horrible happens to their main office building. Regular AD backups are critical for these purposes, but there’s no need to make things tough. You really only need to back up a couple of DCs.

I always choose one DC to be my “backup master.” That’s the one on which I perform daily—in some cases, hourly—backups. Use whatever software you like; just make sure you get a good, clean backup on a regular basis. If you need to restore an object like a user or group, your backup will be ready to go. Keep in mind, though, that AD backups can only be used on the DC on which they were created. So, if my backup master experiences a total hardware failure, all of my backups are pretty much useless unless I can fix the problem. Therefore, I always pick a secondary DC, usually one located at a different office or in a different data center, and pull backups of it, too. That way, I’ll always have a DC to use to perform restores.

Off-site recovery presents a stickier problem. The whole point of off-site recovery is that you won’t have any of your regular computers available, meaning your DC backups might not be useful. What I do is pick one DC to be the “off-site master.” Put it on the network every couple of weeks, let it sync up with the rest of the domain, and then make a backup of it. Cart the DC off-site to use in your off-site recovery scenarios. Don’t leave it off the network for more than 60 days, or you’ll run into weird problems related to the way AD handles deleted objects. If you need to resort to your off-site recovery option, the DC should be ready to go and can be used to repopulate as many new DCs as needed off-site.

So don’t waste time trying to pull a backup of every DC you own. Pick a couple in each domain and back them up. Keep some backup tapes off-site for safety and keep some handy for restoring accidentally deleted objects.