The Importance of Disaster Recovery in Windows Server
In enterprise IT, protecting critical data against catastrophic hardware failure, site-wide power outages, or natural disasters is a fundamental requirement. Historically, achieving block-level synchronous replication across different physical locations required expensive, proprietary Storage Area Network (SAN) hardware from vendors like EMC or NetApp.
With the introduction of Storage Replica in Windows Server 2016 (and greatly enhanced in Server 2019 and 2022), Microsoft brought enterprise-grade, hardware-agnostic block-level replication directly into the operating system. Storage Replica allows administrators to replicate volumes synchronously or asynchronously between servers or clusters, ensuring zero data loss (RPO = 0) in synchronous mode.
Prerequisites for Storage Replica
Before configuring Storage Replica, you must ensure your environment meets the strict prerequisites:
- Active Directory: Both the source and destination servers must be members of the same AD forest.
- Storage: You need at least two volumes on each server: a Data volume (for the actual files) and a Log volume (for replication metadata). The Log volume must be at least 9GB and should ideally be on fast NVMe or SSD storage.
- Network: A dedicated, high-bandwidth network connection with low latency. For synchronous replication, round-trip latency must be under 5ms.
- Firewall: ICMP, SMB (Port 445), and WS-MAN (Port 5985) must be open between the nodes.
Step 1: Installing the Storage Replica Feature
The first step is to install the Storage Replica feature and the necessary PowerShell management modules on both the source server (Server-A) and the destination server (Server-B).
Run the following PowerShell command on both nodes:
Install-WindowsFeature -Name Storage-Replica, FS-FileServer -IncludeManagementTools -Restart
The server will reboot automatically once the installation is complete.
Step 2: Testing the Topology
Microsoft provides a built-in testing cmdlet to verify that your network latency and storage performance can support Storage Replica. This test evaluates the throughput and generates a detailed HTML report.
Run the test from Server-A, specifying the data and log volumes on both ends:
Test-SRTopology -SourceComputerName Server-A -SourceVolumeName D: -SourceLogVolumeName L: -DestinationComputerName Server-B -DestinationVolumeName D: -DestinationLogVolumeName L: -DurationInMinutes 5 -ResultPath C:\SR_Report
Open the resulting HTML report. If the test passes without significant latency warnings, you can proceed to create the partnership.
Step 3: Creating the Replication Partnership
A Storage Replica relationship is called a “Partnership.” When you create a partnership, the destination volume will immediately become inaccessible (mounted as RAW) to users on Server-B, as block-level replication takes exclusive control of the disk.
To establish a synchronous replication partnership, run the following command on Server-A:
New-SRPartnership -SourceComputerName Server-A -SourceRGName rg01 -SourceVolumeName D: -SourceLogVolumeName L: -DestinationComputerName Server-B -DestinationRGName rg02 -DestinationVolumeName D: -DestinationLogVolumeName L: -LogSizeInBytes 9GB
By default, New-SRPartnership configures synchronous replication. If the servers are separated by high latency (e.g., cross-country), you must append the -ReplicationMode Asynchronous flag.
Step 4: Monitoring the Initial Sync
Depending on the size of the data volume and the speed of your network link, the initial block copy can take hours or days. During this time, the replication status will show as “InitialBlockCopy”.
To monitor the progress, check the Replication Status on Server-A:
Get-SRGroup
Additionally, you can monitor the internal Windows Event Logs dedicated to Storage Replica to track the exact percentage of completion:
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -MaxEvents 10
Step 5: Executing a Planned Failover
In the event of a disaster, or during a planned maintenance window, you must manually reverse the replication direction to make the destination server writable.
To execute a planned failover, run the Set-SRPartnership command and flip the roles. The following command makes Server-B the primary source:
Set-SRPartnership -NewSourceComputerName Server-B -SourceRGName rg02 -DestinationComputerName Server-A -DestinationRGName rg01
Once executed, the data volume on Server-A will lock, and the data volume on Server-B will instantly become writable, allowing you to bring your applications back online.
Conclusion
Windows Server Storage Replica democratizes enterprise disaster recovery by eliminating the need for expensive SAN hardware. By utilizing native PowerShell cmdlets to establish synchronous partnerships, administrators can guarantee zero data loss across distributed data centers, ensuring absolute business continuity.