Chat now with support
Chat with Support

Recovery Manager for AD Forest Edition 10.3.1 - User Guide

Overview Getting started
Permissions required to use Recovery Manager for Active Directory Recovery Manager Console Getting and using help Configuring Windows Firewall Using Computer Collections Hybrid Recovery with On Demand Recovery Managing Recovery Manager for Active Directory configuration Licensing
Backing up data
Permissions required for the Backup operation Managing Backup Agent Using a least-privileged user account to back up data Using Managed Service Accounts Active Directory backups vs Windows System State backups Creating BMR and Active Directory backups Using the Backup Wizard Retrying backup creation Enabling backup encryption Backing up AD LDS (ADAM) Backing up cross-domain group membership Backing up distributed file system (DFS) data Backup scheduling Setting performance options Setting advanced backup options Using Forest Recovery Agent Unpacking backups Using e-mail notification Viewing backup creation results
Restoring data
Getting started with Active Directory recovery Managing deleted or recycled objects Restoring backed up Active Directory components Integration with Change Auditor for Active Directory Using granular online restore Restoring AD LDS (ADAM) Selectively restoring Active Directory object attributes Restoring objects in an application directory partition Restoring object quotas Restoring cross-domain group membership Performing a restore without having administrator privileges Reports about objects and operations Using complete offline restore Offline restore implications Restoring SYSVOL authoritatively Performing a granular restore of SYSVOL Recovering Group Policy Restoring data from third-party backups Using the Extract Wizard Restoring passwords and SID history
Full Replication Consolidating backup registration data Recovering an Active Directory forest
Forest recovery overview Deploying Recovery Manager for Active Directory Forest Edition (Disaster Recovery Edition) Permissions required to use Forest Recovery Console Forest Recovery Console Managing a recovery project Recovery methods Phased recovery Managing Forest Recovery Agent Rebooting domain controllers manually Resetting DSRM Administrator Password Purging Kerberos Tickets Managing the Global Catalog servers Managing FSMO roles Manage DNS Client Settings Configuring Windows Firewall Developing a custom forest recovery plan Backing up domain controllers Assigning a preferred DNS server during recovery Handling DNS servers during recovery Forest recovery approaches Deciding which backups to use Running custom scripts while recovering a forest Overview of steps to recover a forest Viewing forest recovery progress Viewing recovery plan Viewing a report about forest recovery or verify settings operation Handling failed domain controllers Adding a domain controller to a running recovery operation Selectively recovering domains in a forest Recovering SYSVOL Deleting domains during recovery Resuming an interrupted forest recovery Recovering read-only domain controllers (RODCs) Checking forest health Collecting diagnostic data for technical support
Using Management Shell Appendices
Frequently asked questions Best practices for using Computer Collections Technical characteristics Best practices for creating backups Best practices for creating backups for forest recovery Best practices for recovering a forest Descriptions of recovery or verification steps Ports Used by Recovery Manager for Active Directory Forest Edition (Disaster Recovery Edition) Backup Wizard Online Restore Wizard Online Restore Wizard for AD LDS (ADAM) Group Policy Restore Wizard Repair Wizard Extract Wizard Events generated by Recovery Manager for Active Directory

Methods for deploying Backup Agent

Recovery Manager for Active Directory (RMAD) employs a Backup Agent to back up data on remote domain controllers.

The Backup Agent must be deployed on each remote domain controller where you want to back up Active Directory® data.

There are two methods to deploy the Backup Agent:

  • Have RMAD automatically deploy the Backup Agent before starting a backup creation operation and automatically remove the Agent after the operation is complete.

  • Manually preinstall the Backup Agent on all target domain controllers where you want to back up Active Directory® data.

The latter method allows you to:

  • Perform a backup operation without having domain administrator privileges. It is sufficient if RMAD runs under a backup operator's credentials.

  • Reduce network traffic when backing up a Computer Collection.

  • Back up domain controllers in domains that have no trust relationships with the domain where RMAD is running, solving the so-called “no trust” problem.

Note

To preinstall Backup Agent, you can either use the Backup Agent Setup Wizard or perform a silent installation. For more information, refer to the Quick Start Guide supplied with this release of RMAD.

 

Retain recent backups

If you create full backups on a daily basis as recommended earlier in this document, you should configure a backup retention policy to maintain the backups created in the last two weeks (14 last backups for each domain controller). This approach will provide you with a sufficient number of backups to recover from an Active Directory® failure that remained undetected for some time. For information on how to configure a backup retention policy, refer to the User Guide supplied with this release of Recovery Manager for Active Directory.

In addition to the retained backups, you can also archive at least one domain controller backup on a weekly basis. This will allow you to retrieve Active Directory® data (for instance, deleted objects) from a period past the recent backup history you retain. Make sure that these archived backups cover the entire tombstone lifetime period (180 days by default).

For security reasons, keep at least one copy of each backup off-site in a properly controlled environment in order to protect it from possible attacks by malicious individuals via the network.

 

Where to store backups

For each Computer Collection, you can specify where to store the Collection’s backup files. You can store backups on the computer running RMAD, the domain controller being backed up, or any available network share.

This section provides general recommendations where to store backups to be used in specific restore scenarios, such as granular online restore of directory objects, complete offline restore of Active Directory®, or Active Directory® forest recovery.

 

Storing backups for granular online or complete offline restores

When considering where to store backups, consider the primary scenario those backups will be used for in recovery. Although any Active Directory® backup can be used for any recovery scenario, deciding where they are stored is still important for both recovery speed and protection of those backups.

For a description of backup storage types, see Backup Storage.

Keeping redundant copies of backups is considered a best practice. Keep in mind that each Computer Collection can store backups in up to seven locations; four Tier 1 locations and three Tier 2 locations. Tier 1 storage must be used first, and then backups are copied from Tier 1 to Tier 2 storage.

Tier 1 storage is configured on the Local and Remote storage tabs. Each tab has two backup paths, Primary and Additional.

  • On the Local Storage tab, any local path mentioned (e.g. D:\) refers to a drive on the RMAD server. Backups are first copied by the Backup agent to the Primary backup path, and then (optionally) the RMAD console will copy it from there to the Additional backup path. Backup retention, the checkbox and value at the bottom of this tab, is only for the Primary backup path. The retention of backups on the Additional backup path is not managed by RMAD.

  • On the Remote Storage tab, any local path mentioned refers to a drive on the Domain Controller. Backups are copied to the Primary backup path and Additional backup path by the backup agent independently. The retention of both Primary and Additional backup paths are managed by the checkbox and value at the bottom of this tab.

Tier 2 storage is configured on the Secondary Storage tab, but before you can do that, the Tier 2 storage location(s) must be defined in the Storage node. To learn more about Secondary Storage options, see Secure Storage Server or Cloud Storage in the RMAD Disaster Recovery Edition User Guide.

Recovery Manager Backups are used to recover from three different scenarios.

  1. Active Directory Object / Attribute or Group Policy Object recovery.

  2. Catastrophic Forest or Domain disasters

  3. SYSVOL corruption

Active Directory Object / Attribute or Group Policy Object recovery

These backups should be placed on Primary (Tier 1) local storage, ideally on the RMAD server itself. If you instead store these on a network share (e.g. a NAS device) be sure it has a high-speed connection to the RMAD server. During recovery, RMAD unpacks these backups locally (on the RMAD server) so it can mount the NTDS.dit or read group policy objects in order to facilitate the recovery operation. Distant, low-speed connections can dramatically affect the efficiency of online object recovery.

Catastrophic Forest or Domain disasters

The most common cause of Forest or Domain disasters is ransomware encryption. With that in mind, it’s reasonable to assume any server and any network share were also encrypted, during the attack. The best way to protect your backups is to use Secondary (Tier 2) storage, either Secure Storage Server, Cloud Storage, or both.

If you plan on Bare Metal Recovery, then you must use an SMB share for Primary storage (on the Remote Storage tab). Then, to protect those backups, configure Secondary Storage too. Keep in mind that Bare Metal Recovery backups can be quite large:

  • For Secure Storage, ensure the Secure Storage server has a high-speed connection to the SMB share. We also recommend both Primary and Secondary storage locations are near to the RMAD server, as when you register those backups, you won’t want to do so over the WAN.

  • For Cloud Storage, keep in mind that Bare Metal Recovery backups can be ten times (10x) the size of Active Directory® backups or more. Retrieving large backups from the cloud can be time consuming.

SYSVOL Corruption

SYSVOL corruption is a rare occurrence. SYSVOL corruption is not usually from a cyber-attack, which means that, apart from SYSVOL, the Domain Controller is still functioning. Currently, our SYSVOL recovery mode uses native APIs, which requires a backup of every Domain Controller. If you decide to prepare for this type of disaster, it is recommend using a local path on the Remote Storage tab to store Active Directory® backups on the Domain Controllers themselves. Only 1 to 5 sessions of backups would need to be kept.

 

Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating