Protecting Data and Keeping Another Usable Volume Were Different Problems
Backing up a server provides a way to recover information after something goes wrong, but recovery can involve locating the backup, restoring the data, and preparing storage before applications can begin using it again.
Organizations that needed stronger continuity could maintain another copy of important storage somewhere else. Traditionally, sophisticated replication capabilities were often associated with specialized storage systems rather than the Windows Server operating system itself.
Windows Server 2016 introduced Storage Replica to bring block-level storage replication directly into the server platform.
Recovery Could Depend on More Than Having a Backup
A second maintained volume could provide a different recovery option from rebuilding storage by restoring files after the original system had already failed.
Windows Could Reproduce Changes at the Block Level
Storage Replica operates at the volume level rather than functioning as an ordinary file-copying system.
When applications change information on a protected volume, the corresponding storage changes can be replicated to another volume. The replication process therefore does not depend on individually selecting documents, folders, or application files for copying.
This made the technology suitable for protecting many types of data because the replication mechanism worked with storage blocks underneath the files themselves.
The Replication System Did Not Need to Understand Every File
By working below the file level, Storage Replica could protect volume data without requiring the replication engine to interpret the purpose or format of each file stored there.
Replication Did Not Require a Complete Failover Cluster
Disaster-recovery technologies are often associated with clusters, but not every organization needs a large clustered infrastructure merely to maintain another copy of important storage.
Storage Replica supported server-to-server replication, allowing volumes on one Windows Server system to be replicated to another server.
The two machines could therefore maintain a storage relationship without requiring every deployment to begin as a traditional multi-node application cluster.
Two Servers Could Form the Replication Relationship
A source server and destination server could maintain replicated storage even when the broader workload did not require a conventional failover cluster.
Distance Could Protect Data From More Than a Failed Drive
Keeping redundant storage inside one server protects against some hardware failures, but it cannot protect the organization from every event affecting that location.
A serious power problem, building outage, fire, flood, or other site-level disruption can affect several systems at once. Maintaining replicated data at another location creates a boundary between the original storage and the event threatening it.
Storage Replica was designed to support replication across different failure domains, including systems located in separate sites.
Redundancy Became More Valuable When the Copies Did Not Share the Same Risk
Separating replicated storage geographically could preserve another copy even when the problem extended beyond an individual disk, enclosure, or server.
A Write Could Be Confirmed Only After the Remote Copy Had It
For environments where losing the newest committed data was unacceptable, Storage Replica supported synchronous replication.
With this approach, write operations are committed to both locations before the application receives confirmation that the write has completed. The remote storage therefore remains closely synchronized with the source.
If the primary system is lost after a confirmed write, the destination can contain the same committed data rather than lagging behind by a group of recently completed changes.
Confirmation Could Wait for the Second Location
Synchronous replication prioritized consistency between the two copies by ensuring the remote side received the write before the operation was acknowledged as complete.
The Speed of the Connection Could Affect Every Synchronous Write
Waiting for another location has consequences. Data must travel to the destination and acknowledgment must return before the source can complete a synchronous operation.
As network latency increases, that round trip can affect application storage performance. Synchronous replication is therefore most practical when the connection between locations is sufficiently fast and reliable for the workload.
No software feature can eliminate the time required for information to travel across a network.
Zero Data Loss Came With Network Requirements
Keeping two locations synchronously aligned could provide extremely strong protection, but the latency between those locations became part of the storage path experienced by the application.
The Primary Server Could Continue Before the Remote Write Finished
Longer distances or slower links can make waiting for every remote write impractical. Storage Replica also supported asynchronous replication for situations where the source needed to continue without waiting for the destination to confirm each change.
The primary storage could acknowledge writes locally while changes were transferred to the remote side afterward.
This reduced the performance dependence on network round-trip latency, although a sudden loss of the source could mean the newest changes had not yet reached the destination.
More Distance Could Mean Accepting Some Replication Lag
Asynchronous replication allowed greater flexibility across slower or more distant connections by trading the guarantee of an immediately identical remote copy for reduced write latency.
Replication Needed More Than Simply Sending Blocks Across the Network
Storage writes occur continuously and their ordering can matter to the consistency of the data stored on a volume.
Storage Replica uses a log volume as part of the replication process. Changes are recorded so they can be transferred and applied appropriately to the destination.
The replicated data volume and the replication log therefore perform different jobs even though both participate in protecting the workload.
The Log Was Part of the Replication Machinery
The destination was not maintained by periodically copying whatever files happened to look different; Windows tracked storage changes as part of an organized replication process.
Storage Replication Could Support Workloads Across Locations
Storage Replica also integrated with Windows failover clustering. A stretch-cluster design could place cluster nodes in separate locations while replicated storage helped protect the data required by the workload.
This allowed the failure boundary of a highly available system to extend beyond one rack or building.
When planned with suitable networking, storage, quorum, and application behavior, the architecture could prepare workloads for failures affecting an entire site rather than only an individual server.
The Cluster Boundary Could Extend to the Disaster-Recovery Site
Replication made it possible for clustered infrastructure in different locations to maintain the storage needed for workloads that might have to move after a major failure.
Windows Could Provide a Capability Once Associated With the Array
Enterprise storage systems had long offered replication technologies of their own. Those systems could be powerful, but the replication feature was tied to the capabilities and architecture of the storage platform.
Storage Replica moved the replication mechanism into Windows Server and was designed to work independently of a particular storage vendor’s proprietary replication implementation.
This gave the operating system a more direct role in building disaster-recovery storage architectures.
Replication Could Belong to the Server Instead of the Storage Array
Organizations could build supported replication around Windows Server volumes without requiring the underlying storage hardware itself to provide the replication engine.
A Perfect Second Copy Could Also Reproduce an Unwanted Change
Replication is powerful because changes made to the source are transferred to another location. That same characteristic means replication should not be confused with maintaining historical backup versions.
If data is deliberately changed, corrupted by an application, or removed in a way that becomes part of the replicated workload, the second location is designed to follow the storage changes rather than act as a permanent untouched archive.
Backup and replication therefore complement each other. Replication can improve continuity after infrastructure failure, while backups can provide historical recovery points for situations where an earlier version of the data is required.
A Second Live Copy Was Not a Time Machine
Replication protected against losing access to the original storage, but a separate backup strategy remained important when recovery required returning to data from an earlier point in time.
The Operating System Could Maintain Storage Beyond the Machine Running It
Windows Server had long provided file services, clustering, storage management, and application infrastructure. Storage Replica added another responsibility by allowing the operating system to coordinate a protected copy of volume data elsewhere.
The second copy could reside on another server, another cluster, or infrastructure in another location depending on the deployment design.
That turned storage replication from something necessarily external to Windows into a capability that could be designed directly into the server environment.
The important volume no longer had to exist in only one place when Windows itself could maintain another copy somewhere safer.
Storage Replica Extended Windows Storage Beyond a Single Location
Storage Replica gave Windows Server a block-level replication system for maintaining protected volumes on other servers or at other sites. Synchronous replication could keep committed data closely aligned between locations, while asynchronous replication provided an option for environments where distance made waiting for every remote write impractical.
Server-to-server replication allowed relatively simple configurations, while cluster-to-cluster and stretch-cluster designs could support larger high-availability and disaster-recovery environments.
The result was a new relationship between Windows Server and its storage. Protecting a volume no longer had to end with the disks attached to one machine or even the equipment inside one building. The operating system could help maintain that data across a much larger failure boundary.
