Stretched Cluster vs. Replication for S3 Backup Targets
Table of Contents
When a primary site loses power halfway through a backup job, what the job was told, what sits on disk at each site and what happens at the next run all depend on how the two sites were joined.
A stretched cluster is one object-storage cluster with nodes in two sites. It acknowledges a write only after both sites hold it. Replication keeps two independent systems and copies data from one to the other, either before or after the acknowledgment.
Microsoft states the mechanics plainly in its documentation on Storage Replica. Synchronous replication guarantees that the application writes data to two locations at once before the I/O completes. The two designs answer different questions, and the difference shows up in what happens to a write when a site fails.
What Is the Difference Between a Stretched Cluster and Replication?
A stretched cluster is a single cluster with one control plane spread across two sites. A write is complete only when both sites hold it. Replication joins two separate systems, each with its own control plane. It copies data between them either before the acknowledgment (synchronous) or after it (asynchronous).
Microsoft describes the stretched topology in its guidance on failover clustering topologies. The cluster is extended across two geographically separated sites over a high-speed wide area network (WAN). Replication leaves two clusters that exchange data. A fault, a bad configuration change or a compromised administrator account in one does not automatically exist in the other.
The second difference is the failure domain. A stretched cluster has one logical system to break, one software version and one set of credentials. That suits availability and weakens protection. Because every client write is synchronously replicated, a stretched cluster has a recovery point objective (RPO) of zero for acknowledged writes.
| Property | Stretched cluster | Synchronous replication | Asynchronous replication |
|---|---|---|---|
| Control plane | One shared by both sites | Two, one per site | Two, one per site |
| Acknowledgment | After both sites hold the write | After the replica write completes | Immediately, replicated afterward |
| RPO | Zero for acknowledged writes, while quorum holds | Zero for acknowledged writes | Above zero; set by replication lag |
| Write latency | Adds at least one inter-site round trip | Adds at least one inter-site round trip | Local write latency |
| Quorum need | Yes, usually a third location | No shared quorum | No shared quorum |
| Exposure to deletion and encryption | Mirrored at link speed | Mirrored at link speed | Mirrored after the lag, unless the copy is immutable |
What Happens to Writes When a Site Fails?
When a site fails, the surviving site keeps accepting writes only if it can prove it holds the majority. Three cases cover the ground.
The first case is a stretched cluster that keeps quorum. The cluster persists a write at both sites and only then returns the acknowledgment. If site A dies, site B still holds every acknowledged write. The cluster then enters a degraded mode and carries on with fewer copies. The cost is capacity, because each site must hold its own full set of copies.
The second case is a stretched cluster that loses quorum. Suppose the link fails but both sites are alive. Each side sees its peer vanish. Neither can tell a dead peer from a cut cable. Without a tiebreaker, a safe system stops accepting writes on at least one side. The alternative is split-brain, where both sides accept writes and the histories conflict. A backup job writing to the stalled side sees timeouts, not data loss.
The third case is asynchronous replication. The local system acknowledges at once and copies the data afterward. Microsoft documentation notes a risk of data loss if the source is lost while the destination copy was still in buffer mode. That unreplicated tail is the RPO. It holds acknowledged writes that exist only at a site that is now dark.
Does Synchronous Replication Guarantee Zero Data Loss?
No. It guarantees that no acknowledged write is lost. A write still in flight when the power failed was never acknowledged, so the client must treat it as undelivered. For a backup job this matters less than it first appears. The backup software knows which writes completed and can repeat the rest.
What Happens to a Running Backup Job at Failover?
A running job loses the restore point it was writing. It does not lose the restore points already completed. The backup software notices the failed or timed-out writes and retries according to its policy. If the target stays unavailable, the next scheduled run is the next chance to produce a restore point.
Veeam documents its retry behaviour in the Veeam user guide on job retry. By default, Veeam Backup & Replication retries a failed job three times within one job session. A retry processes only the failed tasks. No retry runs if the session finished with Success or Warning. If the target returns inside the retry window, the job can complete. If not, the session ends as failed and the next scheduled run begins fresh.
The RPO of the repository is not the RPO of the protected workload. A repository RPO of zero means no acknowledged backup data is lost. A workload RPO is the age of the newest complete restore point, and the job schedule bounds it. If a server is backed up every four hours, the exposure after a site loss is at most the time since the last completed restore point. That holds for any repository design. A stretched cluster cannot make the workload RPO better than the schedule allows. Its value is that completed restore points survive.
Repository layout adds a second layer. Veeam describes a scale-out backup repository as a multi-tier system. A performance tier gives fast access, and a capacity tier holds less frequently accessed data. A copy policy writes new backup files to object storage as they are created. A move policy relocates inactive backup chains. In a two-site design, a copy policy gives each restore point a second copy, so one site loss does not take every copy. Veeam also documents immutability for the performance tier, which prohibits deletion by making data temporarily immutable.
Do You Need a Third Site for Quorum?
For a stretched cluster that must fail over automatically, yes. Two sites cannot tell a dead peer from a severed link. A witness in a third failure domain decides which side holds the majority. Without one, you must accept manual intervention or a design that stops writes during a partition.
Microsoft states that the witness must be accessible from both sites to enable automatic failover and determine site majority during network partitions. Its instructions for deploying a quorum witness add that a file share witness should be physically separate from the cluster sites.
The witness is a cost that is easy to underrate. It is a third location with power, connectivity and an owner. It need not hold backup data, but it must stay reachable. Weigh that against asynchronous replication, which has no shared quorum because each site runs its own control plane.
How Far Apart Can the Two Sites Be?
Far enough to survive a regional event, but only as far as the write latency budget allows. Every synchronous write adds at least one inter-site round trip, so distance converts directly into acknowledgment time. There is no universal limit. Each product publishes its own.
Published limits are product-specific, which is itself the lesson. Microsoft recommends an average of 5 milliseconds round-trip latency or less for synchronous replication. Treat that as a design limit for that product, not as a rule for any object-storage platform. Ask your platform vendor for the tested limits. Then measure the link at peak load.
A few milliseconds is a metropolitan distance. A design that must survive a regional flood or grid failure usually sits beyond it. Microsoft notes that a multi-cluster topology lets clusters span greater distances using asynchronous replication, without the quorum constraints of a single cluster. Distance is one of the clearest reasons to choose replication.
Does a Stretched Cluster Protect Against Ransomware?
No. A stretched cluster is built to mirror every change at the speed of the link. That includes a deletion, an encryption pass or a destructive retention change. Microsoft says it directly: Storage Replica is not a backup solution, and if a user deletes all data from a volume, the deletion is replicated instantly to the other volume.
The threat is real for backup repositories. The Cybersecurity and Infrastructure Security Agency warns in its guide on stopping ransomware that many ransomware variants try to find and then delete or encrypt accessible backups. It recommends offline, encrypted backups tested for availability and integrity. NIST has published its ransomware risk management community profile, final in June 2026. It covers outcomes for managing, detecting, responding to and recovering from ransomware events.
Three separate controls close the gap.
- Immutability: Object Lock uses a write-once-read-many model. In compliance mode, according to the AWS documentation on Object Lock, a protected version cannot be overwritten or deleted by any user, including the root user.
- Independence: a second copy under a different control plane and different credentials, so one compromised administrator account cannot reach both.
- Isolation: an air gap that takes the copy out of reach of production networks and identities.
Object Lock works only in buckets with versioning enabled. Retention protects the specific object version, so new versions and delete markers can still be added on top. Immutability stops a copy changing, while an air gap stops anyone reaching it. A stretched cluster contributes neither. Replication to a separate, immutable target contributes at least the first two controls.
When Should You Choose Replication Instead?
Choose replication when three things matter more than zero loss on acknowledged writes: distance, a recovery point above zero, or a second administrative domain. Most backup designs need both jobs done deliberately. The framework below orders the questions.
- Distance. Beyond the latency envelope your platform documents for synchronous writes, replication is the option that does not slow every backup stream.
- Recovery point. Take the RPO and recovery time objective (RTO) from business impact analysis, as the NIST contingency planning guide, SP 800-34 describes. If the business tolerates losing the newest restore point and re-running the job, asynchronous replication is enough.
- Independence. A second administrative and immutable domain cannot come from a stretched cluster, which is one system by definition.
- Cost. Count the third-site witness, the extra mirrored capacity and the WAN bandwidth.
The hybrid answer follows. Use a stretched design where availability across a site pair is worth its cost. Then add asynchronous replication to an independent, immutable and preferably air-gapped target. The first keeps jobs running through a site loss. The second gives you something to recover from when an administrator or malware did the damage.
Where StoneFly Fits in a Two-Site Backup Design
StoneFly builds AWS-compatible S3 object storage that keeps backup data on infrastructure the customer controls. Replication, immutability and isolation are separate controls. The right arrangement should be validated against your own sites, links and recovery objectives.
Within a site, the StoneFly high availability AWS-compatible S3 object-storage appliance addresses controller failure. It pairs two clustered controller nodes, an active/active RAID controller in each and a high availability RAID expansion array. If a controller node becomes unavailable, the surviving node assumes its object-storage services. Automated failback restores the normal state when the node rejoins. This is controller-level high availability, not a cluster stretched across sites.
Across sites, replication carries the protection. StoneFly describes synchronous replication as completing the configured replica write before acknowledging the protected operation. It describes asynchronous replication as transferring object data or recovery states according to policy, without making every primary operation wait for a remote write. Object data can be replicated between appliances, sites and supported cloud destinations. StoneFly Scale Out object storage, which starts at three nodes, provides multi-site replication and recovery services.
For the copy that must survive an attack, Immutable Object Lock protects selected objects from modification, overwrite or deletion during the configured retention period. Air-Gapped Vault® technology isolates protected repositories, controllers or nodes from production access. The StoneFly guide to Object Lock for compliance and security covers the retention model.
For Veeam environments, the StoneFly Veeam Ready backup and DR appliance is validated for Veeam Ready Object and Veeam Ready Object with Immutability. Which replication mode suits which architecture, and how the sites behave at failover, are questions for a design review of your environment.
Conclusion: Availability and Protection Are Different Jobs
A stretched cluster keeps acknowledging writes when a site dies, provided quorum holds. It pays for that with latency, capacity and a witness. Replication keeps an independent copy and travels further, at a recovery point above zero. Neither does the other’s job, which is why a mirrored pair of sites can still lose everything to one bad deletion.
For backup targets the practical position is usually a pairing. Let the backup schedule bound the workload recovery point. Let the repository design decide how much availability is worth buying. Place an independent, immutable and isolated copy where no single administrator or piece of malware can reach every version. For a second opinion on a two-site design, contact StoneFly to review a two-site design.