Implementing Active Directory Disaster recovery with backup recovery domain controllers

While it is important to have a disaster recovery plan that includes programs that prevent replication failures, every domain controller in the core site is not responding, it is difficult to happen. The more common difficulty is due to hard disk crashes, poor network cards, file system degradation, Active Directory degradation, or a variety of minor problems that can cause damage to one domain controller.

So how do you make a disaster recovery plan for a single domain controller failure?

Here are two answers:

1, Restore from backup (note: The Active Directory is in the system state, so the recovery of the system state can also restore the Active Directory).

2, do not restore. Reinstall and then upgrade, or just use the downgrade to upgrade the method.

The first scenario, the recovery from backup, is not as easy as it looks. Although most direct methods are to upgrade domain controller performance as mentioned above, in many cases it is necessary to recover from backups. For example, when you restore a domain or an entire forest that has no active domain controller, you can do this only by restoring the system state controlled by one domain in the domain and then installing the other server and elevating it to a domain controller. There is no need to restore additional domain controllers from backup. In a multiple-domain forest, you must first restore the root domain and then the subdomain. Information about the process, Microsoft has recorded in their white paper: "Best Practices: Active Directory forest Restoration".

When you are recovering from a domain controller from a backup medium, note the following points:

1. Simply restore a single domain controller in each domain (if it is a multiple domain and parent-child structure, start from the root domain). After the first domain controller is restored, the additional domain controller is loaded with DCPROMO.

2. In a real disaster recovery plan, you must realize that recovery is likely to occur on different hard disks rather than on the initial hard drives of backups. See Microsoft KB article 263532: How to perform a disaster recovery for active purposes on a computer with a different hard drive configuration.

3, the backup belt only within 60 days of application, or according to the Tonbstone life cycle value set. (Refer to Microsoft KB216993: Active Directory Backup is valid for 60 days). Make sure you can create and validate backup tapes on a regular basis and save them securely.

4. There is no need to simply restore a domain controller because it usually acts as one or more FSMO roles. These roles can also be assigned to other domain controllers. If you do have a role, the original role winner will no longer exist (clear and reload).

5, in the existing domain, the start of the day, the automatic recovery of a domain controller from backup with the number of days required will make the domain controller obsolete. This can cause synchronization, as the change to replicate increases the time it takes to replicate upgrades, and the impact on the network is greater. This depends on the number of changes caused by the backup band creation.

I have worked with some administrators who intend to recover domain controllers from a backup. Once, two domain controllers failed and could only be recovered at different times through the backup belt. It took us 2 days to get the system back to work, and we did it the same way, by manually demoting the domain controller, cleaning the Active Directory, waiting for replication and then upgrading with the same name. It is worth noting that one of the reasons for demoting and upgrading a domain controller is because replication is not possible. However, if replication is interrupted, it cannot be degraded through DCPROMO. In the March Active Directory Disaster Recovery series, we will learn how to manually demote a domain controller, clean up the Active Directory, and fix some applications that are installed in the domain controller that are having problems during manual demotion, such as exchange.