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.
Recovery Manager Backups are used to recover from three different scenarios.
-
Active Directory Object / Attribute or Group Policy Object recovery.
-
Catastrophic Forest or Domain disasters
-
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.
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.
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