Backup and disaster recovery are two different jobs, and each incident calls for one of them. Of the teams Eon surveyed, 91% were sure they could identify what data is protected across accounts, regions, and clouds. Yet 61% find unprotected data only after an incident, an audit, or a restore that came up short. The seven practices below address them.
What is backup and disaster recovery?
Backup and disaster recovery get grouped together, but they do different work. Backup protects the data: it keeps clean, restorable copies you bring back onto systems you rebuild. Disaster recovery protects the environment that runs it: it keeps a replica ready, so service returns without a rebuild. Each incident calls for one or the other, and plans fail when the team reaches for the wrong one.
The recovery point objective (RPO) caps acceptable data loss, measured as the time between the incident and the last usable copy, and backup frequency has to meet it. The recovery time objective (RTO) caps acceptable downtime, and the restore process has to meet it.
The distinction sounds academic until an incident starts. You can hold a perfect copy of every database and still miss your recovery window if nobody defined who declares the event, which workload goes first, or how to get one table back without rebuilding the server around it. Cloud disaster recovery planning covers that side in depth.
The 3-2-1 backup rule still holds in the cloud: three copies on two storage types, one kept offsite. In the cloud, "offsite" means a separate trust domain, not just a separate region. Cross-region buys redundancy; cross-account buys isolation, and they are not substitutes. The offsite copy needs credentials independent from production.
Cloud-native designs extend the rule to 3-2-1-1-0, adding an immutable copy and zero errors on verified restores.
Responsibilities of the backup layer and the disaster recovery layer
Splitting the two layers by responsibility is the fastest way to find where your own coverage breaks down.
Backup layer responsibilities
The backup layer answers what exists, what is protected, and what condition the copy is in:
- Discovering and classifying every resource across accounts, regions, and clouds
- Capturing data at a frequency that satisfies the data loss target
- Storing copies with immutability and access separation
- Enforcing retention by data class
- Confirming the copy is restorable and free of encryption or corruption
- Restoring at the level of a file, object, table, or record
Disaster recovery layer responsibilities
The disaster recovery layer answers how service returns:
- Setting RTO and RPO targets per workload tier
- Choosing a recovery model, from restore-only through active-active
- Writing runbooks and assigning named owners
- Declaring the event and running internal and customer communication
- Validating the restored environment before traffic returns
- Failing back and recording evidence for auditors
Active-active is the exception to watch. It replicates damage as fast as it replicates data, so a corrupted or encrypted write lands in both sides before anyone reacts.
Handoff points between the two layers
Three handoffs decide whether a plan survives contact with a real incident.
Confirming the newest copy is usable before anyone needs it falls between the two. It belongs to neither the backup policy nor the recovery plan, so nobody checks it until an incident does.
How data backup and disaster recovery works
Six stages run between a healthy environment and a restored one. Weakness at any stage caps everything downstream.
1. Resource discovery and classification
Discovery builds the inventory. Classification decides what protection each resource earns based on the data inside it, such as customer records, financial data, or logs.
Manual tagging is what creates the hole here: a resource created outside policy stays unprotected until someone notices, and in fast-moving environments that happens constantly. One VP of engineering put it this way: 100 new databases get turned on every day, and the team doesn't know what data sits in them.
Cloud Backup Posture Management (CBPM) continuously discovers and classifies resources and applies policy without a tag, so a database created on a Friday gets covered without anyone tagging it.
2. Data capture and backup frequency
Capture happens three ways:
- Full snapshots copy everything.
- Incremental captures copy only the blocks that changed since the last copy.
- Log-based capture streams transaction logs continuously, which gives you point-in-time recovery (PITR).
With continuous backups switched on, AWS Backup leaves you roughly five minutes short of current on an RDS database and roughly fifteen minutes short on an S3 bucket. Those figures hold for the source account and region. PITR stops at 35 days, and a cross-region or cross-account copy is a snapshot copy with no PITR at all.
Eon's forever-incremental capture doesn't beat native on recovery point (RDS PITR still runs on AWS native PITR). It changes what each copy costs: one full copy first, then only changed data, instead of full backups on a schedule.
3. Isolated, immutable backup storage
Immutability locks a copy at the storage layer, so nothing can overwrite or delete it until the retention period runs out. It does nothing about an admin permission that deletes the whole vault.
Isolation takes care of that part: production credentials and recovery copies sit under separate identities (usually a separate account or subscription), which keeps the copies outside the blast radius of a stolen production login.
4. Recovery point validation
Validation confirms the copy restores and confirms the data inside it is clean. Encrypted or corrupted data replicates into backups without triggering an error.
Managed databases are the blind spot. File-level entropy scanning cannot see inside an RDS or Cloud SQL backup, so detection has to read the logical contents, including row counts, schema structure, and cardinality patterns.
5. Recovery execution and recovery unit selection
The recovery unit is the smallest thing your tooling can bring back. If that unit is the volume, then a single corrupted table costs you a full instance rebuild.
The workarounds people reach for when the unit is too coarse are worse than the damage. Restoring a whole volume to recover one table means standing up a parallel instance, exporting the row, and reconciling it by hand, which runs slower and riskier than the incident that triggered it.
6. Failback and audit evidence
Failback returns workloads to primary infrastructure and reconciles data written during the recovery period.
Auditors ask for the evidence trail. That means what was covered, when it was last restored, who approved the restore, and how long it took. Recording that during the event is far easier than reconstructing it later.
Disaster recovery trigger events in 2026
The events that force a recovery in cloud environments look nothing like the ones this discipline was built around. Site loss, server death, and application crashes still happen. Three newer trigger types now cause more incidents.
Credential-based deletion of production and its copies
Attackers who get into production go after the backups next, since a clean restore removes the reason to pay a ransom. Sophos research on backup compromise found attackers tried to reach the backups in 94% of ransomware incidents and got through in 57% of those attempts.
Any copy reachable by production credentials is part of the same blast radius as production.
AI agent actions against production data
Coding agents hold write access to live systems and act faster than any review cycle. In the PocketOS incident, an agent deleted a production database and every volume-level backup attached to it in nine seconds.
Recovery from an agent event has to be scoped to what that agent touched, which is a different problem from restoring a server. Eon's 2026 Cloud Data Infrastructure Report found 75% of respondents run AI workloads against production data, so the exposure is already widespread.
Cloud region and control plane outages
Regional control plane outages take out the console you would use to run a restore. The October 2025 US-EAST-1 event began with DynamoDB endpoints going unresolvable in DNS. Everything sitting downstream of them started timing out at the application layer, and the disruption ran roughly 15 hours.
Forrester predicts at least two multi-day hyperscaler outages during 2026. AWS draws the line clearly in its own resiliency guidance. The provider keeps the infrastructure running, and you carry everything to do with copies of your data.
Where backup coverage and disaster recovery plans break down
These failure patterns show up again and again across cloud teams, and each stays invisible until an incident forces it into view.
Ownership varies across cloud, platform, and application groups
Who owns protection varies by organization. Some run it from a central platform team, and others let each team pick its own tooling. The risk shows up when the people who create resources aren't the ones who answer for recovering them, because the people writing the disaster recovery plan may not control the accounts where new resources appear.
Unverified backup coverage
Confidence runs far ahead of evidence. Teams are sure they can name what is protected, but most find the holes only after an incident, an audit, or a restore that came up short, which is exactly where unverified coverage turns into an outage.
Untested recovery time estimates
Recovery-time targets are often planning estimates nobody has checked against a real restore. In Eon's 2026 report, 75% of executives said their staff estimates recovery time from assumptions, and 60% of respondents self-report a full restore at six or more hours.
One database engineering director put a full restore at about 12 hours, because the team downloads the S3 copies and then restores on each database. With Eon, SoFi cut recovery from a full day to under five minutes, and NETGEAR took a 10TB SQL Server restore from 24 hours to 3.
Retention limits on managed database services
Native retention windows are shorter than most disaster recovery plans assume. On Amazon RDS, automated backups stop at 35 days, and anything created through the console starts at a week unless someone changes it.
Corruption introduced by a bad migration or a compromised credential often goes unnoticed for longer than that. When it does, the clean recovery point has already expired.
7 backup and disaster recovery best practices
These seven practices turn the gaps above into specific controls you can put in place.
1. Classify resources automatically at creation
Tie protection policy to the type of data a resource holds, and apply it when the resource is created rather than tagging it after the fact.
Audit the inverse too. Resources carrying retention they no longer need are a cost problem hiding inside a coverage program, and 87% of respondents in Eon's 2026 report say they retain data they don't need. Eon's global deduplication stores each unique block once, which is part of how it delivers up to 50% lower cost.
2. Keep the recovery copy outside the production credential boundary
Put backups in a separate account or subscription with its own identity boundary, then make the copy immutable and logically air-gapped. Eon discovers and protects through one read-only IAM role, with no agents or appliances to install. Ask whether a stolen production credential can reach the copy. If it can delete it, the copy isn't a recovery option.
3. Validate recovery points before an incident
Run validation continuously against stored copies. Check restorability and check the logical contents for signs of encryption, mass deletion, or schema damage.
Validate each copy when it lands instead of on a schedule. The window between when a copy lands and when someone checks it is where a damaged copy still counts as protected. Ransomware detection built into the backup path runs the check on each copy that lands in the vault.
4. Match the recovery unit to the damage unit
Plenty of incidents damage only a small thing, such as a record, a table, a bucket prefix, or a set of files. In one case, a recovery that should have taken about 10 minutes became roughly a 3-hour project, because the only native option was a full volume restore.
A DR test in another environment couldn't restore a single large table at all. Someone had backed it up as one partition, the restore pushed it through a container too small to hold it, and the container ran out of memory and died mid-restore. Restore granularity gets decided when the copy is written, long before anyone opens a restore screen.
Eon’s granular recovery indexes the contents of each copy, so you can search or query a backup and pull back one record or table without hydrating the volume it sits on. StructuredWeb cut restore time by 98% with Eon, running SQL queries on its protected databases instead of restoring full clusters first.
5. Set retention by data class and enforce it centrally
Retention set per resource drifts as the environment changes. One senior manager of site reliability and cloud engineering described it this way: "Our retention for S3 backups is six weeks. If we need something earlier than that, tough luck." Retention set per data class avoids that trap, because new resources inherit the rule that fits their contents.
Where native windows cap out below your compliance obligation, move long-term copies to a dedicated, logically air-gapped vault with its own identity boundary. A 35-day cap falls far short of the six-year hold that SEC Rule 17a-4 sets for core broker-dealer records.
Eon holds snapshot-based RDS recovery copies well past the native 35-day cap through tiered retention policies. Point-in-time recovery still runs on AWS native PITR, so that 35-day window stays in place for PITR.
6. Define a minimum viable recovery set for uptime commitments
List the smallest set of systems that returns contracted service. Data stores, identity, and the dependencies those two need to function.
Recover that set first, then everything else. Gartner expects 35% of enterprises with external SLA obligations to include minimum viable recovery in their incident response plans by 2030, up from near 0% in 2026. The reasoning: restoring a whole environment takes longer than the uptime clause allows.
7. Measure recovery time from validated restores
Record wall-clock time on real restores and compare it against the target for that workload tier. Count the time only when the restore is validated. A job can finish green and still fail if the database won't accept connections or the data comes back incomplete, so treat an unvalidated restore as a failed one. An unmeasured objective is a number on a slide.
Log the result per tier, per quarter. Trending those numbers catches degradation long before an incident does.
Emerging backup and disaster recovery capabilities through 2030
Six capabilities answer the weaknesses covered above. Two come first.
Copies written in open formats (Apache Parquet and Apache Iceberg) serve recovery, analytics, and AI from one dataset, which removes the separate export and pipeline built to get recovery data into analytics.
In its 2026 Hype Cycle for Backup and Data Protection Technologies, Gartner expects 70% of organizations to prioritize the recoverability of identity systems by 2030, up from less than 15% in 2026. Gartner also points to identity compromise during attacks as a cause of disrupted recovery.
The other four appear in the same Hype Cycle, and Eon already ships three of them: record-level rollback of rogue-agent changes, CBPM coverage assessment, and detection inside databases. Each needs the following to work:
- Continuous coverage assessment: A consolidated, continuously updated view of readiness across every account and region, which native cloud services do not provide.
- Agent action rollback: Record-level capture, so a reversal can target exactly what an agent changed without rolling back the volume around it.
- Threat detection inside backups: Detection that reads the logical contents of a copy, since file-level scanning cannot see inside a managed-database backup.
- Isolated recovery environment: An immutable copy behind a logical air gap plus a clean environment to verify it in before traffic returns.
Where to invest in backup and disaster recovery first
Start with coverage. If you can't list every unprotected resource, nothing you choose later has a complete set of copies to work from. Then choose your disaster recovery model per workload tier once you know what is protected.
Can you name every unprotected resource in your environment right now? Book a demo and see how Eon classifies resources automatically, holds copies in a logically air-gapped vault, and restores a single file, table, or record without rebuilding the environment around it.
Frequently asked questions
What is minimum viable recovery?
Minimum viable recovery is the smallest set of systems an organization restores first to return contracted service. It usually covers primary data stores, identity infrastructure, and their direct dependencies. It exists because full-environment recovery timelines sit outside most contractual uptime commitments, so restoring everything at once is not a realistic answer to an SLA.
How long should backup retention be for disaster recovery?
Backup retention should cover the longest time between damage and discovery, plus any compliance obligation, and native windows are often shorter than both. Amazon RDS caps automated backups at 35 days, which handles operational rollback but not corruption found months later or a six-year hold like SEC Rule 17a-4.
Do immutable backups guarantee a clean restore?
No. Immutability protects the copy from modification and deletion. It says nothing about whether the data inside was already encrypted or corrupted when it was captured. Validation has to read the logical contents, especially for managed databases where file-level scanning cannot see inside.
How do AI agents change backup and disaster recovery requirements?
AI agents change the requirements by acting on production with valid credentials at machine speed, so recovery has to be scoped to what the agent changed and held where those same credentials cannot reach. Volume-level restores are a poor fit, since an agent that drops three tables has not damaged the volume.
Who owns backup and disaster recovery in a cloud organization?
Ownership varies: some organizations centralize it, and others let each team choose. Policy that is set centrally and applies on its own works in either model. Workloads go unprotected when protection depends on individual owners remembering to opt in.
What is the difference between a backup policy and a disaster recovery plan?
A backup policy governs the copies, covering what gets protected, how often, for how long, and where it is stored. A disaster recovery plan governs the response, covering recovery targets, failover design, runbooks, and owners. Coverage falls through between the two, where neither document claims responsibility.
