Chat now with support
Chat mit Support

Recovery Manager for AD Disaster Recovery 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 Cloud Storage Secure Storage Server 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
Restore Active Directory on Clean OS method Bare metal forest recovery 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

Storing backups for forest recovery

If you intend to use RMAD to recover the entire Active Directory® forest or specific domains in the forest, it is recommended that you store each backup file on the domain controller being backed up. This will considerably decrease the network utilization during backup operations and speed up the recovery process. On top of that, storing backup files on target domain controllers simplifies the permissions required to access those files.

Bare Metal Recovery backups
  • 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 enough memory and CPU 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.

  • You should store backups in the repository that is located in the same Active Directory® site.

  • BMR backups that are stored on the same Forest Recovery Console host are not supported.

Assumptions used here are that the forest or domain recovery is needed in case of logical Active Directory® corruption, when Active Directory® database and/or services were damaged, but the Domain Controllers are still bootable, not infected, not encrypted etc.

In this case the recommendation is simple. Store backups on Domain Controllers. This is done by using the Remote Storage settings and put a Domain Controller local path there, such as, D:\Backups\....

This recommendation extends, not replaces, the previous section about online recovery. In other words, in RMADFE it is recommended to store backups on both RMAD console (for online recovery) and on Domain Controllers (for forest recovery).

If there is not enough space on the Domain Controllers (or due any other reasons like potentially unreliable disk drives on the Domain Controllers), backups can be stored on a remote storage, preferably with a fast network link to Domain Controllers (not to the console). Keep in mind that a single remote storage for a large number of Domain Controllers may be a bottleneck in terms of network bandwidth, for example when 100+ Domain Controllers will do their backups at the same time, targeting the same remote storage.

As a last resort option, backups can be stored on the console machine (configured on the Local Storage tab) which also can be used for forest recovery as this configuration is supported. However in this case, the RMAD console becomes a single point of failure if the RMAD console’s disk drive with all the backups, unexpectedly fails.

 

Best practice for schedule and retention

If you intend to use RMAD to recover the entire Active Directory® forest or specific domains in the forest, it is recommended that you establish a backup schedule and retention period for the domain controllers being backed up.

Typically the Tombstone Lifetime (TSL) is used to decide just how many backups you need per domain.

This image gives a sense of the order that is needed based on the TSL.

For Object level recovery, it is recommend that you retain two weeks of daily backups followed by weekly backups up to Tombstone Lifetime (TSL). If Tombstone Lifetime is the default of 60 days, then that is 21 backups, and since it is recommend backing up at least 2 Domain Controllers per domain, that is 42 backups. If the TSL is 180 days, then that is 38 per Domain Controller or 76 total backups per domain.

It is recommend to create two separate Computer Collections per domain:

Label the first Collection Daily, but run it weekly, on every day of the week except Sunday.

Keep 12 sessions of this collection, which equals 2 weeks (minus Sundays).

Label the second Collection Weekly, and run it every Sunday.

  • If TSL is 60, then keep 9 sessions (9 x 7 = 63, which is 3 days past tombstone lifetime).

  • If TSL is 180, then keep 26 sessions (26 x 7 = 182 which is 2 days past tombstone lifetime).

If you follow this model then you have 2 weeks of daily backups, followed by weekly backups up to TSL, which is what the image above portrays.

It is fine to go just over Tombstone Lifetime (TSL), and that's better than ending just under TSL. Your oldest backup cannot be used after TSL.

 

Best practices for creating backups for forest recovery

 

How many instances of the Recovery Manager Console to deploy?

To recover your Active Directory® forest with the Forest Recovery Console, you can only use backups created with the Recovery Manager Console. In simple environments, it is advisable to have only one Recovery Manager Console deployed. However, this may not be possible in large distributed environments that spread across different physical locations connected by slow links. In this case, you can deploy several instances of the Recovery Manager Console in each main physical location to back up domain controllers there.

You can also deploy several instances of the Recovery Manager Console if you want to:

  • Delegate the right to back up individual Active Directory® objects and perform online restores to other administrators in your environment, without delegating the right to run forest recovery operations.

  • Back up and restore individual Active Directory® objects using backup and restore strategy and schedule specific to those objects.

 

Verwandte Dokumente

The document was helpful.

Bewertung auswählen

I easily found the information I needed.

Bewertung auswählen