An Estate Wide Backup Strategy on OCI

Backup looks solved on OCI because every service offers it: block volumes have policies, databases have automatic backups, object storage has versioning and replication, file storage has snapshots. The abundance is exactly the problem. Five mechanisms configured five ways by five teams is not a strategy, it is an inventory question waiting for an incident. The strategy layer sits above the mechanisms: a small set of recovery tiers defined by the business cost of loss, mapped onto the platform's tools, enforced by policy rather than memory, and proven by restores on a calendar. This article builds that layer, as part of our series on advanced OCI operations.

Start from loss, not from tools

Two numbers define every recovery conversation: how much data the business can afford to lose, the recovery point objective, and how long it can afford to be down, the recovery time objective. The strategy starts by sorting the estate into a handful of tiers along those two axes, three or four tiers, never ten. A typical shape: a platinum tier for the systems where minutes of loss are unacceptable, revenue transactions, anything legally mandated to be continuous; a gold tier where an hour of loss hurts but does not headline; a silver tier where a day is survivable, most internal applications; and a bronze tier for the reproducible, dev environments and anything rebuildable from code and images. Every system in the inventory gets a tier, and the tier, not the team's enthusiasm, determines the mechanism, the frequency, the retention, and the testing cadence. Untiered systems default to silver until someone argues otherwise in writing.

Mapping tiers onto OCI mechanisms

The platform's mechanisms line up against the tiers cleanly once the tiers exist. For databases, the spectrum runs from automatic backups with point in time recovery, through the dedicated database backup tooling with its near zero recovery point capture of redo, up to standby databases for the platinum tier where the real requirement is continuity rather than restoration. For compute, block volume backup policies capture boot and data volumes on schedules with retention built in, and policy assignment makes the protection automatic for every volume attached to the policy rather than a per volume decision. Object storage protects itself through versioning, replication, and lifecycle rules. File storage snapshots cover the shared filesystem tier. The estate wide view matters most at the seams: the application whose database is platinum but whose application server images are backed by nothing, the integration platform whose queues hold an hour of business data that no mechanism captures. The seams are found by walking systems end to end, which is also how the runbooks described in incident runbooks for OCI get written, and the two exercises productively share a workshop.

The two failure cases habits never cover

Per system habits reliably miss the same two scenarios. The first is regional loss. Backups that live only beside the systems they protect share the systems' fate, so the strategy must state, per tier, what crosses regions: cross region copy on block volume backups, replicated buckets for the object tier, standby databases or cross region backup copies for the platinum and gold database tiers. The second is the hostile actor, ransomware above all, where the attacker's first target is the backups themselves. The defenses are platform native and cheap relative to the exposure: retention locks on object storage that make backup buckets effectively immutable for their retention window, separation of duties so that the credentials that administer production cannot also delete its history, and a deletion alarm wired to the monitoring stack, because legitimate mass deletion of backups is rare enough to page on. A strategy that has not considered the deliberate deletion case is a fair weather strategy.

Restore testing: the calendar that proves it

Restores fail for reasons invisible until attempted: the backup that completed but is unreadable, the database restore that works but takes eleven hours against a four hour objective, the volume that restores cleanly into an environment whose network no longer matches, the runbook step that references a console screen redesigned two years ago. The fix is a standing calendar with sampling: every quarter, restore one system per tier, end to end, into an isolated compartment, timed against its stated recovery objective, with the result logged, pass, fail, or pass outside time, and every failure ticketed like the incident it nearly was. Platinum systems earn an annual full rehearsal including the application layer, not just the data. The calendar's output doubles as the compliance evidence the auditors ask for, and it keeps the recovery time numbers honest as data volumes grow, because the restore that met its objective at two terabytes will quietly stop meeting it at twenty.

Cost, retention, and the backups nobody needs

Backup spend deserves the same scrutiny as compute spend, because the failure mode is symmetrical: estates that underprotect the platinum tier routinely overprotect the bronze. Retention beyond the recovery window should exist only where a regulation or a stated business case demands it, archived to the cheapest storage class that meets it. Daily volume backups on disposable development instances, retained for a year by an unexamined default, are a pure tax, and the bronze tier's honest backup mechanism is usually the image pipeline and the repository, not nightly snapshots of machines that could be rebuilt in twenty minutes. A yearly retention review against the tier definitions reliably recovers real money, and pairs naturally with the patch and lifecycle calendar described in a patching strategy that survives audits, since both run on the same quarterly operations rhythm.

Backups are not disaster recovery, and the map should say so

One conflation costs estates dearly: treating the backup strategy as the disaster recovery strategy. They overlap, and they are not the same document. Backup answers the data question, what can be brought back and from when. Disaster recovery answers the service question, how the business keeps running while that happens, and it adds everything backup omits: standby infrastructure, network failover, DNS, identity, the application tier, and the people choreography of a real invocation. The tier map should state explicitly which systems rely on restore as their recovery path and which have continuity arrangements above it, because the difference is measured in hours of downtime and the business signs off on it whether anyone asked or not. A platinum database with a standby uses its backups as the third line of defense, behind the standby and the redo stream. A silver application with no standby uses its backups as the entire plan, and its stated recovery time had better include the full restore, the configuration rebuild, and the smoke test, timed by a drill rather than estimated in a meeting. Writing the dependency down per system is an afternoon of work, and it is the afternoon that prevents the worst day from being improvised.

The strategy in seven steps

Owning the worst day

Backup strategy is the purest form of operations work: invisible when right, unforgettable when wrong, and impossible to retrofit on the day it matters. It is also work with a defined shape, policies, calendars, evidence, sampling, which makes it natural to delegate. Our OCI managed services practice runs estate wide backup governance as standing work: tier maps maintained, policies enforced through code, restore tests executed and logged each quarter, and the deletion alarms watched 24/7/365, on patterns built across 500+ OCI engagements and 20+ years of combined Oracle experience. The question the strategy exists to answer is brutally simple: on the worst day, what comes back, and how fast? An estate that can answer from its standing records has a strategy. An estate that answers with somebody is fairly sure has a postmortem scheduled.