A quite interesting feature, Storage Replica (SR), appeared in Windows Server 2016 that allows to replicate the local disk volume to a remote server for disaster recovery. Volume data are automatically synchronized over your network to a secondary server where the identical copy of your volume will always be available. In Storage Replica, the data are replicated at the block level over the SMB v3.1 protocol independently of the file system type used (NTFS, CSVFS, ReFS).
Storage replication in Windows Server 2016 works in Active/Passive mode. It means that the data are available only on the source server. There are two replication modes:
- Synchronous replication – the data are written to both servers simultaneously. Prior to writing the data, the primary server is waiting for the writing confirmation from the remote server (provide zero data loss at the file system during a failure within a low-latency network).
- Asynchronous replication – the data are written to the primary server and then replicated to the secondary one (can be used to replicate data on a high-latency network, but without guarantee of identical copies of data in case of failure).
Storage Replica supports the following scenarios:
- Replication between the local volumes of the server;
- Server-to-server storage replication;
- Storage replication in the stretch cluster;
- Cluster-to-cluster storage replication.
Storage Replica Prerequisites
To use Storage Replica, your infrastructure must meet the following requirements:
- Windows Server 2016/2019 Datacenter edition;
- Both servers must be joined to the Active Directory domain;
- Each server must have two additional drives: one for data, the other one for logs. The log drive must be faster than the data drive, ideally, it is an SSD. The data drive sizes must be the same;
- GUID Partition Table (GPT) layout on a physical disks (MBR is not supported);
- Local drives (SAS/SCSI/SATA), iSCSI, SAN, shared VHD set, Storage Spaces (S2D) on SAS JBOD are supported;
- At least 2GB of free RAM on the server;
- The network throughput between the server must be at least 1 Gbit/s with less than 5 ms latency in both ways. (As a rule, this limits the distance between the replication partners to 20-50 km.) It is recommended that the network adapter supports RDMA;
- Open TCP ports 445, 5985 and 5445 between the servers.
Installing Storage Replica Feature on Windows Server 2016
You can install the Storage Replica feature on Windows Server 2016/2019 from the Server Manager console or using PowerShell:
Install-WindowsFeature Storage-Replica –IncludeManagementTools -Restart
Install the Storage-Replica feature on both servers. When you are ready, restart your servers.
How to Configure Volume Replication on Windows Server 2016?
Storage Replication does not have an integrated graphical management console. To configure storage replication, you can use PowerShell, Windows Admin Center or Failover Clustering console (if you are using the cluster).
You can display the list of available PowerShell cmdlets in the StorageReplica module as follows:
Get-Command -Module storagereplica
Using the Test-SRTopology command, you can make sure if your server and netwok meet the Storage Replica requirements. You can estimate the current number of I/O operations, network throughput, log sizes. The Test-SRTopology cmdlet generates an HTML report with current loads and recommendations.
Enable the replication of D: drive between two separate servers Server1 and Server2 (Disk L: is used for logs, the log size is 1GB.):
New-SRPartnership -SourceComputerName Server1 -SourceRGName Server1ReplGr01 -SourceVolumeName E: -SourceLogVolumeName L: -DestinationComputerName Server2 -DestinationRGName Server2ReplGr01 -DestinationVolumeName D: -DestinationLogVolumeName E: -LogSizeInBytes 1GB
After you enable replication on the secondary server, the data disk becomes unavailable for direct access (RAW format).
You can get more volume replication information using the additional performance counters in PerfMon or from PowerShell:
Get-Counter -Counter “\Storage Replica Statistics(*)
You can monitor the volume replication events using the Event Viewer (Applications and Services Logs -> Microsoft -> Windows -> StorageReplica) or from PowerShell:
Get-WinEvent -ProviderName Microsoft-Windows-StorageReplica -max 20
You can switch the replication mode to asynchronous using this command:
Set-SRPartnership -ReplicationMode Asynchronous
In case of primary server failure, you can manually change the direction of data replication by putting the secondary copy online:
Set-SRPartnership -NewSourceComputerName Server2 -SourceRGName Server2ReplGr01 -DestinationComputerName Server1 -DestinationRGName Server1ReplGr01
To get the replication group state and the direction of replication, use the Get-SRGroup and Get-SRPartnerShip cmdlets.
You can view the length of the copy queue:
(Get-SRGroup).Replicas | Select-Object numofbytesremaining
To disable the storage replication:
Get-SRPartnership | Remove-SRPartnership (on the primary server only)
Get-SRGroup | Remove-SRGroup (on both servers)
Many companies use DFS replication between datacenters as a solution to replicate data storage. SR has some advantages over DFS replication: the data are copied at the block level (replication of open or in-use files, as well as VSS snapshots is possible); database independence; fast and synchronous replication (no need to wait for hours or days like in DFS). However, SR has some disadvantages: only 1-to-1 replication; high network throughput and latency requirements; without a cluster, the direction of the replication is switched manually, as well as reconfiguration of apps (users) to a new server (you can simplify it by using common DFS namespace).
In Windows Server 2019 Build 17650, Storage Replica is available in the Standard edition as well (you can replicate only 1 volume up to 2TB to one replication partner). In addition, the Test Failover mode has appeared. In this mode, a partner replica volume is writable, and the replication stops until the Test Failover mode is disabled (all changes made in this mode are rolled back to the snapshot).