Chat now with support
Chat with Support

Recovery Manager for AD Disaster Recovery Edition 10.0.1 - User Guide

Overview Backing up data
Permissions required for the Backup operation Managing Backup Agent Using a least-privileged user account to back up data Creating backups 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 Getting started
Permissions required to use Recovery Manager for Active Directory Recovery Manager Console Icons in the user interface Getting and using help Configuring Windows Firewall Using Computer Collections Managing Recovery Manager for Active Directory configuration Licensing
Restoring data
Getting started with Active Directory recovery Managing deleted or recycled objects Restoring backed up System State components 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
Fault tolerance Consolidating backup registration data Monitoring Recovery Manager for Active Directory Recovering an Active Directory forest
Permissions required to use Forest Recovery Console Forest Recovery Console Managing a recovery project Install Active Directory from Media recovery method Install Active Directory recovery method Managing Forest Recovery Agent Rebooting domain controllers manually Specifying fallback IP addresses to access a domain controller Resetting DSRM Administrator Password Purging Kerberos Tickets Managing the Global Catalog servers Managing FSMO roles Manage DNS Client Settings Configuring Windows Firewall Forest recovery overview 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
Bare metal forest recovery Using Management Shell Creating virtual test environments Using Recovery Manager for Active Directory web interface Appendices
Frequently asked questions Best practices for creating backups for forest recovery Best practices for recovering a forest Descriptions of recovery or verification steps 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

Bare metal recovery requirements and limitations

NOTE: Domain controllers that are running on virtual machines in Amazon Web Services (AWS) or Microsoft Azure cannot be restored with the Bare Metal Active Directory Recovery method because there is no way to boot such DCs from an ISO image.

Backup storage requirements
  • If you do not want to encrypt BMR backups, we recommend to enable Server Message Block (SMB) Encryption feature (SMB version 3.0 and higher) on the network share to secure network connection. In this case, For more details on how to turn on SMB Encryption, see Note that backed up domain controllers must support SMB Encryption as well.
  • Also, you should store backups in the repository that is located in the same Active Directory site.
  • For Windows Server 2008 R2, BMR backups that are stored on the same Forest Recovery Console host are not supported.
  • The account that is used to access the BMR backups location must have Read and Write permissions to that location.
  • If the process of creating a Windows Server 2008 R2 BMR backup completes with the error like "The sector size of the physical disk on which the virtual disk resides is not supported.", make sure that the disk sector size on the target machine (NAS device or similar) is equal to 512 bytes.
    For instance, NetApp ONTAP operating system uses the following command: vserver cifs options modify -file-system-sector-size 512.
Backup requirements and limitations
  • Active Directory does not allow using a backup whose age exceeds the Active Directory tombstone lifetime (default is 180 days). But if there is a RMAD BMR backup that is older than 180 days and a more recent System State backup, you can successfully perform the restore operation.
Target system requirements
  • The number of physical disks on the target computer must be equal or exceed the number of disks on the source machine.
  • The physical disks on the target computer must be of the same size as the original disks or larger.
  • The firmware on the target computer must be compatible with the configuration of the source disks.
    • If the physical disks on the source computer have GPT partition style, the target computer must have UEFI firmware and must be booted in the UEFI mode.
    • If the physical disks on the source computer have the MBR partition style, then the target machine should be booted in the BIOS-compatibility mode (or just legacy BIOS mode).
      Source partition style BIOS (Target firmware) UEFI (Target firmware)
      GPT Incompatible Compatible
      MBR Compatible Compatible (legacy BIOS-compatibility mode)
Bare Metal Backup encryption
  • It is recommended to encrypt your Bare Metal Recovery backup by selecting the Encrypt and protect backups with password option (by default, this option is disabled) on the Backup tab in the collection properties. For details, see Creating backups.
    In this case, not only the backup data stored on the remote share is encrypted, but the data transferred over the network during the backup operation is encrypted as well.
  • If RMAD backup encryption is enabled, RMAD BMR backup will be encrypted by BitLocker.
    Recovery Manager for Active Directory uses a virtual hard disk encrypted by BitLocker as a container for the backup (256-bit AES encryption).
  • An encryption key for the backup is derived from the backup password and is not tied to a TPM chip (if any). This means that the encrypted RMAD BMR can be used on another machine, without or with another TPM chip. Only a backup password is required.
  • The BitLocker Drive Encryption feature should be installed on all backed up domain controllers and on the Forest Recovery Console machine to support encrypted BMR backups. But note that the BitLocker feature does not encrypt DC drives automatically. After the feature is installed, it is required to reboot the machine.

NOTE: After disaster recovery, volumes on the restored machine will not be BitLocker-protected. A customer have to enable the BitLocker protection again if required.

Prepare backups

Preparing backups

To restore the system state data in case of failure, you must occasionally create a BMR backup for at least one domain controller in each domain in your environment along with the System State data backup.

What should you do?

  • Decide on a Backup Location
    For BMR backups, the best practice in an enterprise environment is to deploy a dedicated backup server performing the role of an SMB repository with high disk I/O throughput to cope with the amount of backup data. You need to specify custom access credentials for the share to access the backup data even when Active Directory is unavailable.
  • Create Backups
    The backup schedule is defined by customer based on the available resources and desired level of protection.
    • Bare Metal Recovery (BMR) Backup
      It is recommended to prepare a BMR backup for a forest recovery because it can be restored to different hardware instances.
      BMR backups should be created only once a week to minimize the required storage space. Now only system critical volumes are included in a BMR backup by default. If you need to include additional volumes, see Creating backups.
    • System State Backup
      Standard RMAD backup includes system state-specific data, e,g. Active Directory data, registry, etc. It is recommended to create system state backup daily. In case of critical failures (such as DC hardware failure or malware) it will be possible to fully restore the domain with the combination of the most recent BMR backups and latest System State Backups.

    For details on how to create backups, see Creating backups.

Restore from Standard RMAD backup

Restoring from standard RMAD backup

In case of critical failures, the Bare Metal Active Directory Recovery method lets you fully restore the domain with the combination of the most recent RMAD BMR backup and the latest System State (standard RMAD) backup. For details about the backup creation, see Creating backups.

Standard RMAD backup includes system state-specific data, e,g. Active Directory data, registry, etc. It is recommended to create system state backup daily.

To enable restore of system state data, select the Restore from System State Backup option on the Settings tab. For information about all available options, see Settings tab.

NIC teaming support

When Recovery Manager for Active Directory Disaster Recovery Edition recovers the network settings, it connects to the first available network adapter.

In case of NIC teaming, there are two possible scenarios:

  • Recovery Manager for Active Directory Disaster Recovery Edition restores the system to the new hardware where network adapters have different MAC addresses.
    In this case, Recovery Manager for Active Directory Disaster Recovery Edition will configure some adapter with IP settings (either original or custom), and the operating system will disable NIC teaming because it will not be able to identify teamed NICs. So, the network will work with applied settings, but without teaming.
  • The domain controller is restored to the same server.
    In this case, the result depends on what adapter is selected by the recovery process (it is random). If the correct adapter (with MAC assigned to NIC team) will be selected, teaming will work, if a different one, the teaming will fail.
Related Documents