Object Storage Replication for DR on OCI

A large share of modern application state lives in object storage. If those buckets do not survive a regional loss, the application comes up missing half of what it needs.

Object storage is part of your recovery story

When teams plan disaster recovery they focus on the database and forget that a large share of modern application state lives in object storage. Uploaded documents, generated reports, media, backups, data lake content, and application artefacts all sit in buckets. If a region is lost and those buckets do not exist in the secondary region, the application comes up missing half of what it needs. Object storage replication is how you make sure the unstructured side of your estate survives a regional failure.

This article explains how cross region replication works on OCI object storage, what it does and does not guarantee, and how to fit it into a wider recovery plan.

How cross region replication works

OCI object storage can replicate a bucket to a bucket in another region. Once a replication policy is in place, objects written to the source bucket are copied to the destination on an ongoing basis. The replication is asynchronous, which means there is a lag between a write landing in the source and appearing in the destination. That lag is your recovery point exposure for the data in that bucket, and it is the single most important number to understand and monitor.

Replicate what matters, not everything

Replication has a cost in both storage and cross region data transfer, and that cost scales with how much you copy and how often it changes. Not every bucket needs a copy in the secondary region. Classify your buckets by whether the data is recoverable from another source, whether the application genuinely needs it to function, and how current it must be. Replicate the buckets that hold irreplaceable, application critical data, and leave the rest. This single discipline keeps the replication bill proportionate, a theme we develop across the backup strategies article.

The destination is read only until you promote

A common surprise is that the destination bucket is read only while it is the target of replication. You cannot simply start writing to it during a failover. The recovery procedure has to account for promoting the destination so the application can write to it, and the runbook must state exactly how and when that happens. Treating the destination as immediately writable is a mistake that surfaces at the worst possible moment.

Consistency across stores

Object storage does not exist in isolation. Your application is consistent only when the database, the block volumes, and the object store all reflect the same logical moment. If the database has been promoted to a point in time but the object store is lagging behind, references in the data may point at objects that have not yet replicated. Build a single replication plan that lists every stateful store, its mechanism, its measured lag, and the order in which each is promoted, so the recovered application is internally consistent. The cross store choreography is covered in cross region DR.

Monitoring the replication lag

Replication that runs unattended will drift, and a lag that has been quietly growing for weeks is a failover that loses more data than you planned. Monitor the replication lag for every critical bucket continuously, not just during an incident. Alert when the lag crosses the threshold that maps to your recovery point objective, and treat a breach as an incident in its own right rather than waiting for a disaster to expose it. The discipline mirrors how you watch database apply lag in Data Guard on OCI.

Versioning and protection against deletion

Replication protects against losing a region. It does not protect against a mistaken or malicious deletion, because a delete in the source can replicate to the destination. To guard against that class of failure, combine replication with object versioning and retention so that an unwanted change can be reversed. Replication and versioning solve different problems, and a complete plan uses both. Think of replication as resilience against infrastructure loss and versioning as resilience against human and application error.

Fitting object replication into the plan

Cross region object replication is one strand of a complete recovery design that also includes the database standby, block volume replication, networking, and DNS failover. Decide the recovery objectives first, then choose replication scope and lag tolerances that meet them, and write the promotion steps into the runbook. The full picture is in the disaster recovery pillar, the testing in DR testing. When we run recovery as a managed service, we own the replication policies, the lag monitoring, and the failover that brings the unstructured data back online.

Cost of replication and how to keep it sane

Object storage replication carries two recurring costs: the storage footprint of the replicated copies in the secondary region, and the cross region data transfer that moves objects between regions. Both scale with how much you replicate and how often your data changes. A bucket with a high churn rate ships far more data than a write once archive, even if they hold the same total volume. Model these two lines for each replicated bucket so finance can see the recurring premium next to the data it protects.

Apply storage lifecycle rules to the replicated copies so older objects move to cheaper tiers automatically. You are paying for these copies as insurance, and there is rarely a reason to keep aged copies on the most expensive tier. Lifecycle policies trim the storage line without weakening the protection.

Failback after a regional recovery

Replication runs one way, from source to destination. After a failover, when the original region returns, you do not simply switch back. You re establish replication in the reverse direction so the recovered region catches up with the changes made while it was down, validate that it is current, and only then cut back during a planned window. Treating failback casually is how teams turn a successful recovery into a second incident. The runbook should cover failback with the same rigour as the original failover.

Operating replication day to day

Replication is not a configure once and forget feature. New buckets are created as the application grows, and each one needs a deliberate decision about whether it must be replicated. Without governance, critical new buckets quietly go unprotected while nobody notices until a disaster reveals the gap. Build the decision into how buckets are provisioned, ideally through infrastructure as code so a new bucket carries its replication policy by construction, and review the set of replicated buckets periodically against what the application now depends on.

Where object replication fits the plan

Cross region object replication is one strand of a complete recovery design that also includes the database standby, block volume replication, networking, and DNS failover, all developed in the disaster recovery pillar. Decide the recovery objectives first, choose the replication scope and lag tolerances that meet them, and validate the whole thing during a real DR test. When we run recovery as a managed service, we own the policies, the lag monitoring, and the failover. To review how your unstructured data would survive a regional loss, book an OCI assessment.