SAN-to-SAN Replication Over a WAN: A Practical Guide
Plan SAN-to-SAN replication with the right synchronous, asynchronous, or file-level method, realistic bandwidth math, and a tested cutover runbook.
When an application must recover at another site, moving the first copy is only part of the job. The destination also needs a sufficiently recent, consistent state and a tested way to take over. Those requirements determine the replication mode and the network capacity it needs.
SAN-to-SAN replication copies block-storage changes using compatible array or storage-virtualization features. This guide explains when remote writes must be acknowledged synchronously, when asynchronous replication is practical, and how to plan the baseline and cutover. A file migration remains a separate option when the destination needs selected files rather than a block replica.
SAN replication methods at a glance
| Method | When a source write completes | Best fit | Main tradeoff |
|---|---|---|---|
| Synchronous block replication | After the remote copy is acknowledged, according to the selected vendor mode | Zero-RPO designs across a supported low-latency topology | WAN latency enters the application write path; loss of the relationship can pause I/O or relax protection depending on policy |
| Asynchronous block replication | Before the remote copy is committed | Longer distance, higher latency, or a defined nonzero RPO | The destination can lag; journals, schedules, and catch-up capacity must be sized |
| File-level migration or seed | Per file, chunk, or job rather than per source LUN write | Moving selected datasets, creating an ordinary readable copy, or staging a migration | Does not reproduce block semantics, array snapshots, consistency groups, or storage failover |
IBM describes Metro Mirror as synchronous and Global Mirror as asynchronous in its Remote Mirror and Copy documentation. Dell likewise documents SRDF synchronous and asynchronous modes and makes the acknowledgment point part of the mode definition in the PowerMax SRDF product guide. These are product examples, not interchangeable implementations.
Synchronous replication: protect every acknowledged write
Synchronous replication can support a zero recovery point while the relationship is healthy and in sync. That guarantee is conditional: hosts, arrays, links, consistency-group design, quorum or mediator components, and the selected failure policy all matter.
The latency cost is structural. If the storage system waits for a remote commit before acknowledging the host write, the WAN round trip becomes part of that write. Test the application at the real site-to-site RTT, not only with a bandwidth test. Also decide what should happen when the remote site or link fails: continue local I/O without zero-RPO protection, or stop writes to preserve identical copies. NetApp documents both Sync and StrictSync behavior in its SnapMirror Synchronous guide.
Asynchronous replication: accept bounded lag
Asynchronous replication lets the primary acknowledge writes before they are committed remotely. That removes the remote acknowledgment from the foreground write path, but the design now needs an explicit lag target and enough capacity to catch up after a burst or outage.
Define the recovery point in time, not with labels such as “near real time.” NIST defines the recovery point objective (RPO) as the point before disruption to which data must be recovered, and the recovery time objective (RTO) as the maximum time a resource can remain unavailable before impact becomes unacceptable. Record both before selecting a replication mode. See NIST SP 800-34 Rev. 1.
File-level transfer: useful, but not a block replica
A file copy can be the right migration tool when the destination only needs ordinary files and permissions that the chosen tool preserves. It can also stage a large baseline so that the final cutover transfers only changes. It is not SAN replication: applications may have open or internally inconsistent files, destination LUN identifiers differ, and array-native failover is absent.
Use the 100 TB migration runbook for manifests, checksums, delta passes, and rollback planning. If the source contains millions of entries, test the actual directory shape with the small-file transfer guide rather than extrapolating from one large file.
Calculate baseline time and replication headroom
Start with two separate numbers: initial baseline size and ongoing write-change rate.
Baseline seconds = bytes to copy × 8 ÷ sustained bits per second
For a decimal 100 TB baseline on a 1 Gbps circuit, reserving 30% for overhead and other traffic leaves 700 Mbps:
100,000,000,000,000 × 8 ÷ 700,000,000 ≈ 1,142,857 seconds, or 13.2 days
That is only a payload lower bound. Storage reads, remote writes, snapshots, compression, deduplication, encryption, retransmission, consistency processing, and other traffic can extend it. Use the 1 TB transfer-time calculator with a measured sustained rate, then scale with the actual changed-data volume.
For steady-state replication, calculate:
Required payload rate = changed bytes during peak interval × 8 ÷ interval seconds
If the source changes by 2 TB during a 10-hour peak window, the average payload rate is about 444 Mbps before overhead and catch-up headroom. A design that merely equals that average will fall behind during bursts and after link interruptions.
Include the bandwidth-delay product
At 1 Gbps and 80 ms RTT, the bandwidth-delay product is:
1,000,000,000 bits/s × 0.080 s ÷ 8 = 10 MB in flight
That is not a complete buffer-sizing prescription, but it shows why a high-bandwidth, long-RTT path needs enough data in flight. IETF RFC 7323 defines TCP Window Scale for high bandwidth-delay-product paths. Array protocols may add multiple streams, compression, or proprietary transports; validate the vendor’s supported network design rather than assuming a generic TCP tweak applies.
A seven-step SAN-to-SAN replication plan
1. Define the recovery contract
List every application using the volumes. For each one, record RPO, RTO, dependency order, acceptable write latency, and who can authorize failover. A single array relationship may contain databases, file systems, and services with different consistency requirements.
2. Prove array and host compatibility
Confirm source and destination models, software versions, licenses, replication mode, maximum supported distance or latency, LUN and consistency-group limits, host multipathing, quorum or mediator requirements, encryption, and network ports in the vendor’s current interoperability matrix.
3. Capture application-consistent points
Crash-consistent blocks are not automatically application-consistent transactions. Coordinate database quiesce, VM consistency, filesystem freeze, or application-aware snapshot hooks as required. Put dependent volumes in the same supported consistency group.
4. Measure the real path
Record RTT, loss, jitter, usable throughput in both directions, MTU, routing, encryption overhead, and failover-path capacity. Compare peak changed bytes per interval with the sustained replication rate and catch-up time.
5. Initialize and observe the baseline
Start the baseline outside critical windows where possible. Track source read latency, application impact, destination write latency, link use, compression or reduction ratio, replication lag, and resynchronization behavior. Do not declare success when the dashboard first says “in sync”; verify the application-level copy.
6. Run delta passes and rehearse cutover
Freeze or control writes, take the final consistent point, wait for the target state, fence the old writer, promote the destination, rescan host paths, mount or import volumes, and start applications in dependency order. Microsoft’s Storage Migration Service uses an analogous inventory, transfer, validate, and cutover sequence for file-server migrations; the exact SAN commands remain product-specific.
7. Test failback and evidence
Record the achieved RPO and RTO, application checks, write/read tests, replica state, logs, and rollback decision. Rehearse failback before an emergency. A recovery design that has only been failed over in one direction is incomplete.
Validation checklist
| Check | Evidence to save | Failure it catches |
|---|---|---|
| Application consistency | Snapshot or quiesce log plus application recovery check | A block-consistent but unusable database or VM set |
| Replica currency | Source and destination checkpoints with measured lag | An RPO that exists only on paper |
| Host access | Multipath, LUN identity, filesystem, and mount validation | A healthy array copy that hosts cannot use |
| Performance | Application latency and throughput before, during, and after replication | A synchronous design that meets RPO but breaks production latency |
| Isolation | Fencing or write-prevention evidence for the old primary | Split-brain writes during cutover |
| Rollback | Timed failback steps and decision point | No safe route back after a failed promotion |
| Data validation | Application checks plus bounded checksums or manifests | Silent omission or corruption in a file-level migration |
Where WarpSend fits—and where it does not
WarpSend is a file-level transfer and sync product. When a SAN-hosted filesystem is mounted on a supported Windows, macOS, or Linux endpoint, WarpDirect or WarpSync can be evaluated for moving ordinary files to another supported endpoint. That can fit a selected-dataset migration, an initial file seed, or a recurring file workflow.
It does not implement the storage array’s remote-copy protocol, create a destination LUN replica, preserve array snapshot history, coordinate application-consistent block groups, or provide automatic SAN failover. Keep the array-native replication design when those semantics are required. Review high-speed file transfer over long distance for WAN transfer bottlenecks, and WarpSend’s feature boundaries before a proof of concept.
Primary sources
- NIST SP 800-34 Rev. 1: RPO and RTO definitions
- NetApp ONTAP SnapMirror replication workflow
- NetApp SnapMirror Synchronous behavior
- Dell PowerMax SRDF modes of operation
- IBM Remote Mirror and Copy
- IETF RFC 7323: TCP Extensions for High Performance
- Microsoft Storage Migration Service transfer and cutover
Sources were checked on August 10, 2026. Vendor capabilities and support matrices change; verify the documentation for the exact array model and software release in the project.
Start a WarpSend test only when the requirement is a file-level seed or migration between supported endpoints. Use the storage vendor’s replication stack when the project requires LUN, snapshot, consistency-group, or automatic failover semantics.
Frequently asked questions
What is SAN-to-SAN replication?
SAN-to-SAN replication copies block-storage changes from a source array or virtualized storage system to a compatible destination. Depending on the product and mode, writes are acknowledged after both sites commit them or are sent asynchronously. It is different from copying files between mounted shares.
Should SAN replication over a WAN be synchronous or asynchronous?
Use synchronous replication only when the required RPO, supported distance, measured latency, and application write-latency budget all fit the storage vendor’s design. Use asynchronous replication when distance or latency makes remote write acknowledgment unacceptable and the business can tolerate a defined nonzero RPO.
How much bandwidth does SAN replication need?
Capacity must cover the sustained change rate plus protocol overhead, retransmission, catch-up after outages, and the initial baseline. Measure changed bytes in peak periods rather than sizing only from total capacity, and keep operational headroom instead of planning at 100 percent link utilization.
Can WarpSend replace SAN replication?
No. WarpSend moves ordinary files and folders between supported endpoints; it does not create block-level LUN replicas, storage-array consistency groups, automatic SAN failover, or a zero-RPO relationship. It can be evaluated for a file-level seed or migration when the dataset is mounted on a supported endpoint.
How do you test a SAN replication cutover?
Document the RPO and RTO, capture a consistent application checkpoint, verify the replica, isolate or fence the old writer, promote the destination, rescan host paths, start applications in dependency order, validate writes and reads, and rehearse failback. A green replication status alone is not a recovery test.