Edit

Share via

Storage Replica FAQ

  • FAQ

This article contains answers to frequently asked questions for Storage Replica.

Is Storage Replica supported on Azure?

Yes. You can use the following scenarios with Azure:

  • Server-to-server replication inside Azure (synchronously or asynchronously between infrastructure as a service (IaaS) virtual machines (VMs) in one or two datacenter fault domains, or asynchronously between two separate regions).
  • Server-to-server asynchronous replication between Azure and on-premises (by using a virtual private network (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 (by using VPN or Azure ExpressRoute).
  • Stretch clustering by using Azure Shared Disks (synchronously or asynchronously between IaaS VMs in one or two datacenter fault domains, or asynchronously between two separate regions).

For more information about guest clustering in Azure, see Deploy IaaS VM guest clusters in Azure.

Important notes:

How do I view the progress of replication during initial sync?

Event ID 1237 messages in the Storage Replica Admin event log on the destination server show the number of bytes copied and the bytes remaining every 10 seconds.

Another option is to use the Storage Replica performance counter on the destination server under \Storage Replica Statistics\Total Bytes Received for one or more replicated volumes.

You can also query the replication group by using Windows PowerShell. For example, the following sample command gets the name of the groups on the destination, and 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

Can I specify the network interfaces to use for replication?

Yes. To specify the network interfaces to use for replication, use the Set-SRNetworkConstraint cmdlet. This cmdlet operates at the interface layer. You can use it both in cluster and noncluster scenarios.

For example, with a standalone server (on each node), run these commands:

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

To configure network constraints on a stretch cluster, run:

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"

Can I configure one-to-many replication or transitive (A to B to C) replication?

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 example, Server 1 can replicate its D volume to Server 2, and its E volume from Server 3.

Can I grow or shrink replicated volumes that Storage Replica replicates?

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

For example:

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

Can I bring a destination volume online for read-only access?

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

Windows Server 2019: Yes. You can mount the destination storage by using the test failover feature. To perform a test failover, you must have an unused NTFS or ReFS formatted volume that isn't currently replicating on the destination. Then, 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, run:

Dismount-SRDestination -Name RG2 -Computername SRV2

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

Can I configure Scale-Out File Server (SOFS) in a stretch cluster?

Although it's technically possible, we don't recommend this configuration due to the lack of site awareness in the compute nodes that contact the SOFS instance. If you use campus-distance networking, where latencies are typically less than a millisecond, this configuration typically works without issues.

In a cluster-to-cluster replication, Storage Replica fully supports SOFS, including the use of Storage Spaces Direct, when you replicate between two clusters.

Is Cluster Shared Volumes required to replicate in a stretch cluster or between clusters?

No. You can replicate by using Cluster Shared Volumes or a persistent disk reservation (PDR) that's owned by a cluster resource, such as a File Server role.

In cluster-to-cluster replication, Storage Replica fully supports SOFS, including the use of Storage Spaces Direct, when replicating between two clusters.

Can I configure Storage Spaces Direct in a stretch cluster with Storage Replica?

No. This configuration isn't supported in Windows Server.

In cluster-to-cluster replication, Storage Replica fully supports SOFS and Hyper-V servers, including the use of Storage Spaces Direct.

How do I configure asynchronous replication?

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

How do I prevent automatic failover of a stretch cluster?

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 run Start-ClusterNode -PreventQuorum on nodes in the primary site and Start-ClusterNode -ForceQuorum on nodes in the disaster site to force failover. Preventing automatic failover isn't available as a UI configuration option, and we recommend that you don't prevent automatic failover.

How do I disable virtual machine resiliency?

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

How can I reduce time for initial synchronization?

You can use thin-provisioned storage 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 Storage Area Network (SAN) Logical Unit Numbers (LUNs). After initial replication begins, you can't shrink or trim the volume.

You can also use seeded data volumes to reduce bandwidth usage and, in some scenarios, synchronization time. Use the Seeded option in Failover Cluster Manager or use the New-SRPartnership cmdlet 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.

To seed data, you can choose from options that offer varying degrees of efficacy:

  • Previous replication. Replicate via normal initial sync locally between nodes that contain the disks and volumes, remove replication, ship the destination disks elsewhere, and then add replication by using the seeded option. This method is the most effective because Storage Replica guarantees 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 next most effective. Blocks are likely to match because volume snapshots are mirror images.
  • Copied files. Create a new volume on the destination that wasn't used, and then perform 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.

Can I delegate users to administer replication?

Yes. Use the Grant-SRDelegation cmdlet to delegate users. You can use the command 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 contoso\tonywang

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

What are my backup and restore options for replicated volumes?

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 it's protected by Storage Replica because it isn't mounted or accessible.

If you experience a disaster and the source volume is lost, you can use the Set-SRPartnership cmdlet to promote the destination as the new source volume. On the newly promoted source, you can back up or restore that volume. You can also remove replication with by using the Remove-SRPartnership and Remove-SRGroup cmdlets to remount the volume as read/writable.

To create periodic application-consistent snapshots, you can use Volume Shadow Copy Service (VSS) by running VSSAdmin.exe on the source server to snapshot replicated data volumes.

For example, where you're replicating the F: volume with Storage Replica, run this command:

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:, run:

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

You can also schedule this tool to run periodically by using a scheduled task. For more information on using VSS, see vssadmin. VSS ignores the log volume, so you don't need to back up the log volume.

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

What network ports does Storage Replica require?

Storage Replica relies on Server Message Block (SMB) and Web Services Management (WSMan) for its replication and management, so the following ports are required:

  • 445 (SMB; replication transport protocol, cluster RPC management protocol)
  • 5445 (iWARP SMB; needed only when using iWARP remote direct memory access (RDMA) networking)
  • 5985 (WSManHTTP; management protocol for Windows Management Instrumentation (WMI)/Common Information Model (CIM)/PowerShell)

Note

The Test-SRTopology cmdlet requires ICMPv4/ICMPv6, but not for replication or management.

What are log volume best practices?

The optimal size of the log varies widely per environment and workload, and by how much write I/O your workload performs.

  • A larger or smaller log doesn't make replication any faster or slower.
  • A larger or smaller log doesn't have any bearing on a 10-GB data volume versus a 10-TB data volume (for example).

A larger log simply collects and retains more write I/Os 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 t'ss typically slower to get back into sync. When it's in sync, it returns to using the log.

Storage Replica relies on the log for all write performance. Log performance is critical to replication performance. You must ensure that the log volume performs better than the data volume because the log serializes and sequentializes all write I/O. You should always use flash media like a solid-state drive (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.

Important

We recommend that your log storage be faster than your data storage, and that log volumes are never used for other workloads.

You can get log sizing recommendations by running the Test-SRTopology cmdlet. 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 120 GB to wrap in 120 GB divided by 50 MB per seconds, which is 2,400 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 replays blocks via the bitmap 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 because a backup can conflict with Storage Replica operations.

Which topology should I choose: stretch cluster, cluster-to-cluster, or server-to-server?

Storage Replica comes in three main configurations: stretch cluster, cluster-to-cluster, and server-to-server. Each topology has different advantages.

The stretch cluster topology is ideal if your workload requires automatic failover with orchestration, like in a Hyper-V private cloud cluster or for SQL Server FCI. It also has a built-in graphical interface, Failover Cluster Manager, for ease of use. It uses 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 if you want manual failover or when the second site is provisioned for disaster recovery and not for everyday use. Orchestration is manual. Unlike in a stretch cluster topology, you can use Storage Spaces Direct in this configuration (for caveats, see the Storage Replica FAQ and the cluster-to-cluster documentation). You can run this topology with as few as four nodes.

The server-to-server topology is ideal if you're running hardware that can't be clustered. It requires manual failover and orchestration. It's ideal for inexpensive deployments between branch offices and central datacenters, especially when you use asynchronous replication. This configuration can often replace instances of Distributed File System Replication (DFS Replication)-protected file servers that you use for single-master disaster recovery scenarios.

In all cases, the topologies support both running on physical hardware and running on virtual machines. On a virtual machine, the underlying hypervisor doesn't require Hyper-V. You can use, for example, VMware, KVM, or Xen.

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

Is Data Deduplication supported with Storage Replica?

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

Although you should install Data Deduplication on both the source and the destination servers (see Install and enable 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.

Can I replicate between Windows Server 2019 and Windows Server 2016?

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, and then re-create them with seeded data (either when you create the partnership in Windows Admin Center or by using the New-SRPartnership cmdlet).

How do I report an issue with Storage Replica or with the documentation?

For technical assistance with Storage Replica, you can post at Microsoft Q & A or contact Microsoft Business Support.

For issues with this documentation, see the Feedback section at the bottom of this page, and select This page.

Can Storage Replica be configured to replicate in both directions?

Storage Replica is a one-way replication technology. It replicates only from the source to the destination on a per-volume basis. The direction can be reversed at any time, but it still replicates in only one direction.

You can have a set of volumes (source and destination) replicated in one direction and a different set of drives (source and destination) replicated in the opposite direction.

For example, you want to have server-to-server replication configured. Server1 and Server2 each have drive letters L:, M:, N:, and O:. You want to replicate drive M: from Server1 to Server2, and replicate drive O: from Server2 to Server1. As long as there are separate log drives for each of the groups, you can use this configuration:

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

Can you place cluster disks in maintenance mode?

Storage Replica blocks any cluster disks from entering maintenance mode. For some tasks, like enabling or disabling BitLocker, the disks must be in maintenance mode. For tasks that require the disks to be in maintenance mode, the partnership must first be broken, and then created again when the task is completed.

Can you configure Storage Replica between different operating system versions?

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 capability that doesn't match between operating system versions because it was first added in Windows Server 2022. Attempting to configure a partnership with a server that doesn't support a capability returns the error "The requested operation isn't supported."

The following table shows the current log version interoperability matrix:

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

Related content