Windows Server Storage Replica: Architecture, Setup, and Failover Guide

What Is Storage Replica?

Storage Replica is a built-in Windows Server feature designed to deliver host-level, block-based volume replication for high availability and disaster recovery. Historically, enterprise disaster recovery required costly hardware-level SAN replication (such as EMC SRDF or NetApp SnapMirror) or fragile file-based synchronization tools like DFS Replication.

DFS Replication operates at the file level in user mode: it waits until an application closes a file before calculating differences and transmitting changes. If a user has a virtual machine disk (VHDX) or a SQL Server database file open for six months, DFS Replication cannot replicate it at all.

Think of Storage Replica like an automated live mirror on a conveyor belt. Instead of waiting for an entire document to be finished, printed, signed, and closed before photocopying it, Storage Replica mirrors every single pen stroke the moment ink touches paper. If power cuts out mid-sentence, the replica paper on the receiving end matches the primary copy stroke for stroke.

Because Storage Replica lives in the kernel storage filter stack between the file system driver and the partition manager, it sees raw sectors. It does not care whether the volume contains Hyper-V virtual hard disks, SQL Server databases, ReFS file shares, or arbitrary application files.

How Storage Replica Works: Synchronous vs Asynchronous

Storage Replica offers two distinct replication modes depending on network latency and business continuity objectives:

1. Synchronous Replication: Designed for local metro areas or campus networks where round-trip network latency is under 5 milliseconds. In synchronous mode, when an application issues a write, the write must be committed to the log on both the source and the destination before the application receives a completion acknowledgement. This guarantees a Recovery Point Objective (RPO) of zero — there is zero data loss during an abrupt site failure.

2. Asynchronous Replication: Designed for long-distance disaster recovery across regional WAN links where latency exceeds 5 milliseconds. The application receives a write completion as soon as the write lands in the local source log; changes replicate to the destination as network bandwidth allows. If the primary site is destroyed, the RPO is greater than zero, meaning a few seconds of recent uncommitted writes may be lost.

The synchronous write path works across the network using SMB3 or SMB Direct (over RDMA) on port 445 or 5445:

[Application Write]
        │
        ▼
[Source File System (NTFS/ReFS)]
        │
        ▼
[Storage Replica Filter Driver] ─── (Parallel Write) ───▶ [Source Log Volume]
        │
        ▼ (SMB3 / RDMA over Port 445 / 5445)
[Destination Storage Replica Driver] ─────────────────▶ [Destination Log Volume]
        │                                                          │
        ▼                                                          ▼
[Destination ACK returned] ◀────────────────────────────── [Log Write ACK]
        │
        ▼
[Application Receives Write ACK]
        │
        ▼ (Background Drain)
[Source & Destination Data Volumes Updated from Log]

Notice that writes land on the log volume first. Writing sequentially to a dedicated partition is drastically faster than random seeks on a large data drive. Once both log volumes acknowledge the write, the application continues, and background kernel threads flush (drain) the log blocks into the actual data volume.

Deployment Topologies

Storage Replica supports three standard architectural topologies:

For small to medium homelabs or remote branch offices, Server-to-Server replication is the simplest and most accessible topology: it provides robust offsite disaster recovery without requiring the complexity of shared SAS enclosures or complex cluster witnesses.

Prerequisites and Validating with Test-SRTopology

Before configuring Storage Replica, both servers must satisfy strict volume and network prerequisites:

Both servers must belong to the same Active Directory forest. Disks must be partitioned as GPT (not MBR), formatted with either NTFS or ReFS, and have matching sector sizes (e.g. 4096-byte advanced format sectors on both sides).

Each server requires at least two separate volumes: one for data (e.g. D:) and one for the transaction log (e.g. L:). The log volume should reside on fast storage (preferably SSD or NVMe), must be at least 8 GB, and cannot be shared across multiple replication groups.

Microsoft provides the Test-SRTopology cmdlet to evaluate connectivity, bandwidth, latency, and log sizing before you establish replication:

# Test topology and assess required log sizing based on a 15-minute write sample
Test-SRTopology `
  -SourceComputerName "SRV-PRI.corp.example.com" `
  -SourceVolumeName "D:" `
  -SourceLogVolumeName "L:" `
  -DestinationComputerName "SRV-SEC.corp.example.com" `
  -DestinationVolumeName "D:" `
  -DestinationLogVolumeName "L:" `
  -DurationInMinutes 15 `
  -ResultPath "C:\SRTopologyReport"

Open the resulting HTML report generated in C:\SRTopologyReport. It evaluates average write IOPS, round-trip latency, and confirms whether your network bandwidth can sustain synchronous replication without throttling the primary application.

Configuring Replication and Failover

Configuring Storage Replica involves installing the role feature, creating the partnership, monitoring replication status, and executing controlled failovers.

# 1. Install Storage Replica and management tools on both servers
Install-WindowsFeature -ComputerName "SRV-PRI", "SRV-SEC" -Name Storage-Replica, FS-FileServer -IncludeManagementTools -Restart

# 2. Establish a new synchronous replication partnership between source and destination
New-SRPartnership `
  -SourceComputerName "SRV-PRI" `
  -SourceRGName "rg01-primary" `
  -SourceVolumeName "D:" `
  -SourceLogVolumeName "L:" `
  -DestinationComputerName "SRV-SEC" `
  -DestinationRGName "rg02-secondary" `
  -DestinationVolumeName "D:" `
  -DestinationLogVolumeName "L:" `
  -ReplicationMode Synchronous

# 3. Verify partnership health and group status
Get-SRPartnership
Get-SRGroup -ComputerName "SRV-PRI"

# 4. View replication progress and remaining initial copy bytes
(Get-SRGroup -ComputerName "SRV-PRI").Replicas | 
  Select-Object Name, Mode, ReplicationStatus, NumOfBytesRemaining

# 5. Perform a planned disaster recovery failover (reverse replication direction)
# Run from the target node to make it the new source
Set-SRPartnership `
  -NewSourceComputerName "SRV-SEC" `
  -SourceRGName "rg02-secondary" `
  -DestinationComputerName "SRV-PRI" `
  -DestinationRGName "rg01-primary"

# 6. Test destination data without breaking replication using a temporary snapshot mount
Mount-SRDestination -Name "rg02-secondary" -ComputerName "SRV-SEC" -TemporaryPath "C:\TempMount"

# 7. Dismount the test destination snapshot when verification is complete
Dismount-SRDestination -Name "rg02-secondary" -ComputerName "SRV-SEC"

# 8. Remove the replication partnership completely if decommissioning
Remove-SRPartnership -SourceComputerName "SRV-PRI" -SourceRGName "rg01-primary"

Storage Replica Troubleshooting and Event IDs

Storage Replica logs detailed operational events to the Event Viewer under Applications and Services Logs > Microsoft > Windows > StorageReplica.

Final Thoughts

Windows Server Storage Replica is one of the most under-utilised native disaster recovery features in enterprise infrastructure. By decoupling volume replication from proprietary SAN controllers, it allows systems administrators to build resilient zero-data-loss mirror architectures using standard commodity hardware, DAS, or Storage Spaces.

Whether you are standing up a multi-site stretch cluster for automated Hyper-V failover or simply replicating a mission-critical file repository to an offsite server, validating network latency with Test-SRTopology and provisioning fast, dedicated SSD log volumes ensures robust disaster recovery without compromising primary storage performance.