A deleted file, damaged table, or scoped ransomware incident should not require rebuilding an entire environment, yet that is still how many native cloud restore workflows behave. Granular recovery is supposed to fix that, but the real question is how it actually works across different cloud services.
What is granular recovery?
Granular recovery means restoring only the data unit you need, such as a file, object, table, or record, instead of waiting on a full server, volume, or database restore.
The exact restore unit depends on the platform and the workload it protects. File recovery is the most common form, but granular recovery can also mean object, table, or record-level restore. For database workloads, that distinction is where it counts most.
How does granular recovery work?
Granular recovery follows a simple pattern: locate the data, validate it, and restore only that specific unit without rehydrating the full environment.
In most systems, this process includes three core steps:
- Search for and identify the right recovery point. Select the backup snapshot or point in time that contains the data you need.
- Find the exact data. Use metadata, indexing, or global search to locate the specific file, object, table, or record within that backup.
- Restore only that data. Recover the selected item directly, without restoring the entire server, volume, or database.
In narrower backup workflows, this process often breaks down. Teams may still need to restore a full resource (like a database or table) into a temporary environment, then extract the data they actually need (also the ETL, overhead, etc).
That extra step adds time, infrastructure overhead, and operational risk that teams don't always account for upfront.
Where native cloud restore still stays broad
Native cloud tools have improved, but restore scope still defaults to the resource boundary instead of the data unit you actually need.
The most common example is Amazon RDS and Aurora PITR. Point-in-time recovery (PITR) restores to a new DB instance, not a specific table or record. If you need one table back, you still have to spin up a full instance, locate the data, and extract it manually. The restore works, but it's not granular.
DynamoDB PITR follows the same pattern. Recovery restores the entire table to a new table rather than an individual item. For teams running high-volume transactional workloads, that's a significant operational lift for what might be a small, scoped problem.
EFS is the cleaner case. AWS Backup supports item-level restore for EFS workflows, but recovered files land in a new recovery directory rather than back in place. It's narrower than a full volume restore, but still requires manual steps to complete the recovery.
The pattern holds across providers. Native restore is built around resource-level operations. When the problem is smaller than the resource, the workflow doesn't shrink with it.
When granular recovery actually changes the outcome
Granular recovery is most critical when the issue is smaller than the system that protects it. Without it, even minor problems can trigger full restores, longer downtime, and manual recovery steps.
The clearest cases are:
- A deleted file or object. You need one item back, not the whole volume. Restoring a full EC2 instance or S3 bucket to recover a single file adds time and infrastructure overhead that the problem never warranted.
- A PostgreSQL table issue. Innago averaged 10–15 minute restores for small to medium volumes with granular recovery in place. For context on what that replaces: one prospect dealt with a 1–2 hour downtime incident restoring a single Aurora PostgreSQL table manually.
- A ransomware event. You need the last clean recovery point and a way to restore only what was affected. SoFi cut recovery time from a full day to under five minutes using Eon's granular restore model, which matters because their environment spans five AWS regions with strict regulatory retention requirements.
- An audit, compliance review, or internal data request. You need access to historical backup data without rebuilding the full environment first.
What should you look for in a granular recovery platform?
A granular recovery platform is only useful if the rest of the recovery path holds up. These are the checks that tell you whether a platform delivers on that.
Search before restore
Recovery starts with finding the right data before restore. If your team cannot find the exact file, table, or record before restore, the workflow is still heavier than it needs to be.
Table- and record-level precision
Most backup products use "granular recovery" to mean file, folder, or object recovery. That's useful, but it's a narrower restore scope than database workloads typically require.
The more relevant question is whether the platform can restore at the table, record, or query level without spinning up a full environment first.
Clean recovery points
Granular recovery only works if the data you restore is safe. During a ransomware incident, this means identifying clean recovery points before committing to a restore.
For managed databases like RDS or Aurora, that requires logical analysis of backup content. Filesystem-level scanning doesn't reach inside managed database backups, so platforms that depend on it can't reliably confirm what's clean.
Policy coverage and drift visibility
Recovery depends on what was protected in the first place. Untagged resources, policy drift, and cross-account blind spots all create gaps that surface at restore time. Automated discovery, classification, and continuous drift detection are what keep coverage reliable at scale.
Query access to backup data
In many workflows, backups are only usable after a restore. A stronger model allows teams to search, inspect, and query backup data directly, without rebuilding environments first.
How we built granular recovery into Eon
Granular recovery is a primary differentiator for Eon, but it's only one part of how we designed the platform. The full model combines four things working together: Cloud Backup Posture Management (CBPM), logically air-gapped immutable backups, granular recovery, and instantly queryable backup data.
Restoration (or recovery?) precision alone doesn't prevent a small incident from becoming a large recovery operation. That's why we built clean recovery point identification into the ransomware protection layer. Eon is the only backup solution to analyze the logical content of database backups, not just filesystem-level signals, so teams know what's actually safe to restore before committing to it.
Here's how each piece connects:
- Cloud Backup Posture Management: automatically discovers and classifies resources, enforces policies without manual tagging, and surfaces coverage drift across accounts and regions before it becomes a recovery problem.
- Granular Restoration: restores the exact file, record, or table you need without rehydrating a full environment. For database workloads especially, that's the difference between a 15-minute fix and a multi-hour infrastructure operation.
- Ransomware Protection: immutable, air-gapped backups with clean recovery point identification built in. Scoped restore only works if you can trust what you're restoring from.
- Global Search: makes backup data searchable and queryable without a full restore. Teams can run audits, compliance reviews, and data requests directly against backup data without rebuilding an environment first.
Key takeaways
Most cloud restore workflows are still broader than the problems they’re meant to fix. If you have to restore full resources to recover a file, table, or record, the workflow is not truly granular. It’s just a slower rollback.
What matters is simple: can you find the right data, verify it’s safe, and restore only that scope without rebuilding everything around it?
A scoped incident shouldn't cost you hours of downtime. Request a demo to see how Eon handles granular recovery across AWS, Azure, and GCP — and how fast you can recover the right data without a full environment restore.
Frequently asked questions
What workloads benefit most from granular recovery?
Database workloads benefit most from granular recovery, particularly managed databases like RDS, Aurora, and DynamoDB. These are workloads where native restore defaults to a full resource boundary, meaning a single table issue can trigger an instance-level restore.
How is granular recovery different from PITR?
Granular recovery and PITR solve different problems. PITR rolls back an entire resource to a previous state. Granular recovery targets a specific data unit (a file, a record, a table) without touching anything else. For most everyday incidents, granular recovery is the faster and less disruptive path.
Is granular recovery the same as file-level restore?
No, file-level restore is one type of granular recovery. Granular recovery can also include objects, tables, and records. For database workloads, that distinction is where recovery time and operational overhead are decided.
Do native cloud tools support granular recovery?
Native cloud tools support different restore scopes by service. Some workflows support narrower recovery, such as AWS Backup for EFS item-level restore. Others default to a broader resource boundary: RDS PITR restores to a new DB instance, DynamoDB PITR restores to a new table. The restore scope depends on the workload, not the cloud provider.
Why does granular recovery matter for ransomware?
During a ransomware event, teams typically need to restore only the affected data, not roll back an entire environment. Granular recovery supports that, but only when paired with immutable backups, clean recovery point identification, and a way to verify what's safe to restore before committing to it.
What should I check before buying a granular recovery platform?
Check five things: the restore unit it supports, search capability before restore, supported workloads, clean recovery point validation, and whether backup data is queryable without a full restore. Those checks tell you whether the platform delivers scoped recovery or just claims to.
