DynamoDB backup and recovery
Native point-in-time recovery restores the whole table into a new table, and stops at 35 days. Eon stores only what changed, keeps it as long as your policy needs, and restores a single record.
What Eon backs up
Tables are discovered and protected on their own, and every backup stays searchable down to the record.
Amazon DynamoDB
True incremental capture, so you store what changed instead of another full copy of the table. Restore a whole table, or search the backup and bring back a single item. Global-table aware, and running on tables in the hundreds of terabytes.
Amazon Keyspaces
An initial full export in Parquet, then item-level change capture coalesced into retention points. The stored footprint tracks how much the data changes, not how long you keep it. Restore into a different account or Region for a recovery drill without touching production.
Amazon DocumentDB
Cluster backups with retention beyond the native window, managed under the same policies as your DynamoDB tables.
Restore the records, not the table
When a bad deploy corrupts a few thousand items out of billions, native recovery leaves two options. Cut over to a restored copy of the table and lose every good write since the incident, or copy the damaged items back by hand. Eon finds those items in the backup and restores only them, into the same table or a different one.
Native backup and PITR
Eon
Restore scope
The whole table, into a new table.
A record, a set of records, or the whole table.
Retention
35 days.
As long as your policy needs.
Storage model
A full copy per on-demand backup.
Incremental after the first backup, deduplicated across the vault.
Reading the backup
Restore it first, then query it.
Query it in place, with no table to clone.
Recovery drills
Against production, or not at all.
Restore into another account or Region and check it comes back.
Where copies live
Inside the same account.
An isolated, immutable vault.
When an agent writes to the wrong table
An automation with write credentials can do a lot of damage in seconds, and in many stacks that means NoSQL, where the high-volume application data sits. The next morning you need the damaged records back without losing everything written since. Record-level restore does exactly that.
Query your backups like a database
DynamoDB and Keyspaces backups are stored in Parquet, so you can query them without restoring first. Point Amazon Athena at them and run SQL across DynamoDB, Keyspaces and your relational databases in one place, with no table to clone and no index to build.
What table backup actually costs
On-demand backups are full copies, so a table that doubles in size doubles every backup you take from then on. Looking inside a native backup means restoring it first, which means paying to run a second copy of a large table. Eon stores changes instead of copies, so storage follows how much the data changes.
Incremental after the first backup
Storage tracks change volume, not retention length. Extending retention from 30 days to a year does not multiply the footprint by twelve.
No GSIs to pay for
Backups are queryable as they are. You are not rebuilding secondary indexes on a restored table just to find something.
No clone to investigate
Query the backup directly instead of restoring a table you only need to read.
More on DynamoDB backup
FAQs
Yes. Search the backup to find what you need, then restore those records into the same table, a different table, or a different account. The rest of the table is untouched, so you keep every write that happened after the incident.
As long as your policy requires. Native point-in-time recovery stops at 35 days, which is usually the point where teams start looking, because audit and compliance windows are measured in years.
Backups run incrementally against the table without throttling it. Teams run these every few hours across Regions on tables in the hundreds of terabytes.
No. Backup data is stored in Parquet and queried directly, so you are not paying to maintain indexes for the sake of investigation or audit.
Not necessarily. Some teams keep it on with a short window, seven days or so, for a sub-second recovery point, and use Eon for long-term retention, granular restore and cost. The two are not mutually exclusive.
Yes. Eon backs up MongoDB Atlas clusters for as long as your policy needs, and restores a single collection, a document, a dataset, or the cluster to a point in time.
See it against your own tables
Connect a read-only role to see every table across accounts and Regions, what is protected, and what the backups cost. Bring a recovery you have had to do and we will show you how it runs on Eon.