Step 6: Run the first backup.
Active Directory (AD) is one of the most critical component of any IT infrastructure. In a Windows-based environment, almost all the applications and tools are integrated with Active Directory for authentication, directory browsing, and single sign-on.
Due to this heavy dependency, it is necessary to have a well-defined process for AD Backup.
In this article, we will discuss all the important points regarding Active Directory Backup. We will also see how to automate the AD Backup through a scheduled task.
Restoring Active Directory Backup should be the LAST option for any Disaster Recovery.
For a single Domain Controller failure, the recommended option is to demote the Domain Controller, wait for few hours to replicate the demotion, and then promote it back again.
There is no need to restore Active Directory Backup to restore/recover a single Domain Controller. Active Directory backup restoration is required only when the AD Database needs to be recovered/restored for some reason.
Do not restore Active Directory backup to recover deleted objects. We strongly recommend to enable AD Recycle Bin and use that feature for object level recovery, rather than restoring AD Backup.
Our first goal is to create an effective Active Directory Backup Policy. The backup policy would define the backup approach, tool, frequency, backup location and many other important points.
The most common and recommended approach for AD Backup is the System State Backup of Domain Controller.
Active Directory Database and related files.
Call Registration database of Component Service.
There are many third party tools available in the market for backing up and restoring Active Directory. However, the Windows Server Backup (WBADMIN) tool that comes bundled with all versions of Windows Servers is just fine for this purpose.
In this article, we will discuss the WBADMIN tool that comes bundled with Windows Server 2012 R2. In this edition, the WBADMIN tool is equipped with some great features which we will discuss in the upcoming sections.
We strongly recommend the daily backup. In an enterprise environment where data changes in every second, restoring an old backup does not make sense.
Moreover, Microsoft recommends that: “Any backup older than the tombstone lifetime set in Active Directory is not a good backup.“.
For a large enterprise, we strongly recommend to take System State Backup twice a day. Windows Server backup tools take incremental backup, so disk space is not a big concern here.
Please note that in a multi domain forest, every Domain needs to be backed up separately. This is because there are few partitions which are different for every Domain, like Domain Partition and DomainDnsZone partition.
Microsoft recommends to take backup of at least two Domain Controllers for each Domain, and one of those two Domain Controllers should be the Operation Master role holder. However, Microsoft does not recommend restoring a Domain Controller which is holding the RID Master role. This is to avoid any future RID block conflict.
Based on the Microsoft recommendation, we have decided to configure backup in two Domain Controllers in each Domain, which are in different geographical locations and far from each other. This will offer better redundancy and we will schedule the backup in such a way that both Domain Controllers will be backed up in different point of time.
Once the System State Backup is scheduled through the WBADMIN tool, the first backup will be Full Backup, followed by 14 subsequent incremental backups , and then again another full backup.
First Full Backup > 14 Incremental Backups > 1 Full backup > 14 Incremental Backups > 1 Full backup > 14 Incremental Backups...and so on.
Do not store the backup in a network share. Backup versioning and automatic space management (which we will cover in next section) will not work through a network share.
This is because WBADMIN takes block level backup using VSS, which does not work through SMB.
Always store the backup in a local, non-system volume which is dedicated for storing backup. The local disk can be mounted from SAN or (in case of VM) can come from a datastore, but it has to be mounted in such a way that it is displayed as a locally mounted disk in the Disk Management tool.
As mentioned before, we will not store anything else on that volume. Also, we cannot use System Drive (typically C drive) to store the backup as WBADMIN will not allow storing the backup in system drive.
The disk where the system state backup is stored should be backed up on a regular basis. This will be “Backup of Backup” which ensures availability of backup in case the drive is not available or corrupted.
Windows Server Backup stores backup versions in volume shadow copies. Once the data write is complete, WBADMIN creates a shadow copy of the volume where the backup is stored using Volume Shadow Copy Service (VSS).
This shadow copy retains the Point in time state of the Storage volume where the backup is stored, and each Point in Time State is called a Backup Version.
Backup versioning is one of the most exiting feature of WBADMIN tool. There will be no separate folder for each backup, instead, there will be versioning for each instance of backup.
Every time the backup job is triggered (manually or through scheduled task), a new version is created along with a unique snapshot ID and timestamp.
The command "WBADMIN get versions" will show all the point in time snapshots which are present on that server.
WBADMIN in Windows Server 2012 R2 offers another great feature, which is automatic disk space management.
When we schedule the backup using WBADMIN tool, we do not need to worry about disk space management, and we do not need to delete any backup to accommodate newer backups. This is entirely managed and taken care by the tool, which deletes the oldest backup versions as and when required to manage disk space.
Automatic Disk Management feature does not work when backups are stored in a network share.
The last thing that we have to plan is the Service Account, which will be used to run the scheduled task.
We recommend using built in “NT AUTHORITY\SYSTEM” account. The advantage is we do not need to worry about password management and password expiry. However, this decision depends on organization policy.
If we use any other AD account to run the task, we have to ensure that “Password Never Expires” is enabled, otherwise backup will stop once password will expire.
Now that we have considered all the points, let’s summarize our backup policy. For an organization, it is important to document this backup policy and get a sign off from all key stakeholders.
Where to Store the Backup In a non-system disk, mounted as a local disk. Not in network share.
We have created our backup policy and reviewed it. Now it’s time to implement the backup solution.
We are going to configure it on a Domain Controller DC1.subhro.org. The operating System of the Domain Controller is Windows Server 2012 R2.
We have provisioned a new volume (E:) which is formatted with NTFS. Since this is a test environment, the Disk size is 20 GB. However, for the production environment, we recommend at least 200 GB or higher. Higher disk size would allow number of versions (snapshots) to be stored in the disk.
Go to My Computer > Backup Drive (E: Drive in this case) > Right Click > Properties.
Go to Shadow Copies and select E drive > Properties.
Set the Maximum Size to “No Limit” and save the settings.
Go to Server manager > Add Roles and Features > Features > Windows Server backup.
We should now see the WBADMIN console.
As we can see, there is no backup configured, or no manual backup run on this Domain Controller.
At this stage, if we run the command "WBADMIN get versions", we will see below output that there is no backup version available.
We have the tool and the volume ready, so now let’s configure the scheduled task.
On the right-hand side of the console, click “Backup Schedule”.
Click “Custom” on Backup Configuration.
In the next screen, click on Advanced Settings > VSS Settings.
As we are not using any other third party tool to take AD Backup, select ‘VSS Full backup”.
Select "System State" from the Backup Items list.
Select "Backup to a volume" in the destination type. As discussed, some key features will not work if the destination is a network folder.
A confirmation message will appear if the configuration is successful.
Go to Computer Management (Compmgmt.msc) and open the Task Scheduler.
We should see the scheduled task already created by the WBADMIN wizard, which we ran in the previous section.
Open the Scheduled Task and changed the value of “Configured For” to “Windows Server 2012 R2 , as shown in the below diagram.
We also have to ensure that the task is running under "NT AUTHORITY\SYSTEM" account.
We will run the first backup manually to verify things are working as expected.
To run the scheduled task, we have to enable “Run the Task on Demand” option in the task settings. Once the first backup is complete, we should disable this option so that no one runs it manually.
So we have enabled that option and run the scheduled task. Since this is the first backup and a full backup, it will take some time to complete the backup.
The next backup would be incremental, whether we run it manually or through scheduled task.
Once the next backup is complete, we can check the versions again, and now we should see two versions available created in two different timestamp.
Please note that backups will be stored in Hyper-V Disk (VHDX) format.
Below screenshot captures the version details after 3 runs.
If the value is anything other than this, please correct the value and reboot the Domain Controller. Please take downtime and proper approval before changing the registry values, and please backup the registry before making any change.
Also, sometimes the automatic space management does not work correctly and backup fails due to disk space issue. Generally, a reboot of the Domain Controller solves this problem.
In this article, we have discussed the Active Directory Backup Policy. We have also discussed how to deploy and automate daily System State Backup using Windows native backup tool. As mentioned earlier, restoring AD Backup should be the LAST option in any production environment.
Configuring and automating AD Backup is one part. Another part, which is equally important, is to monitor and ensure that the backup jobs are running as per the schedule, and more importantly, the backup is successful. Unlike the backup configuration, this is not a one-time task but daily or weekly; depending on your backup frequency.
Can we automate this backup monitoring without using any third party tool? Can we receive an email notification after every backup job, indicating the success/failure status of the backup?
The answer is yes, we can automate this without using any additional tool, and using windows native solution.
The solution which I am going to propose here is tested, and we are running this in the production environment for last 1 year. Since then, we have got every single backup success and failure report without any slippage. It saved us a lot of time and effort, and I believe it would save a lot of your effort too, once you implement it.