Frequently asked questions about Storage Replica

Yes. You can use the following scenarios with Azure:

• Server-to-server replication inside Azure (synchronously or asynchronously between IaaS VMs in one or two datacenter fault domains, or asynchronously between two separate regions)
• Server-to-server asynchronous replication between Azure and on-premises (using VPN or Azure ExpressRoute)
• Cluster-to-cluster replication inside Azure (synchronously or asynchronously between IaaS VMs in one or two datacenter fault domains, or asynchronously between two separate regions)
• Cluster-to-cluster asynchronous replication between Azure and on-premises (using VPN or Azure ExpressRoute)
• Stretch clustering using Azure Shared Disks (synchronously or asynchronously between IaaS VMs in one or two datacenter fault domains, or asynchronously between two separate regions)

Further notes on guest clustering in Azure can be found at: Deploying IaaS VM Guest Clusters in Microsoft Azure.

Important notes:

• There are Azure Resource Manager templates for Storage Spaces Direct-based Storage Replica clustering at Create a Storage Spaces Direct SOFS Clusters with Storage Replica for Disaster Recovery across Azure Regions.
• Cluster to cluster RPC communication in Azure (required by the cluster APIs for granting access between cluster) requires configuring network access for the CNO. You must allow TCP port 135 and the dynamic range higher than TCP port 49152. Reference Building Windows Server Failover Cluster on Azure IAAS VM – Part 2 Network and Creation.
• It's possible to use two-node guest clusters, where each node is using loopback iSCSI for an asymmetric cluster replicated by Storage Replica. But this configuration might perform poorly and should be used only for limited workloads or testing.

Event ID 1237 messages in the Storage Replica Admin event log on the destination server show the number of bytes copied and bytes remaining every 10 seconds. You can also use the Storage Replica performance counter on the destination showing \Storage Replica Statistics\Total Bytes Received for one or more replicated volumes. You can also query the replication group using Windows PowerShell. For instance, this sample command gets the name of the groups on the destination then queries one group named Replication 2 every 10 seconds to show progress:

Get-SRGroup

do{
    $r=(Get-SRGroup -Name "Replication 2").replicas
    [System.Console]::Write("Number of remaining bytes {0}`n", $r.NumOfBytesRemaining)
    Start-Sleep 10
}until($r.ReplicationStatus -eq 'ContinuouslyReplicating')
Write-Output "Replica Status: "$r.replicationstatus

Yes, using Set-SRNetworkConstraint. This cmdlet operates at the interface layer, and can be used on both cluster and noncluster scenarios. For example, with a standalone server (on each node):

Get-SRPartnership

Get-NetIPConfiguration

Note the gateway and interface information (on both servers) and the partnership directions. Then run:

Set-SRNetworkConstraint -SourceComputerName sr-srv06 -SourceRGName rg02 -
SourceNWInterface 2 -DestinationComputerName sr-srv05 -DestinationNWInterface 3 -DestinationRGName rg01

Get-SRNetworkConstraint

Update-SmbMultichannelConnection

For configuring network constraints on a stretch cluster:

Set-SRNetworkConstraint -SourceComputerName sr-cluster01 -SourceRGName group1 -SourceNWInterface "Cluster Network 1","Cluster Network 2" -DestinationComputerName sr-cluster02 -DestinationRGName group2 -DestinationNWInterface "Cluster Network 1","Cluster Network 2"

No, Storage Replica supports only one-to-one replication of a server, cluster, or stretch cluster node. You can configure replication between various servers of a specific volume pair, in either direction. For instance, Server 1 can replicate its D volume to server 2, and its E volume from Server 3.

You can grow (extend) volumes, but not shrink them. By default, Storage Replica prevents administrators from extending replicated volumes; use the Set-SRGroup -AllowVolumeResize $TRUE option on the source group, prior to resizing. For example:

1. Use against the source computer: Set-SRGroup -Name YourRG -AllowVolumeResize $TRUE
2. Grow the volume using whatever technique you prefer
3. Use against the source computer: Set-SRGroup -Name YourRG -AllowVolumeResize $FALSE

Not in Windows Server 2016. Storage Replica dismounts the destination volume when replication begins.

However, in Windows Server 2019, the option to mount the destination storage is now possible - this feature is called Test Failover. To perform a Test Failover, you must have an unused, NTFS or ReFS formatted volume that isn't currently replicating on the destination. Then you can mount a snapshot of the replicated storage temporarily for testing or backup purposes.

To create a test failover for the Replication Group RG2 on the destination server SRV2, using T: as a temporary drive that isn't being replicated, run the following command.

Mount-SRDestination -Name RG2 -Computername SRV2 -TemporaryPath T:\

The replicated volume is now accessible on SRV2. You can read and write to it normally, copy files off it, or run an online backup that you save elsewhere for safekeeping. The T: volume contains log data.

To remove the test failover snapshot and discard its changes:

Dismount-SRDestination -Name RG2 -Computername SRV2

You should only use the test failover feature for short-term temporary operations. It isn't intended for long term usage. When in use, replication continues to the real destination volume.

While technically possible, this configuration isn't recommended due to the lack of site awareness in the compute nodes contacting the SOFS. If using campus-distance networking, where latencies are typically submillisecond, this configuration typically works without issues.

If configuring cluster-to-cluster replication, Storage Replica fully supports Scale-out File Servers, including the use of Storage Spaces Direct, when replicating between two clusters.

No. You can replicate with CSV or persistent disk reservation (PDR) owned by a cluster resource, such as a File Server role.

If configuring cluster-to-cluster replication, Storage Replica fully supports Scale-out File Servers, including the use of Storage Spaces Direct, when replicating between two clusters.

This configuration isn't supported in Windows Server. If configuring cluster-to-cluster replication, Storage Replica fully supports Scale Out File Servers and Hyper-V Servers, including the use of Storage Spaces Direct.

Specify New-SRPartnership -ReplicationMode and provide argument Asynchronous. By default, all replication in Storage Replica is synchronous. You can also change the mode with Set-SRPartnership -ReplicationMode.

To prevent automatic failover, you can use PowerShell to configure Get-ClusterNode -Name "NodeName").NodeWeight=0. This command removes the vote on each node in the disaster recovery site. Then you can use Start-ClusterNode -PreventQuorum on nodes in the primary site and Start-ClusterNode -ForceQuorum on nodes in the disaster site to force failover. There's no graphical option for preventing automatic failover, and preventing automatic failover isn't recommended.

To prevent the new Hyper-V virtual machine resiliency feature from running and therefore pausing virtual machines instead of failing them over to the disaster recovery site, run (Get-Cluster).ResiliencyDefaultPeriod=0

You can use thin-provisioned storage as one way to speed up initial sync times. Storage Replica queries for and automatically uses thin-provisioned storage, including nonclustered Storage Spaces, Hyper-V dynamic disks, and SAN LUNs. Once initial replication is initiated, the volume isn't able to shrink or be trimmed.

You can also use seeded data volumes to reduce bandwidth usage and in some instances synchronization time. Use the Seeded option in Failover Cluster Manager or New-SRPartnership to ensure that the destination volume has some subset of data from the primary site. If the volume is mostly empty, using seeded sync might reduce time and bandwidth usage. There are multiple ways to seed data, with varying degrees of efficacy:

• Previous replication - by replicating with normal initial sync locally between nodes containing the disks and volumes, removing replication, shipping the destination disks elsewhere, then adding replication with the seeded option. This method is the most effective as Storage Replica guaranteed a block-copy mirror and the only thing to replicate is delta blocks.
• Restored snapshot or restored snapshot-based backup - by restoring a volume-based snapshot onto the destination volume, there should be minimal differences in the block layout. This method is the next most effective as blocks are likely to match thanks to volume snapshots being mirror images.
• Copied files - creating a new volume on the destination that wasn't used and performing a full robocopy /MIR tree copy of the data, there are likely to be block matches. Using Windows File Explorer or copying some portion of the tree doesn't create many block matches. Copying files manually is the least effective method of seeding.

You can use the Grant-SRDelegation cmdlet. This command allows you to set specific users in server-to-server, cluster-to-cluster, and stretch cluster replication scenarios. The command delegates the permissions to create, modify, or remove replication, without being a member of the local administrators group. For example:

Grant-SRDelegation -UserName contso\tonywang

The cmdlet reminds you that the user needs to sign out and then sign in to the server they're planning to administer in order for the change to take effect. You can use Get-SRDelegation and Revoke-SRDelegation to further control delegation.

Storage Replica supports backing up and restoring the source volume. It also supports creating and restoring snapshots of the source volume. You can't back up or restore the destination volume while protected by Storage Replica, as it isn't mounted nor accessible. If you experience a disaster where the source volume is lost, you can use Set-SRPartnership to promote the destination as the new source volume. The newly promoted source allows you to back up or restore that volume. You can also remove replication with Remove-SRPartnership and Remove-SRGroup to remount that volume as read/writable.

To create periodic application consistent snapshots, you can use VSSADMIN.EXE on the source server to snapshot replicated data volumes. For example, where you're replicating the F: volume with Storage Replica:

vssadmin create shadow /for=F:

Then, after you switch replication direction, remove replication, or are simply still on the same source volume, you can restore any snapshot to its point in time. For example, still using F:

vssadmin list shadows
vssadmin revert shadow /shadow={shadown copy ID GUID listed previously}

You can also schedule this tool to run periodically using a scheduled task. For more information on using VSS, review Vssadmin. There's no need or value in backing up the log volumes as VSS ignores it.

Storage Replica supports file-based backups. Storage Replica doesn't support block-based backup and restore.

Storage Replica relies on SMB and WSMAN for its replication and management, meaning the following ports are required:

• 445 (SMB - replication transport protocol, cluster RPC management protocol)
• 5445 (iWARP SMB - only needed when using iWARP RDMA networking)
• 5985 (WSManHTTP - Management protocol for WMI/CIM/PowerShell)

The optimal size of the log varies widely per environment, workload, and how much write IO your workload performs.

• A larger or smaller log doesn't make you any faster or slower
• A larger or smaller log doesn't have any bearing on a 10GB data volume versus a 10TB data volume, for instance

A larger log simply collects and retains more write IOs before they're wrapped out. A larger log allows an interruption in service between the source and destination computer – such as a network outage or the destination being offline - to go longer. For example, your log is configured to hold up to 10 hours of writes and the network goes down for 2 hours. When the network returns, the source can play back only the delta of unsynced changes back to the destination. If the log holds 10 hours and the outage is two days, the source now has to play back from a different log called the bitmap – and is typically slower to get back into sync. Once in sync it returns to using the log.

Storage Replica relies on the log for all write performance. Log performance critical to replication performance. You must ensure that the log volume performs better than the data volume, as the log serializes and sequentializes all write IO. You should always use flash media like SSD on log volumes. You must never allow any other workloads to run on the log volume, the same way you would never allow other workloads to run on SQL database log volumes.

You can get log sizing recommendations by running the Test-SRTopology tool. Alternatively, you can use performance counters on existing servers to make a log size judgment. The formula is simple: monitor the data disk throughput (Avg Write Bytes/Sec) under the workload and use it to calculate the amount of time it takes to fill up the log of different sizes. For example, data disk throughput of 50 MB/s causes the log of 120GB to wrap in 120GB/50MB seconds or 2400 seconds or 40 minutes. So the amount of time that the destination server could be unreachable before the log wrapped is 40 minutes. If the log wraps but the destination becomes reachable again, the source would replay blocks via the bit map log instead of the main log. The size of the log doesn't have an effect on performance.

ONLY the Data disk from the Source cluster should be backed-up. The Storage Replica Log disks should NOT be backed-up since a backup can conflict with Storage Replica operations.

Storage Replica comes in three main configurations: stretch cluster, cluster-to-cluster, and server-to-server. There are different advantages to each.

The stretch cluster topology is ideal for workloads requiring automatic failover with orchestration, such as Hyper-V private cloud clusters and SQL Server FCI. It also has a built-in graphical interface using Failover Cluster Manager. It utilizes the classic asymmetric cluster shared storage architecture of Storage Spaces, SAN, iSCSI, and RAID via persistent reservation. You can run this topology with as few as two nodes.

The cluster-to-cluster topology uses two separate clusters. This topology is ideal for administrators who want manual failover or when the second site is provisioned for disaster recovery and not everyday usage. Orchestration is manual. Unlike stretch cluster, Storage Spaces Direct can be used in this configuration (with caveats - see the Storage Replica FAQ and cluster-to-cluster documentation). You can run this topology with as few as four nodes.

The server-to-server topology is ideal for customers running hardware that can't be clustered. It requires manual failover and orchestration. It's ideal for inexpensive deployments between branch offices and central data centers, especially when using asynchronous replication. This configuration can often replace instances of DFSR-protected File Servers used for single-master disaster recovery scenarios. The server-to-server topology is ideal for customers running hardware that can't be clustered. It requires manual failover and orchestration. It's ideal for inexpensive deployments between branch offices and central data centers, especially when using asynchronous replication. This configuration can often replace instances of DFSR-protected File Servers used for single-master disaster recovery scenarios.

In all cases, the topologies support both running on physical hardware and virtual machines. When in virtual machines, the underlying hypervisor doesn't require Hyper-V; it can be VMware, KVM, Xen, etc.

Storage Replica also has a server-to-self mode, where you point replication to two different volumes on the same computer.

Yes, Data Deduplication is supported with Storage Replica. Enable Data Deduplication on a volume on the source server, and during replication the destination server receives a deduplicated copy of the volume.

While you should install Data Deduplication on both the source and destination servers (see Installing and enabling Data Deduplication), it's important not to enable Data Deduplication on the destination server. Storage Replica allows writes only on the source server. Because Data Deduplication makes writes to the volume, it should run only on the source server.

Unfortunately, we don't support creating a new partnership between Windows Server 2019 and Windows Server 2016. You can safely upgrade a server or cluster running Windows Server 2016 to Windows Server 2019 and any existing partnerships continue to work.

To get the improved replication performance of Windows Server 2019, all members of the partnership must run Windows Server 2019. You must also delete existing partnerships and associated replication groups, then recreate them with seeded data (either when creating the partnership in Windows Admin Center or with the New-SRPartnership cmdlet).

For technical assistance with Storage Replica, you can post at Microsoft Q & A or contact Microsoft Business Support. For issues with this documentation, see Feedback section at the bottom of this page, and select This page.

Storage Replica is a one-way replication technology. It only replicates from the source to the destination on a per volume basis. The direction can be reversed at any time, but is still only in one direction. That doesn't mean you can't have a set of volumes (source and destination) replicated in one direction and a different set of drives (source and destination) in the opposite direction. For example, you have want to have server to server replication configured. Server1 and Server2 each have drive letters L:, M:, N:, and O:. You wish to replicate drive M: from Server1 to Server2 and replicate drive O: from Server2 to Server1. You can use configure as long as there are separate log drives for each of the groups. For example:

• Server1 source drive M: with source log drive L: replicating to Server2 destination drive M: with destination log drive L:
• Server2 source drive O: with source log drive N: replicating to Server1 destination drive O: with destination log drive N:

Storage Replica blocks any cluster disks from entering maintenance mode. For tasks such as enabling or disabling BitLocker, the disks must be in maintenance mode. For tasks that require the disks to be in maintenance mode, the partnership would need to be broken first and created again once it's complete.

Storage Replica blocks a new partnership if the replication log versions don't match or if a capability isn't supported by both servers. Storage Replica compression is an example of a one capability that doesn't match between OS versions, as it was first added in Windows Server 2022. Attempting to configure a partnership for with unsupported capability returns:

"The requested operation isn't supported."

The current log version interoperability matrix is:

Replication from / to	Windows Server 2016	Windows Server 2019	Windows Server 2022
Windows Server 2016
Windows Server 2019
Windows Server 2022

• Storage Replica Overview
• Stretch Cluster Replication Using Shared Storage
• Server to Server Storage Replication
• Cluster to Cluster Storage Replication
• Storage Replica: Known Issues

• Storage Overview
• Storage Spaces Direct