Build and Test a Windows Server Storage Replica Recovery Plan

Storage Replica copies a Windows Server volume to another server at the block level. A server-to-server partnership can support a disaster recovery plan, but the destination volume is not a second live writable copy while replication runs. This lab uses SR-SRV05 as the source and SR-SRV06 as the destination, with F: for data and G: for replication logs on each server. Replace every name and volume with your approved topology.

The destination is dedicated to replication

Creating a partnership changes access to the destination data volume and begins an initial copy. Never point this guide at a volume containing independent data. Keep a separate, tested backup; replication also carries unwanted writes and does not replace backup. Rehearse the direction change on disposable data before any production recovery drill.

01

Define Recovery Goals and Supported Topology

Design

Record the application owner, source and destination, recovery time objective, recovery point objective, and who can authorize a role change. Check the installed Windows Server edition and its Storage Replica limits against Microsoft’s current support matrix. Decide whether synchronous replication is viable for the measured network latency and write workload. A server-to-server replica does not automatically move application names, shares, or services to the destination.

Get-CimInstance Win32_OperatingSystem |
  Select-Object CSName, Caption, Version, BuildNumber
Get-WindowsFeature Storage-Replica, FS-FileServer |
  Select-Object Name, InstallState

❯ What to Verify

Both server builds, editions, feature state, and application recovery
requirements are documented before storage is provisioned.

02

Prepare Dedicated Data and Log Volumes

Storage

Provision data and log volumes on both servers according to the storage vendor’s procedure. Use matching data sizes and sector sizes, GPT disks, and log volumes dedicated to Storage Replica. Make the log volume large enough for the measured write rate; the topology report informs final sizing. Do not use the OS volume, page-file volume, or an existing destination workload volume.

Get-Volume -DriveLetter F,G |
  Select-Object DriveLetter, FileSystem, Size, SizeRemaining
Get-Partition -DriveLetter F,G |
  Select-Object DiskNumber, DriveLetter, Size
Get-Disk | Select-Object Number, PartitionStyle, LogicalSectorSize, PhysicalSectorSize

❯ What to Verify

F: and G: exist on both servers; the destination F: is reserved for
replication, and log volumes are dedicated and sized for the workload.

Network and management path

The servers need bidirectional SMB and management connectivity, along with bandwidth for the application’s writes. Microsoft’s topology test checks reachability, volumes, sector sizes, and other prerequisites. Fix failures rather than bypassing them.

03

Install Features and Validate the Topology

Prerequisites

In a maintenance window, install Storage Replica on both servers and restart if requested. Install File Server where required for the topology test. Run the requirements-only test first, then schedule a performance test under representative write load. The test generates temporary data and a report; review its findings and storage impact with the application owner.

# On each server, in an elevated session; restart if the result requires it.
Install-WindowsFeature Storage-Replica, FS-FileServer -IncludeManagementTools

# On a server or management host with Storage Replica tools:
New-Item -ItemType Directory -Path 'C:\SRReports' -Force
Test-SRTopology -SourceComputerName SR-SRV05 -SourceVolumeName 'F:' `
  -SourceLogVolumeName 'G:' -DestinationComputerName SR-SRV06 `
  -DestinationVolumeName 'F:' -DestinationLogVolumeName 'G:' `
  -DurationInMinutes 1 -ResultPath 'C:\SRReports' -IgnorePerfTests

❯ What to Verify

The HTML topology report passes required checks. A separate measured run
supports the selected log size and recovery targets.

04

Create the Approved Partnership

Replication

After confirming that the destination F: is expendable and backups exist, create the partnership. Use distinct replication-group names. The source remains writable; the destination replica is dismounted for normal access. The initial copy may take time and consume bandwidth. Do not expose the destination share to users during synchronization.

New-SRPartnership -SourceComputerName SR-SRV05 -SourceRGName RG-SOURCE `
  -SourceVolumeName 'F:' -SourceLogVolumeName 'G:' `
  -DestinationComputerName SR-SRV06 -DestinationRGName RG-DEST `
  -DestinationVolumeName 'F:' -DestinationLogVolumeName 'G:' `
  -LogType Raw

❯ What to Verify

The partnership lists SR-SRV05 as source and SR-SRV06 as destination.
Initial block copy begins; destination data is not served to users.

05

Monitor Initial Copy and Ongoing Health

Health

Inspect the partnership on the source, then inspect group replica state, bytes remaining, and Storage Replica provider events on the destination. Wait for initial synchronization to complete before any planned switch. Record latency and queue counters under the actual application workload. A partnership object alone does not prove that the replica is current.

# On SR-SRV05 (current source):
Get-SRPartnership | Format-List *
# On SR-SRV06 (current destination):
Get-SRGroup | Select-Object Name, ComputerName, ReplicationMode
(Get-SRGroup -Name 'RG-DEST').Replicas |
  Select-Object ReplicationStatus, NumOfBytesRemaining, LastInSyncTime
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -MaxEvents 20 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

❯ What to Verify

Initial copy completes, replication is healthy, and unexpected error
events are investigated before a recovery drill proceeds.

Direction changes stop writes on the old source

A planned switch changes which server owns the writable copy. Stop application writes and coordinate client redirection first. Windows Server prevents a normal switch during initial synchronization; do not force a switch to skip that safeguard.

06

Rehearse a Planned Direction Change

Recovery Drill

On a disposable lab workload, stop writes to the old source and verify the replica is current. Save the partnership state, then switch the new source to SR-SRV06. Confirm that writes are blocked on the old source and that the new source can serve the test data. Restore application sharing and names according to a separately documented service recovery runbook. Do not present a volume direction switch as complete application failover.

# Approved lab drill only; complete synchronization and stop writes first.
$switch = @{
  NewSourceComputerName = 'SR-SRV06'
  SourceRGName = 'RG-DEST'
  DestinationComputerName = 'SR-SRV05'
  DestinationRGName = 'RG-SOURCE'
}
Set-SRPartnership @switch
Get-SRPartnership | Format-List *

❯ What to Verify

SR-SRV06 is the new source. Test data and the application recovery steps
are verified against the recorded recovery objectives.

07

Document Return and Monitoring

Closeout

Once the drill is complete, plan a separate, approved switch back after synchronization and application checks. Record the partnership direction, volumes, log sizing, event findings, DNS/share cutover actions, backup location, and who declares failover. Alert on replication errors and growing backlog. Do not remove a partnership as a cleanup shortcut; removal has separate storage access implications.

Recovery record: source | destination | data/log volumes | sync status |
                 service cutover | tested recovery time | rollback owner

❯ What to Verify

The recovery runbook covers both volume replication and service access.
The current writable source and return procedure are unambiguous.

Primary references

See Microsoft’s Storage Replica overview, server-to-server deployment and management guide, topology test reference, and known issues.