Database backup and recovery
Eon protects managed and self-managed databases on AWS, Google Cloud and Azure. Restore the instance, a database, a table, or only the rows a query matches, where a native restore builds a whole new instance.
What Eon backs up
Databases are discovered and protected on their own, across every account, project and subscription you connect.
AWS
Amazon RDS on MySQL, PostgreSQL, MariaDB, SQL Server and Oracle. Amazon Aurora. And self-managed MySQL, PostgreSQL and SQL Server running on EC2. Restore the instance, a table, or the rows a query matches.
One policy model across every engine
Three policy types, not one per service.
Standard snapshots for long retention, high frequency for tighter recovery points, and point-in-time recovery to the exact second.
Databases you manage yourself count too.
MySQL, PostgreSQL and SQL Server running on your own instances get the same treatment as managed services, so a self-hosted database is not a gap in your coverage report.
Coverage you can prove.
New databases are discovered and classified without anyone tagging them. When something stops matching policy, it shows up as a finding, rather than as a surprise during a restore.
Restore the rows, not the instance
A native snapshot or point-in-time restore builds a new instance. When a bad migration corrupts one table out of two hundred, you still stand up the whole instance, find the data, extract it by hand and reconcile what changed since. Eon stores backups as Parquet exposed as Iceberg tables, so you can query a backup, find the rows that matter, and restore only those.
Native database backup
Eon
Restore scope
A new instance, always.
Instance, database, table, or the rows a query matches.
Point-in-time recovery
Capped at 35 days on RDS and Aurora.
Retention as long as your policy needs.
Proof the backup restores
The job reports success. Whether the data comes back intact is not checked.
Every table is fingerprinted, the backup is restored to a temporary instance, and the fingerprints are compared.
Where copies live
Inside the same account.
An isolated, immutable vault.
Another cloud
Not possible.
A database on one cloud can be protected into a vault on another.
Knowing what is protected
Tags and configuration you maintain.
Discovered and classified automatically. Drift shows as a finding.
Undo the damage, keep the good writes
An automation with write credentials, or an attacker with a stolen key, can damage a database in seconds. Rolling the instance back also throws away every legitimate transaction since then. With Eon you query the backup for the rows the incident changed and restore only those, so later writes stay put.
Credentials from production do not open your backups
Backups land in an isolated, immutable vault, kept apart from the account they came from. Access is time-bound, so a stolen key does not reach your recovery data.
Detection that reads the data, not the files
Managed database services don't give you backup files to scan. Eon reads the contents instead, watching for drops in row and table counts, unexpected schema changes, value patterns that change when data is encrypted in place, and ransom notes inside the data. In early access.
Put back the rows, not the database
Restore what was damaged and keep every good write that landed alongside it.
What database backup costs
When database backup isn't its own line item, it grows unnoticed. Snapshots outlive their instances, audit retention never gets revisited, and inspecting a native backup means paying for a full instance. Eon stores changes instead of full copies, and lets you query a backup without restoring it.
Protect a database into another cloud
Back up Amazon RDS and Aurora into a Google Cloud vault, Cloud SQL into AWS, and Azure SQL and PostgreSQL Flexible Server into AWS or Google Cloud. Your recovery data sits outside a cloud-level incident, and you can query it and restore records while the original cloud is down. A full restore returns the database to its source cloud once that cloud is back.
More on database backup
FAQs
Yes. Restore a full instance when that is what the incident calls for, a single table, or only the records matching a SQL query. On Amazon RDS PostgreSQL and Aurora PostgreSQL you can also restore an individual database out of a snapshot.
Eon discovers and classifies databases as they appear, and applies policy based on what the data is rather than what someone remembered to tag. If a database stops matching policy, or an account shows up with nothing protecting it, that surfaces as a finding you can act on.
On AWS: RDS for MySQL, PostgreSQL, MariaDB, SQL Server and Oracle, plus Aurora, and self-managed MySQL, PostgreSQL and SQL Server on EC2. On Google Cloud: Cloud SQL for MySQL, PostgreSQL and SQL Server, plus self-managed databases on Compute Engine. On Azure: Azure SQL Database, Azure Database for PostgreSQL and MySQL Flexible Server, and SQL Server on Azure VMs.
Supported. RDS lets you take RMAN backups but not restore an RDS for Oracle instance from them, and native point-in-time recovery depends on how often RDS ships transaction logs. Eon keeps Oracle backups in a vault outside production, for as long as your policy needs, and restores at instance, database, table or row level.
Yes. RDS and Aurora into a Google Cloud vault, Cloud SQL into an AWS vault, and Azure SQL Server and PostgreSQL Flexible into AWS or Google Cloud. You can query that backup and restore records from it in the vault's cloud, even while the original is unavailable. A full restore returns the database to the cloud it came from.
Yes. Backups are stored as Parquet and exposed as Iceberg tables, so you can query one directly and confirm what it contains, and what changed, before you commit to a restore.
See it against your own databases
Connect a read-only role to see every database across accounts, projects and subscriptions, what is protected, and what your backups cost. Bring a recovery you have had to do and we will show you how it runs on Eon.