The Storage Replica feature in Windows Server 2016 delivers a backup and recovery option for organizations that might otherwise require an offsite data center.
Most Windows Server administrators will find themselves resorting to a convoluted system to ensure data is copied and backed up to another server. There has to be a better way than using a custom DOS-style Xcopy-based batch file and scripting routines or a cumbersome, separately licensed backup software.
Windows Server 2016 might have the solution with Storage Replica, a remarkable addition that provides near-instant backups and recoveries for organizations that don't have expensive off-site data centers running on standby.
Storage Replica acts as a carbon copy for protected assets. It provides block-level, synchronous replication of a volume on one system to a volume on another system. Storage Replica can be used for disaster recovery deployment or for high availability. Admins can link different geographical sites then deploy a failover cluster between them using Storage Replica. This type of Windows Server replication occurs asynchronously, which creates a potential of data loss, a potential which varies based on the distance between sites, link speed and other factors.
The Storage Replica model
Storage Replica uses two different models to replicate data between a source and a target:
Storage Replica acts as a carbon copy for protected assets. It provides block-level, synchronous replication of a volume on one system to a volume on another system.
Synchronous replication, which is suited for use when the source and target are within the same data center or physical site. With this method, Storage Replica grabs the data from an application's memory and writes it to two different locations simultaneously before the I/O operation completes. This requires powerful hardware that works with SMB 3.0 and InfiniBand to write big files quickly over a network.
Asynchronous replication, which is ideal for a disaster-recovery scenario with a "hot" standby site in a different physical location that should take action if the primary site experiences issues. This communication and replication happens over a longer link -- perhaps a VPN or even over the internet -- and has a higher data loss margin but it offsets that risk by handling substantial physical distances between the source and target.
How to set up Storage Replica
Setting up asynchronous replication and stretching over a failover cluster is more complex than setting up a simple mirror that is wholly contained within a site, so we can address that in another article.
For this exercise, we need two servers with a C: volume and two separate volumes with the letters D: and E:. The volumes labeled D: and E: should be the same capacity on both servers. Initialize both of these volumes as GPT, not MBR volumes. Next:
Use Server Manager to install the File Server role and the Storage Replica feature. This will require a reboot but it only installs code; no configuration is required.
After reboot, use those PowerShell code to create a replication partnership between the two machines:
Make sure the configuration is valid by using the Get-SRGroup and Get-SRPartnership PowerShell commands to verify the Windows Server replication status. You should see values for ReplicationMode equaling Synchronous and ReplicationStatus equaling ContinuouslyReplicating.
The initial block level sync will take some time. Wait until this activity dies down before attempting to use Storage Replica in production.
To put data in the replica, just copy some data. Do this on server 1, since it is the source machine. Copy a folder to the D: volume. Wait for the replication activity to subside -- use the Task Manager to check the CPU activity or look at Performance Monitor by adding the Storage Replica statistics counters to a view -- data has been replicated.
To simulate a disaster, use the following PowerShell code to reverse the flow of the replication from SERVER2 to SERVER1:
The Storage Replica feature is still somewhat in flux and some of the PowerShell commands do not work the expected manner -- for example, they do not work in a remoting session; they must be run locally on each machine. But Microsoft has the makings of an outstanding feature that, for some applications, could be well worth the cost of admission into Windows Server 2016.
