Storage Replication Sync Failed – Quick Fixes That Actually Work

30-Second Fix: Check the Network Path

Before you blame the storage or the replication software, check if the two servers can actually talk to each other. The culprit here is almost always a transient network issue — a bad cable, a flapping port, or a firewall rule that changed during a patch cycle.

Open PowerShell as admin on both sides and run:

Test-NetConnection -ComputerName <remote-server> -Port 445

If that fails, check the firewall. For Windows Storage Replica, you need port 445 (SMB) open between the servers. Also run a simple ping with a continuous flag for 30 seconds:

ping -t <remote-ip>

If you see any "Request timed out" or high latency (>10ms on a LAN), you've found your problem. Reseat cables, check switch ports, or ask the network team to look at link errors. Don't bother with a full network trace yet — 90% of sync failures are just bad connectivity.

5-Minute Fix: Fix Clock Drift

Storage Replication uses timestamps to track changes. If the clocks on your source and destination servers are off by more than 5 minutes, replication will stall. This happens more than you'd think — especially after daylight saving time changes or if one server is in a different time zone and the NTP config is wrong.

Check the time on both servers:

w32tm /query /status

Look at the "Source" and "Last Sync Time". If they're not pointing to the same NTP source, fix it. On both servers, set the same NTP server:

w32tm /config /manualpeerlist:"time.windows.com" /syncfromflags:MANUAL
net stop w32time && net start w32time
w32tm /resync

Then verify the offset is under 1 second:

w32tm /stripchart /computer:<remote-server> /samples:5

If you see a difference over 500ms, your clocks are off. Sync them, wait 2 minutes, then check if the replication resumes. If it doesn't, move on to the next fix.

15+ Minute Fix: Rebuild the Quorum and Restart the Replica

This is the nuclear option. If the network is clean and clocks are synced, the issue is likely a stale quorum state. Storage Replica uses a witness or a majority node set to decide which copy is authoritative. When the quorum gets confused — from a forced restart or a partial network partition — the sync gets stuck in "Synchronizing" or "Failed" mode.

First, check the replication status:

Get-SRPartnership
Get-SRGroup

If the state shows "Synchronizing" for more than 10 minutes or "Failed", you need to reset it. Here's the procedure:

1. Stop the replication group on the destination server. This preserves the data but breaks the sync relationship.
2. Run this on the destination:

Set-SRPartnership -Force -ReplicationMode Asynchronous -SourceComputerName <source> -SourceRGName <sourceRG> -DestinationComputerName <destination> -DestinationRGName <destinationRG>

That's a mouthful, but it forces a new partnership with an async mode first. Async is less strict about network latency and will often get things moving again. Once you see it's syncing (use Get-SRPartnership), you can switch back to sync if needed:

Set-SRPartnership -ReplicationMode Synchronous -Force

If this still fails, you're looking at a full re-initialization. That means copying the data from scratch. On the destination, remove the replication:

Remove-SRPartnership -Force
Remove-SRGroup -Force

Then on the source, remove the group too:

Remove-SRGroup -Force

Now re-create the replication from scratch using New-SRPartnership. This takes time — expect a full copy of the volume. But it's the only way to clear a corrupt quorum state.

When to Call It Quits and Get Help

If you've done all three steps and the sync still fails, check the Windows Event Log under Applications and Services Logs > Microsoft > Windows > StorageReplica > Admin. Look for Event ID 2033 or 5006. These will tell you exactly why it failed — usually a "log overflow" or "out of log space". That means the log volume on the source or destination is full. Increase the log size to at least 8GB (default is 1GB, which is stupid for any real workload):

Set-SRGroup -Name <group> -LogSizeInBytes 8GB

If logs aren't the issue, you've got something deeper — maybe a disk driver bug or a SAN compatibility issue. At that point, open a case with Microsoft or your storage vendor. But honestly? 9 times out of 10, it's one of the three fixes above.