Replication and Archival Solve Different Recovery Problems

A design review gets vague fast when a diagram contains a box labeled secondary copy and nothing else. I want to know why that copy exists, where it lives, what creates it, how long it stays there, and what has to be running before anybody can recover from it.

Rubrik Security Cloud makes replication and archival separate policy choices inside an SLA Domain. This article is scoped to data center workloads managed by Rubrik clusters, where replication is cluster-to-cluster and archival starts from the Rubrik cluster. RSC also supports replication for some cloud-native AWS and Azure workloads, but those flows use cloud account or region targets rather than another Rubrik cluster and are outside this comparison.[1][2][3][16][17][18]

Within that scope, both mechanisms can place protected data beyond the original protection location. They do not create the same recovery capability, and current Rubrik documentation does not treat them as interchangeable features.[2][6]

Another Copy Needs a Job

RSC exposes frequency, retention, archival, and replication as separate SLA Domain policy elements.[1] Copy count by itself says almost nothing about recoverability. Two copies can contain the same workload and still have completely different access paths, retention periods, infrastructure dependencies, and realistic recovery times.

Within the data center scope here, a replicated copy normally exists on another Rubrik cluster. An archived copy exists in an archival location selected by policy. Those are different mechanisms. The recovery design should preserve that difference instead of flattening both into a remote copy column in a spreadsheet.

The first question I would ask is not how many copies exist. I would ask what each copy is expected to do after a specific failure. A copy intended to support recovery after loss of the primary Rubrik cluster has a different job from a copy kept for seven years of historical retention. If both requirements exist, the design may need both mechanisms.

Replication Builds Another Rubrik Recovery Location

Documented For supported data center workloads managed by Rubrik clusters, Rubrik replication sends replicas of protected snapshots or backups from a source Rubrik cluster to a target Rubrik cluster. The replication policy identifies the target and gives the replicated data its own retention setting.[2][4] Rubrik documents many-to-one and one-to-one cluster replication configurations. One-to-one is supported only for data center workloads, and Rubrik marks the current replication configuration workflow as a feature being gradually rolled out to customers.[16] Replication pairings must exist between participating clusters.[2]

The target is still Rubrik infrastructure. It has to exist in a failure domain that makes sense for the recovery requirement, and the path between source and target has to carry the replication workload. Rubrik documents private network and NAT addressing for replication pairings, and it provides cluster level bandwidth throttling with scheduled overrides for replication traffic.[5][8]

Bandwidth affects more than transfer duration. Rubrik documents that when constraints prevent all replication tasks in an SLA Domain from completing, the cluster can skip older replication work to prioritize newer data. Local snapshot expiration still follows the local retention policy.[4] A configured replication policy therefore does not prove that every expected replica is present. Recovery planning should use completed recovery points on the target, not the intent expressed in the policy.

Recovery behavior also depends on the workload. Rubrik's workload matrix does not show replication as universally available, and the recovery path is not identical for every protected object.[3] For example, RSC cyber recovery for supported virtual machines can select the replication cluster and recover the replica, while SAP HANA documentation describes downloading a replicated full snapshot when the required snapshot is not available locally.[10][11]

I would not describe replication as automatic failover. A target cluster can give the organization another Rubrik managed recovery location. The application still needs somewhere to run, and the exact restore, mount, export, or download path has to be verified for the workload being protected.

Archival Has a Different Access Path

Documented For data center workloads, Rubrik archival policies copy protected data to configured archival locations. Current RSC documentation lists Rubrik Cloud Vault, Microsoft Azure, Amazon S3, Google Cloud Platform, NFS shares, S3-compatible object storage, and tape among supported archival location types.[6] The archival policy also controls when eligible recovery points are sent to archive and how local retention relates to that archival behavior.[7]

Archive is not simply a slower replication target. It is storage reached through an archival workflow, and recovery has to account for that storage system's access model. Rubrik documents a reader cluster process that allows another Rubrik cluster to connect to supported archival locations, recover metadata, discover archived workloads and snapshots, and access recoverable data.[9][15] That can be part of a disaster recovery design, but it is a different path from having the same replica already present on a target Rubrik cluster.

Storage class can widen that difference. Rubrik Cloud Vault's Archive tier currently has a minimum retention period of 180 days, and Rubrik advises that data can take several hours to a few days to become accessible. Rubrik specifically says that tier should not be used for backups required for disaster or cyber recovery.[12] The data can be protected and retained correctly while still being a poor source for a short recovery objective.

Cloud storage can still appear in a data center protection design as an archival destination. That does not turn the archive into cloud-native replication. Classify the copy by the Rubrik workflow and its recovery behavior, not by the logo on the storage bill.

Retention Is Different at Each Location

An SLA Domain can express several time decisions that are easy to collapse into one retention number on a diagram. Local snapshot retention defines one window. Replica retention defines another. Archival policy adds its own timing and retention behavior. Rubrik also supports Instant Archive for eligible designs, which changes when data begins moving to the archival location.[2][7]

The architecture should document those windows separately. A workload protected every four hours does not automatically have a remote RPO of four hours. The local snapshot has to succeed, the replica or archive operation has to complete, and the required recovery point has to remain available at the location you intend to use.

The same separation applies when mechanisms are combined. Rubrik supports cascading archival, where replicated snapshots on a target Rubrik cluster can be archived to a separate archival location. Rubrik documents the source archival policy and the target cascading archival policy as independent.[13] This adds another placement option and another retention and transfer path that needs to be understood on its own.

That table is a design comparison for data center workloads managed by Rubrik clusters, not a guarantee that every workload exposes every option. Rubrik's current supported features matrix contains real exceptions. Kubernetes is listed with replication support but not archival, Microsoft Exchange and NetApp Volumes with archival support but not replication, and Cassandra with neither feature in that matrix.[3] I would check the workload before standardizing a copy design across the estate.

Site Loss Is a Better Test Than Copy Count

Take the primary site off the diagram. Assume the production infrastructure and the local Rubrik cluster are unavailable. Now ask which recovery points can still be used.

With cluster replication, the answer starts with the target Rubrik cluster and the newest completed replica that survived the failed site. The next questions are practical: Is there compute to run the workload? Can the target Rubrik cluster reach it? Are the required networks, storage, credentials, DNS, and identity services available? Which recovery operation does this workload support from the replica?

With archival, the copy may be perfectly intact and still need more preparation before recovery begins. The team may need to connect a reader Rubrik cluster, recover archive metadata, wait for a storage class to make data accessible, transfer data, and then perform the workload specific recovery.[9][12][15] None of those steps makes archival a bad design. They simply belong in the RTO calculation.

Architecture point Copy availability and service recovery are different measurements. Replication can reduce the distance between a remote recovery point and a usable Rubrik recovery location. Archival can preserve data for a much longer period or outside local protection storage. Neither one supplies the compute, network, identity, application dependencies, or operator access required to finish recovery.

Failure Domains Decide What the Copy Is Worth

Three copies can still share one weak dependency. A local snapshot, a replicated snapshot, and an archived snapshot may all rely on the same administrative team, network edge, credential set, cloud account, or recovery procedure. Counting them does not tell you which failures they actually survive.

I would review each location against the failures that matter to the service: loss of production, loss of the local Rubrik cluster, site loss, WAN loss, internet loss, cloud service interruption, storage failure, loss of the replication target, loss of the archive target, and administrative or credential compromise. Not every copy has to survive every event, but the intended coverage should be explicit.

Cyber recovery deserves the same discipline. Replication and archival can give the recovery team more surviving points and more locations to work from, but neither mechanism should be treated as proof of isolation, clean recovery point selection, or safe return to service. Those are separate controls and procedures.

Networking is part of that failure domain analysis. Rubrik provides separate throttling controls for replication and archival because they use different transfer paths and can compete with other protection and recovery traffic.[8][14] I would size and monitor those paths from measured transfer behavior, then test recovery traffic as well. A copy that arrives eventually can still miss the business requirement.

Use Both When the Workload Has Two Problems to Solve

A remote cluster replication design makes sense when a supported data center workload needs another Rubrik managed copy that can participate in recovery after loss of the primary protection location, assuming the workload supports the required recovery workflow. The remote site still needs the infrastructure required to finish recovery.

A long retention archive makes sense when the organization needs history that should not consume the same local protection capacity for its entire life. The design has to accept the archive's retrieval behavior, access path, and recovery timing. For some archive tiers, that timing is intentionally much longer than an operational recovery window.[12]

Some supported data center workloads need both. RSC can combine replication with archival, including cascading archival from a replication target.[13] In that design the replicated copy and archived copy should have separate jobs in the recovery plan. Keeping both without defining those jobs only creates a more expensive version of the same ambiguity.

Review Every Secondary Copy as a Recovery Location

Before I sign off on a secondary copy design, I want these answers written down for each location:

1. Why does this copy exist?
2. Where is it stored?
3. What Rubrik mechanism created it?
4. How long is it retained there?
5. What failure is it intended to survive?
6. How current can the surviving recovery point realistically be?
7. How is the copy accessed during recovery?
8. What infrastructure is required to recover from it?
9. What network connectivity is required?
10. How quickly can it realistically contribute to recovery?
11. Which dependencies does it share with the primary copy?
12. Who controls or administers it?

If a copy still depends on the failed site, or nobody can explain how it is accessed after site loss, the design is not ready. The same review also exposes cases where a retention design is being mistaken for a disaster recovery design.

For supported data center workloads managed by Rubrik clusters, use cluster replication when the requirement calls for another Rubrik recovery location and the workload supports the recovery path you need. Use archival when the requirement calls for a different retention or storage location and its access path fits the recovery objective. Use both when the workload has both problems.

I would not approve the phrase we have another copy as the recovery strategy. I would approve a design that can name the copy, its mechanism, its failure domain, its retention, the infrastructure needed to use it, and the recovery time the organization has actually planned around.

Source Notes

Product behavior changes. These sources were checked against public Rubrik documentation available on September 30, 2026.