What Is Storage Replication?

Storage replication is the process of copying data from one storage system to another, continuously or on a schedule, so that a recent copy is available on a second system if the first one fails. The copy, called a replica, can sit in the same data center or at a remote site. It can be made by a storage array, server operating system, hypervisor, or cloud storage service. Storage replication is an important component of cyber resilience, particularly for disaster recovery and business continuity.

This article explains the difference between storage and data replication, how storage replication works, where it runs, what shapes a replication strategy, and how Everpure approaches replication.

Storage replication vs. data replication

Storage replication is a type of data replication. The key difference is what gets replicated and at which layer of the IT infrastructure. Storage replication focuses on maintaining copies of data at the infrastructure level, typically without requiring applications to manage the replication process. Data replication is the broader practice of maintaining copies of data across systems or locations, regardless of the underlying technology.

How storage replication works

Every replication relationship has a source, also called the primary, and a target, also called the secondary or replica. Replication engines generally copy the full data set first and then send only the changes. Proxmox VE documentation, for example, describes sending new data incrementally after the initial full sync.

What separates synchronous from asynchronous replication is when the source acknowledges a write to the application. That decision sets how much recent data can be lost in a failure and how far apart the two copies can be.

Synchronous replication

In synchronous replication, data must be committed to stable storage at both the primary and the secondary site before the write is acknowledged to the host. While both sites are in sync, the result is a recovery point objective (RPO) of zero.

The tradeoff is write latency. Every write includes a round trip to the second site, so distance is limited by how much added latency applications can absorb. In its Storage Replica documentation, Microsoft recommends an average round-trip latency of 5ms or less for synchronous replication.

Asynchronous replication

In asynchronous replication, the write is acknowledged once it’s committed at the primary site, and the data is forwarded to the secondary site as permitted by networking capabilities. Applications don’t wait on the remote site, so asynchronous replication works over long distances.

The cost, or tradeoff, of asynchronous replication is a non-zero recovery point objective (RPO). If the source fails before recent writes reach the target, those writes are missing from the replica and can be lost. The gap between the source and the replica is called replication lag.

Asynchronous replication can be periodic or continuous. Periodic replication sends the changes between snapshots on a schedule, as Proxmox VE does. Continuous asynchronous replication streams changes to the target as they occur, without waiting for the target’s acknowledgment. Microsoft states that Storage Replica, which replicates continuously, theoretically has a lower RPO.

Types of storage replication

Storage replication software exists at several layers of the stack. Each layer copies a different unit of data and is managed by a different system.

Array-based (SAN) replication

Array-based replication, also called storage-based or storage area network (SAN) replication, is performed by the storage array’s operating system. The array copies volumes to a second array at the block level, independently of the hosts that write to them.

Host-based replication

Host-based replication runs on the server. Windows Server Storage Replica, which Microsoft classifies as host-based, replicates volumes between servers or clusters at the block level and supports both synchronous and asynchronous replication.

Hypervisor-based replication

Hypervisor-based replication copies individual virtual machines. Broadcom describes VMware vSphere Replication as hypervisor-based virtual machine replication and “an alternative to storage-based replication.” Proxmox VE replicates guest volumes to another node on a schedule, with intervals from one minute to once a week.

Application and database replication

Above the storage layer, databases replicate their own transactions. In SQL Server Always On availability groups, the availability mode sets this behavior: asynchronous-commit mode does not wait for secondary replicas to harden the transaction log, while synchronous-commit mode waits for that confirmation at the cost of increased transaction latency. Oracle database replication is another example. Application-level replication works with transactions, while storage-level replication copies the volumes underneath, whatever writes to them.

Cloud and object replication

Cloud object storage services replicate between buckets. AWS documents Amazon S3 Replication as automatic, asynchronous copying of objects, either across AWS Regions or within one Region.

Local, metro, and remote replication

Replication is often grouped into three tiers by the distance between source and target:

• Local replication: The source and target sit in the same data center. This protects against the failure of a system, but not the loss of the site.
• Metro replication: The sites are close enough, typically within a metropolitan area, for synchronous replication to stay inside the application’s latency budget. Stretched clusters, in which hosts at both sites work with the same data, are typically built on this tier.
• Remote replication: The target sits far enough away to survive a regional event. Remote links typically use asynchronous replication, which keeps the round trip to the remote site out of each write.

Designs can combine tiers. SNIA notes that data may be replicated to multiple secondary sites. One three-site design replicates synchronously between two nearby sites and asynchronously to a distant third, pairing zero RPO between the first two sites with protection against a regional outage.

Active-active vs. active-passive replication

In an active-passive configuration, the target holds a replica on standby until a failover promotes it. In an active-active configuration, both sites can provide simultaneous read and write access to shared volumes. However, applications and host clusters must coordinate concurrent access to maintain data consistency. At the storage layer, read and write access to the same volume from both sites typically relies on synchronous replication, so every write reaches both copies before it’s acknowledged.

Factors that shape a storage replication strategy

A replication strategy is a set of choices about mode, layer, distance, and the recovery process.

RPO and RTO

The National Institute of Standards and Technology (NIST), in SP 800-34 Rev. 1, defines the recovery point objective as the point in time to which data must be recovered after an outage. It defines the recovery time objective (RTO) as how long a system’s components can be in the recovery phase before the organization’s mission or business processes are affected.

A zero RPO on a replica requires synchronous replication. With scheduled asynchronous replication, the data written since the last completed sync is at risk, so the interval is set against the RPO. RTO depends on the recovery process: how quickly applications can restart against the replica. See RTO vs. RPO.

Distance, latency, and bandwidth

Round-trip latency, which grows with distance, determines whether synchronous replication is practical. Bandwidth, measured against the write rate, determines whether replication keeps up. Microsoft’s Storage Replica prerequisites call for a network with enough bandwidth to contain the input/output (I/O) write workload. In asynchronous replication, data moves as the network permits, so when writes arrive faster than the link can carry them, replication lag grows.

Consistency groups and write ordering

Applications that spread data across several volumes, such as a database with separate data and log volumes, need those volumes replicated as a unit. SNIA defines a consistency group as “a collection of replication sets grouped together to ensure write order consistency across all the replication sets’ primary volumes.” Without one, a replica could hold one volume’s latest writes alongside another volume’s older state.

Failover, failback, and DR testing

Failover moves workloads to the replica when the primary is unavailable. Failback returns them once the original site is repaired.

The replication mode can limit which failovers are possible. In SQL Server availability groups, synchronous-commit mode supports manual and, optionally, automatic failover once the secondary is synchronized, while asynchronous-commit mode supports only forced failover, with possible data loss. A DR test runs the failover process against the replica without waiting for a real outage.

Why storage replication doesn’t stop ransomware on its own

Replication reproduces all changes, including unintended ones. Storage replication is not a backup solution. It replicates all changes to all blocks on the volume, regardless of the change type, so if a user deletes all data from a volume, the deletion can replicate to both servers.

The same applies to ransomware. Encryption is a change to data, and a replication engine that copies every change copies the encrypted data to the replica. Recovery from an attack depends on point-in-time copies that the attack cannot alter or delete, such as immutable snapshots that are also protected from early deletion, isolated backups kept under a 3-2-1 backup strategy, and a cyber recovery environment.

Replication and point-in-time copies cover different failures. Replication keeps a current copy ready for failover after a hardware or site failure. Point-in-time copies make it possible to return to the state before corruption or encryption began. For definitions of each, see snapshots vs. backups vs. replication.

Why organizations use storage replication

• Disaster recovery and business continuity: A replica at a remote site lets workloads restart after a site-wide outage.
• High availability: Synchronous replication with automatic failover can keep applications running through the loss of one system.
• Data migration: Replicating to a new system ahead of a cutover moves data while the source stays in service. See the data migration strategy guide.

How Everpure helps with storage replication

Everpure™ FlashArray™ includes synchronous, continuous asynchronous, and periodic asynchronous replication in the Purity//FA operating environment.

• ActiveCluster™: Synchronous replication between two FlashArray systems. In normal operation, a write is not acknowledged to the host until it’s protected in NVRAM on both arrays, which gives ActiveCluster its zero-RPO behavior at the storage layer. ActiveCluster also provides automatic failover and active-active access to stretched volumes across two sites.
• ActiveDR™: Continuous asynchronous replication with a near-zero RPO. The source array confirms host writes without waiting for the target array to acknowledge them, so distance between the arrays adds no latency for host applications. Failover is manual or API-driven, and DR tests can run while replication continues.
• Protection groups: For periodic, snapshot-based replication, FlashArray protection groups set the snapshot schedule and replication schedule separately. They group related volumes under shared protection policies, allowing them to be protected and replicated together.
• Three-site resilience: Starting with Purity//FA 6.10.5, released April 1, 2026, three-site configurations combine ActiveCluster synchronous replication across metro sites with ActiveDR asynchronous replication to a remote third site. This architecture provides zero-RPO protection between synchronized metro sites and additional disaster recovery protection against regional outages. Actual recovery objectives depend on configuration and application recovery procedures.
• FlashBlade: For unstructured data, the Purity operating environment on FlashBlade includes file replication and object replication.
• Cloud offload: Purity CloudSnap™ offloads FlashArray snapshots to AWS or Azure for an off-site, long-term copy.

SafeMode™ Snapshots lock protection-group snapshots against early deletion. No single person, not even an administrator, can eradicate a protected snapshot before its scheduled roll-off, and snapshot frequency and retention cannot be unilaterally lowered. Everpure ransomware recovery guidance advises pausing replication to secondary sites during an attack so encrypted data does not overwrite clean copies.

Learn more about Everpure cyber resilience solutions.

Conclusion

Every storage replication design trades distance against data loss. Synchronous replication keeps a zero RPO within the latency a metro link allows, and asynchronous replication accepts a non-zero RPO to reach a distant site. The layer where replication runs decides what is protected as a unit, from a whole array to a single virtual machine or bucket.

What replication does not do is preserve the past. A replica mirrors the source, including corruption and encryption, so a design that relies on replication alone keeps systems available without keeping data recoverable. Recovery from both kinds of failure takes a current replica and protected point-in-time copies.

Storage replication FAQs

What are the two types of replication?

Storage replication is usually divided into synchronous and asynchronous modes. Synchronous replication acknowledges a write only after both sites have committed it, giving a zero RPO but adding write latency that limits distance. Asynchronous replication acknowledges the write at the primary first and forwards it afterward, so it works over long distances but can lose recent writes.

What is the difference between data backup and replication?

Replication maintains a current copy of data on a second system so workloads can fail over quickly. Backup keeps point-in-time copies so data can be restored to an earlier state. Replication copies every change, including deletions and encryption, so it does not replace backup.

What is replication lag?

Replication lag is the delay between a write landing on the source and the same write reaching the replica. While synchronous replication is in sync, the replica already holds every acknowledged write, so there is no lag. In asynchronous replication, lag depends on the write rate, the link’s bandwidth, and the replication schedule, and it sets how much recent data could be lost.

What is storage replication software?

Storage replication software copies data between storage systems and manages the relationship between source and target. It can be built into a storage array’s operating system, a server operating system such as Windows Server Storage Replica, a hypervisor feature such as VMware vSphere Replication, a database engine such as SQL Server Always On availability groups, or a cloud service such as Amazon S3 Replication.