Backup Active Directory Essentials For Secure Enterprise Recovery

Understanding Active Directory Backup Fundamentals

The integrity of AD hinges on its hierarchical structure, where a single failure—such as a corrupted NTDS.dit file or an unrecoverable DC—can cascade into domain-wide outages. Native Windows tools like Windows Server Backup (WSB) and Volume Shadow Copy Service (VSS) provide built-in mechanisms for AD protection, but their effectiveness varies based on deployment complexity and recovery requirements. Third-party solutions, such as Veeam, Altaro, or Commvault, offer advanced features like granular recovery, cross-platform support, and automated testing, yet introduce dependency on vendor-specific licensing and expertise.

Core Components Requiring Backup

Structural Components:

Active Directory Database (NTDS.dit): Stores all AD objects (users, groups, OUs) and their attributes. Corruption here renders the DC inoperable.

System State Data: Includes registry hives (e.g., `SYSTEM`, `SECURITY`), COM+ Class Registration Database, and boot files. Required for restoring a DC to a previous state.

Domain Controller Boot Files: Essential for recovery when a DC fails to start, including `NTDS.dit`, `Boot.ini`, and BCD (Boot Configuration Data).

Operational Assets:

Group Policy Objects (GPOs): Stored in SYSVOL, these define security policies, software deployments, and user preferences. Loss disrupts enterprise-wide configurations.

SYSVOL Replication: Contains scripts, policies, and logon scripts. Corruption here affects user logins and system behavior.

DNS Server Data: AD-integrated DNS zones must be backed up to ensure name resolution continuity post-recovery.

Native vs. Third-Party Backup Solutions: Comparative Analysis

Windows Server Backup (WSB):

Strengths:

Integrated with Windows Server, requiring no additional licensing.

Supports bare-metal recovery of DCs, restoring the entire system state in a single operation.

Can back up to local disks, network shares, or removable media.

Limitations:

No granular recovery—restoration requires reinstalling the DC and applying the backup, which can take hours.

No support for incremental backups of AD (only full system state backups).

No built-in verification of backup integrity, increasing risk of silent corruption.

Volume Shadow Copy Service (VSS):

Strengths:

Enables point-in-time snapshots of volumes containing AD data (e.g., `C:\Windows\NTDS`).

Useful for recovering individual files (e.g., a corrupted `NTDS.dit` copy) without full DC restoration.

Supports application-aware backups via VSS writers (e.g., SQL Server, Exchange).

Limitations:

No native AD-specific recovery tools—requires manual intervention to restore from snapshots.

Snapshot retention is limited by disk space and does not replace a full backup strategy.

No cross-platform support for hybrid environments (e.g., Azure AD integration).

However, third-party tools introduce vendor lock-in risks, higher licensing costs, and dependency on external support. For example, a misconfigured Veeam job might exclude critical AD logs, leading to undetected corruption until a recovery attempt fails.

Risks of Neglecting Active Directory Backups

1. Data Corruption:
   
2. Scenario: A failed Windows update or malware (e.g., ransomware like LockBit) encrypts or corrupts the `NTDS.dit` file.
3. Impact: The DC becomes inoperable, and without a backup, manual reconstruction of the AD database is required—a process that can take days and risks data loss.
4. Real-World Example: In 2021, a healthcare provider lost access to patient records after a ransomware attack corrupted their sole DC’s `NTDS.dit`. Recovery required rebuilding the domain from scratch, resulting in a 48-hour outage and HIPAA violations.
5. Accidental Deletions:
   
6. Scenario: An administrator deletes an Organizational Unit (OU) containing 500 user accounts via PowerShell or AD Users and Computers.
7. Impact: Without a backup, the OU and its contents must be recreated manually, leading to misconfigured permissions and user access disruptions.
8. Mitigation: Native WSB lacks granular recovery, but third-party tools like Altaro allow restoring individual OUs from backups.
9. Domain Controller Failures:
   
10. Scenario: A hardware failure (e.g., RAID controller crash) or power outage renders the last writable DC inoperable.
11. Impact: If no backup exists, the domain may enter directory services restoration mode (DSRM), requiring DIT recovery—a process that can fail if critical logs are missing.
12. Example: A financial firm lost its primary DC to a hardware failure. Without a recent backup, they had to promote a new DC from scratch, leading to replication conflicts and a 24-hour delay in resuming operations.
13. Replication Conflicts:
    
14. Scenario: A DC is restored from a backup without first seizing FSMO roles or ensuring replication consistency.
15. Impact: The restored DC may introduce authoritative conflicts, causing authentication failures and group policy inconsistencies across the domain.

Active Directory Backup Process Flowchart: Pre- and Post-Backup Validation

Pre-Backup Checks (Critical for Success):
1. Replication Status:

Verify all DCs have synced successfully using `repadmin /replsummary`.

Identify and resolve replication latency (>15 minutes indicates potential issues).

2. Disk Space:

Ensure backup targets (e.g., network shares, tapes) have sufficient capacity for full system state backups (typically 20–50GB per DC).

3. Backup Window:

Schedule backups during low-activity periods (e.g., overnight) to minimize performance impact.

4. VSS Writers:

Confirm VSS writers (e.g., `NTDS`, `System Writer`) are operational via `vssadmin list writers`.

5. Exclusion of Temporary Files:

Exclude pagefile.sys, hiberfil.sys, and temp folders to reduce backup size and improve efficiency.

Native Windows Tools for Active Directory Backup

Active Directory (AD) serves as the backbone of identity and access management in Windows environments, making its backup a critical operational task. Native Windows tools, particularly Windows Server Backup (WSB), provide a structured approach to securing AD data through system state backups. These tools integrate seamlessly with Windows Server 2016/2019/2022, offering a balance of simplicity and reliability for administrators. Below are step-by-step procedures for configuring, verifying, and recovering AD backups using WSB, along with best practices to mitigate common pitfalls.

Configuring and Executing a Full System State Backup Using Windows Server Backup

Windows Server Backup (WSB) allows administrators to create system state backups, which include critical AD components such as the Active Directory database (NTDS.dit), SYSVOL folder, registry hives, and COM+ catalog. This process ensures that AD can be restored in the event of corruption, accidental deletion, or hardware failure.

Prerequisites for WSB Configuration:

Windows Server with Windows Server Backup feature installed (included by default on full/standard editions).

Sufficient disk space on the backup destination (minimum 20% free space for optimal performance).

Administrative privileges on the server.

Step-by-Step Configuration:
1. Open Windows Server Backup
Navigate to Server Manager > Tools > Windows Server Backup. Alternatively, use the command `wsbctl` or search for "Windows Server Backup" in the Start menu.

2. Select Backup Once or Backup Schedule

For one-time backups, choose Backup Once.

For automated backups, select Backup Schedule and define a recurring interval (e.g., daily/weekly).

3. Choose Backup Destination
Select the target location for the backup:

Local drives (recommended for initial backups).

Network shares (requires proper permissions and may impact network performance).

Removable media (e.g., external drives or tapes).

4. Select System State Components

Under Select Items to Back Up, choose Add Items > System State.

Verify that the following AD-related components are included:

Active Directory database (NTDS.dit).

SYSVOL folder (contains group policies and logon scripts).

Registry (critical for AD configuration).

COM+ catalog (required for distributed transactions).

5. Configure Backup Options

Volume Shadow Copy Service (VSS): Ensure VSS is enabled to quiesce AD databases during backup (default setting).

Compression: Enable VSS Full Backup for larger environments to reduce storage footprint.

Verification: Select Verify data after backup to ensure integrity (recommended for production environments).

6. Execute the Backup

Click Next and review the summary.

Initiate the backup by selecting Backup. Monitor progress via the Backup Progress window.

Upon completion, a Backup Report is generated, confirming success or highlighting warnings.

Example Backup Command (PowerShell):

wbadmin start backup -backuptarget:E: -include:C:,D: -allCritical -quiet

Note: Replace `E:` with the backup destination and adjust volumes as needed.

Verifying the Integrity of a WSB AD Backup via Test Restoration

Restoring critical AD components in a test environment validates backup integrity and ensures recovery procedures are functional. This process involves restoring the SYSVOL folder, NTDS.dit, and registry hives to a non-production server with identical AD schema and domain functional levels.

Prerequisites for Test Restoration:

A test server with the same OS and AD role as the production environment.

Backup media containing the system state backup.

Authoritative restore permissions (if testing metadata changes).

Step-by-Step Restoration Procedure:
1. Prepare the Test Environment

Install Windows Server with the same AD Domain Services (AD DS) role.

Ensure the test server is not a domain controller (to avoid replication conflicts).

Disable Network Load Balancing (NLB) or Failover Clustering if the test server is part of a cluster.

2. Restore System State Components

Open Windows Server Backup > Recovery > This server.

Select the backup set and choose System State.

Under Select Recovery Type, opt for Restore all selected items (or granular options if available).

Verify the following components are selected:

NTDS.dit (Active Directory database).

SYSVOL (Group Policy and scripts).

Registry (AD-specific hives: `HKLM\SYSTEM\CurrentControlSet\Services\NTDS`).

Select a restore location (e.g., `C:\RestoredAD` to avoid overwriting production data).

3. Post-Restoration Validation

Check NTDS.dit Integrity: Use `ntdsutil` to verify the database:

ntdsutil snapshot "activate instance NTDS" activate
ntdsutil snapshot "mount {GUID}" mount

- Validate SYSVOL: Ensure group policies and scripts are accessible via `\\ServerName\SYSVOL`.

Test Authentication: Join a test machine to the restored domain and verify logon functionality.

4. Document Findings

Record any errors (e.g., missing objects, replication issues) in the backup report.

Compare the restored AD with a known-good backup to identify discrepancies.

Common Validation Scenarios:

Corrupted Objects: Restore a backup from a date before the corruption occurred.

Accidental Deletion: Recover deleted OUs or users via Authoritative Restore (see next section).

Group Policy Issues: Restore SYSVOL to resolve missing or corrupted policies.

Authoritative Restore in Active Directory Recovery

An Authoritative Restore is a recovery technique used to reintroduce deleted or modified objects into AD after restoring a backup. This process is critical when a backup is restored to a Domain Controller (DC) that is no longer the Primary Domain Controller (PDC) emulator, as replication may overwrite the restored data.

When to Use Authoritative Restore:

Deleted Organizational Units (OUs), users, or groups.

Modified attributes (e.g., `userAccountControl`, `lastLogonTimestamp`).

Tombstoned objects (objects deleted but not yet purged from the AD database).

Step-by-Step Authoritative Restore Procedure:
1. Restore the System State Backup

Use WSB to restore the NTDS.dit and registry to the target DC.

Ensure the DC is not set as a Global Catalog (GC) during restoration to avoid replication conflicts.

2. Seize FSMO Roles (If Necessary)

If the restored DC was previously a PDC emulator, seize the role to prevent replication conflicts:

ntdsutil
roles
connections
connect to server q
seize PDC
q
q

- Document the seized roles for later transfer back to the original DC.

3. Perform Authoritative Restore

Open Active Directory Users and Computers (ADUC) or Command Prompt.

For deleted objects:

ntdsutil
authoritative restore
restore subtree # e.g., "OU=DeletedUsers,DC=domain,DC=com"
q
q

- For modified attributes (e.g., `userAccountControl`):

dsmod user "CN=UserName" -useraccountcontrol

4. Monitor Replication

Use Repadmin to verify replication status:

repadmin /replsummary
repadmin /showrepl

- Wait for inbound replication to complete before promoting the DC to production.

Impact on AD Replication:

Immediate Conflicts: If the restored DC was not the original source, replication may cause object conflicts (e.g., duplicate SIDs).

Metadata Cleanup: Use `ntdsutil metadata cleanup` to remove orphaned objects post-restore.

Event Logs: Monitor Directory Service logs for errors (Event ID 1126 indicates replication issues).

Example Scenario:
A user account was accidentally deleted from the Users OU. The backup from yesterday is restored to a DC, and the account is reintroduced via authoritative restore. Replication ensures the account reappears across all DCs within the replication interval (default: 15 minutes).

Common Pitfalls When Using WSB for AD Backups

Third-Party Solutions and Advanced Backup Strategies for Active Directory

Active Directory (AD) environments demand robust backup solutions that balance granularity, recovery speed, and operational simplicity. While native Windows tools provide essential functionality, third-party solutions and advanced strategies—such as virtualization-based backups and continuous replication—offer enhanced resilience, automation, and cross-platform compatibility. These approaches address critical gaps in traditional backups, including rapid disaster recovery, minimal downtime, and support for hybrid or multi-cloud deployments. Below, a comparative analysis of leading third-party tools, virtualization integration, and replication techniques is presented, alongside a structured framework for automation via PowerShell.

Comparison of Third-Party Active Directory Backup Tools

Third-party AD backup solutions extend native capabilities with features like incremental backups, instant recovery, and cross-platform support. Below, three industry-leading tools—Veeam Agent for Microsoft Windows, Acronis Cyber Protect, and Quest On Demand Recovery (ODR)—are evaluated based on key criteria: backup granularity, recovery performance, cost structure, and ideal deployment scenarios.

Granularity refers to the ability to restore individual objects (e.g., users, groups, OUs) without full AD restoration, while recovery speed measures time-to-restore critical services post-failure.

Tool/Method	Backup Granularity	Recovery Speed	Cost	Best Use Case
Veeam Agent for Microsoft Windows	Supports item-level recovery (e.g., individual AD objects via VSS snapshots). Integration with Veeam Backup & Replication for VM-aware backups. Incremental forever backups with minimal storage overhead.	Instant recovery for VM-based AD (mounting backups as virtual disks). Sub-minute recovery for physical AD servers (depends on hardware).	Per-server licensing (~$50–$100/year per agent). Enterprise bundles reduce costs for large deployments.	Hybrid environments (physical + virtual AD). Organizations requiring VM-aware backups and cloud replication. Compliance-driven backups with immutable storage options.
Acronis Cyber Protect	Granular recovery for AD objects (users, GPOs, DNS records) via Acronis Active Protection. Supports bare-metal recovery with AD-aware restore points. Cross-platform backups (Windows, Linux, macOS) for hybrid AD forests.	Sub-5-minute recovery for local backups (SSD-optimized). Cloud recovery times vary (5–30 minutes based on bandwidth).	Subscription model (~$50–$150/year per endpoint). Advanced features (e.g., ransomware protection) add cost.	Multi-platform AD deployments (e.g., Linux-based DCs). SMBs or enterprises needing unified endpoint/AD protection. Disaster recovery with cloud-to-cloud or cloud-to-local restore.
Quest On Demand Recovery (ODR)	Fine-grained recovery (e.g., restore a single user without affecting OUs). AD-optimized backups with transaction log awareness (reduces corruption risk). Supports restore of deleted objects (e.g., "tombstoned" AD accounts).	Near-instant recovery for object-level restores (seconds). Full DC recovery in <10 minutes (with pre-staged backups).	Per-server licensing (~$200–$500 per DC, one-time or subscription). High upfront cost but lower total cost of ownership for large AD forests.	Enterprise AD environments with strict RTO/RPO requirements. Organizations needing granular recovery for compliance (e.g., GDPR). Legacy AD deployments where native tools fall short.

Key Considerations for Selection:

Virtualized AD: Veeam or Acronis are preferable for Hyper-V/VMware environments due to snapshot integration.

Physical AD: Quest ODR excels in granularity but requires careful planning for transaction log management.

Hybrid/Cloud AD: Acronis provides the broadest platform support, including Azure AD Connect sync logs.

Virtualization-Based Backups for Active Directory

Virtualization platforms (Hyper-V, VMware) enable AD backups via snapshots, leveraging Volume Shadow Copy Service (VSS) to capture consistent AD states. This method is widely adopted for its speed and simplicity but introduces risks if not configured properly.

Pros of Virtualization-Based Backups:

Rapid Recovery: Restore a DC VM from a snapshot in minutes, reducing downtime for critical services (e.g., authentication, DNS).

Point-in-Time Recovery: Snapshots allow reverting to a known-good state without manual intervention.

Storage Efficiency: Incremental snapshots minimize storage footprint compared to full backups.

Automation: Integrates with native hypervisor tools (e.g., Hyper-V Replica, VMware vSphere Replication).

Cons and Mitigation Strategies:

AD Consistency Issues: Snapshots may capture AD in an inconsistent state if not aligned with VSS writers. Solution: Use Application-Aware Image Processing (AAIP) in VMware or VSS-aware snapshots in Hyper-V.

Log Truncation Risks: Unmounted snapshots can corrupt AD logs. Solution: Implement a snapshot retention policy (e.g., 24–48 hours) and use Windows Server Backup (WSB) for log backups.

Performance Impact: Frequent snapshots can degrade VM performance. Solution: Schedule snapshots during low-usage periods (e.g., off-peak hours).

Best Practices for Virtualized AD Backups:
1. Enable VSS Writers: Ensure the Active Directory VSS Writer and System Writer are operational.

vssadmin list writers

2. Test Failover: Validate snapshot recovery by promoting a snapshot to a production DC in a lab environment.
3. Combine with Native Tools: Use Windows Server Backup for log backups and DFS-R for SYSVOL replication to complement snapshots.
4. Document Recovery Steps: Maintain a runbook for snapshot-based AD recovery, including steps to seize FSMO roles if needed.

Continuous Replication for Active Directory

Continuous replication reduces recovery time objectives (RTO) by maintaining synchronized copies of AD data in real time. Unlike traditional backups, replication methods like Distributed File System Replication (DFS-R) and Azure AD Connect sync logs provide near-instantaneous recovery for critical changes.

DFS-Replication (DFS-R) for SYSVOL and NETLOGON:

Mechanism: Replicates SYSVOL (Group Policy, scripts) and NETLOGON shares across DCs in a domain.

Use Case: Mitigates corruption in SYSVOL by maintaining a secondary copy. If primary SYSVOL is compromised, promote a replica.

Limitations:

Does not replicate AD database (NTDS.dit) or logs.

Requires

Recovery Procedures and Disaster Scenarios in Active Directory

Active Directory (AD) recovery operations require precise execution to restore critical domain services while minimizing downtime and preventing metadata conflicts. Proper recovery procedures address scenarios ranging from single-object deletions to catastrophic failures, such as domain controller (DC) crashes or ransomware attacks. This section provides structured guidance on restoring AD components, including DC promotion, object recovery, and database repair, alongside a framework for validating recovery outcomes in simulated disaster scenarios.

Step-by-Step Guide to Restoring an Active Directory Domain Controller from Backup

Restoring a DC from backup involves reinstalling the operating system, applying the backup, and promoting the restored server to avoid metadata conflicts. The process ensures the restored DC synchronizes correctly with the existing AD environment without introducing replication inconsistencies.

Prerequisites for DC Restoration:

A verified backup of the DC (System State or full system backup).

A server with hardware matching or exceeding the original DC’s specifications.

Appropriate permissions (Domain Admin or Enterprise Admin).

Network connectivity to other DCs in the domain.

Steps to Restore a DC:

1. Prepare the Target Server
   Install the same or compatible Windows Server OS version as the backed-up DC. Ensure the server is joined to the domain (if possible) or configured with the same network settings.
2. Restore System State or Full Backup
   Use the Windows Server Backup tool or third-party software to restore the System State backup (includes AD database, SYSVOL, registry, and boot files). For full system backups, restore the entire disk or volume containing the AD components.

   Note: If restoring to dissimilar hardware, use the "Recover to Different Hardware" option in Windows Server Backup.

3. Metadata Cleanup (If Applicable)
   If the original DC is permanently unavailable, use ntdsutil to remove its metadata from the AD database to prevent replication conflicts:
   

   ntdsutil
   
   metadata cleanup
   
   connections
   
   connect to server 
   quit
   
   select operation target
   
   list domains
   
   select domain  (e.g., 0 for the root domain)
   
   list sites
   
   select site  (e.g., 0 for the default site)
   
   list servers in site
   
   select server  (the original DC)
   
   quit
   
   remove selected server
   
   quit
   
   

4. Promote the Restored Server to DC
   Run dcpromo (Windows Server 2003/2008) or Install-ADDSDomainController (PowerShell, Server 2012+) to promote the server as a DC. Specify the same domain, site, and replication settings as the original DC.

   Critical: If the original DC’s name is reused, ensure no lingering objects (e.g., computer accounts) exist in AD that could cause conflicts.

5. Verify Replication and AD Health
   Use repadmin /replsummary to check replication status and dcdiag /test:dns /test:sysvolcheck to validate AD functionality. Monitor Event Viewer for errors (e.g., Event ID 1920 for replication failures).
6. Post-Restore Validation
   Confirm the restored DC holds all FSMO roles if the original DC was the last holder. Test critical services (e.g., authentication, Group Policy application) and demote the restored DC if it was a temporary replacement.

Recovering Deleted Active Directory Objects Using Authoritative Restore and Recycle Bin

Deleted AD objects (users, groups, OUs) can be recovered using the Authoritative Restore method or, if enabled, the AD Recycle Bin. The Recycle Bin provides a simpler recovery process, while Authoritative Restore is necessary for objects deleted before its implementation or in scenarios requiring immediate restoration without waiting for the tombstone period.

Recovering Objects with AD Recycle Bin (Enabled):

1. Enable AD Recycle Bin (if not already enabled)
   Run the following PowerShell command on a DC:
   

   Enable-ADOptionalFeature -Identity 'CN=Recycle Bin Feature,CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=domain,DC=com' -Scope ForestOrConfigurationSet -Target 'domain.com'
   
           

   Note: The Recycle Bin requires Windows Server 2008 R2 or later and must be enabled before deletions occur.

2. Restore Deleted Objects via PowerShell or GUI
   Use the Restore-ADObject cmdlet:
   

   Restore-ADObject -Identity '' -RestoreModifiableObjects
   
   

   Or navigate to Active Directory Administrative Center > Deleted Objects container and right-click the object to restore.
3. Validate Recovery
   Verify the object’s attributes (e.g., userAccountControl for users) and test functionality (e.g., logon for users).

Authoritative Restore for Objects Outside Recycle Bin:

1. Identify the Deleted Object’s Tombstone
   Use dsquery or Get-ADObject to locate the object in the Deleted Objects container:
   

   dsquery "CN=Deleted Objects,DC=domain,DC=com" -filter "(name=*)"
   
           

2. Authoritative Restore via ntdsutil
   Launch ntdsutil and execute:
   

   ntdsutil
   
   authoritative restore
   
   restore object
   
   
   quit
   
   quit
   
       

   Critical: Authoritative Restore forces the object’s deletion timestamp to the current time, preventing replication conflicts. Use this only when necessary, as it can disrupt replication if misapplied.

3. Force Replication
   Run repadmin /syncall to propagate the restored object to all DCs.
4. Post-Restore Adjustments
   Manually correct attributes (e.g., whenChanged) if the object was restored incorrectly. For users, reset passwords and test access.

Recovering a Corrupted Active Directory Database (NTDS.dit) Using ntdsutil and esentutl

Corruption in the AD database (NTDS.dit) can render a DC inoperable. Recovery involves using ntdsutil for metadata repairs and esentutl for Extensible Storage Engine (ESE) database recovery. This process should be performed in a controlled environment to avoid further damage.

Steps to Recover NTDS.dit:

1. Isolate the Corrupted DC
   Disconnect the DC from the network to prevent replication from exacerbating corruption. Boot into Directory Services Restore Mode (DSRM) if the DC fails to start normally.
2. Run esentutl for Database Repair
   Use esentutl.exe to repair the ESE database:
   

   esentutl /r  (e.g., C:\Windows\NTDS\NTDS.dit)
   
   

   For a full repair (may lose uncommitted transactions):
   

   esentutl /g  C:\Temp\NTDS_Repair
   
   

   Warning: The /g option creates a clean database copy, which may require a non-authoritative restore if used.

3. Use ntdsutil for Metadata and Log File Recovery
   Launch ntdsutil and execute:
   

   ntdsutil
   
   files
   
   compact to  (creates a compacted database)
   
   quit
   
   quit
   
   

   To recover from log files (if available):
   

   ntdsutil
   
   activate instance ntds
   
   journal wrap
   
   quit
   
   quit
   
   

4. Restore from Backup (If Corruption Persists)
   Replace the corrupted NTDS.dit with a known-good backup. Ensure the backup is recent and matches the AD schema version. After restoration, promote the DC again.

Mastering Active Directory backup is not merely about preserving data—it is about future-proofing an organization’s ability to recover swiftly and accurately when adversity strikes. By leveraging the right tools, automating critical processes, and rigorously testing recovery procedures, administrators can transform potential disasters into manageable incidents. The tables, step-by-step guides, and comparative analyses provided here serve as a blueprint for constructing a backup framework that balances reliability, efficiency, and adaptability. In an era where digital infrastructure underpins every business function, the difference between a seamless recovery and a prolonged crisis often lies in the preparation undertaken today.

• active directory backup
• authoritative restore
• disaster recovery planning
• ntfs backup strategies
• windows server recovery

Leave a Comment

Name

Comment

Post Comment

Comments are moderated before appearing. The data you submit is processed according to the Privacy Policy of ir.msu.ac.zw.