Schrödinger's Backup: How Eon Proves Every Backup Restores

A primary database is gone. You open the backup console and every job for the past ninety nights is green. You start the restore, and it fails.

Until that moment, the backup existed in two states at once. The dashboard said it was recoverable. The one test that would have settled the question had never run. A backup you have never restored is neither valid nor invalid until you open the box. That is Schrödinger's Backup, and you learn which state it was in only at recovery time.

The trap is that "backup succeeded" was never a statement about your data. It confirms a snapshot was taken, files were written, and retention was updated. It does not confirm the data reads back, that the application comes up, or that the bytes still match what you sent. Verification closes that gap: reading the data back, checking it against what was captured, and exercising the path you will depend on during an incident.

What the green dashboard actually measures

The green dashboard measures job completion, not recoverability. Backup success rate is popular because it is cheap to observe: job completion shows up every day, while recoverability shows up only during a test or a real incident, so the metric that gets watched is the one that says the least about whether you can recover. In SaaS and cloud especially, a restore point can return data without reconstituting identity, integrations, workflows, or configuration state. "The data is there" and "the system works again" are separate claims.

The gap between believed and demonstrated recoverability is measurable. In the 2025 State of Backup and Recovery Report, 60% of organizations believed they could recover from downtime within a day. Only 35% actually could, and 25% test disaster recovery once a year or less.

Three questions, answered per workload

Every backup, whatever it protects, has to answer three questions. Did the backup actually complete? Is the data still intact? Will the restore work when you run it?

The honest answers differ by workload. A virtual machine, a managed database, a self-managed database on a VM, a NoSQL table, and an object store each fail in their own way, so Eon proves each one in its own way. One rule holds everywhere: an API call that returned OK is never treated as proof. Eon polls the cloud until it confirms the job finished, and its patience scales with the size of what is being protected.

VMs and volumes

Every VM backup includes a restore test. After the snapshot completes, Eon turns it into a volume, mounts it on a worker, and scans the filesystem. The backup passes only if the volume attaches and the filesystem reads cleanly, so most of the restore path is exercised on every single backup. Native cloud backup never checks this.

Capture is atomic across disks. A machine with several volumes gets all of them snapshotted at the same instant, using the cloud's own primitives: AWS CreateSnapshots for instance-scoped multi-volume snapshots, Azure VM restore points, and GCP consistency groups. The result is crash-consistent, the same state a machine is in after a power cut, and journaling filesystems and databases are built to recover from exactly that state, provided every disk agrees on a single point in time.

As data is copied into the vault, every block is hashed. Those hashes do double duty: they drive deduplication, and they are what integrity is measured against. Before each new incremental, Eon validates the existing chain of full plus increments against those hashes, so a broken link is caught before it can carry forward.

Managed databases

For managed databases like RDS, Aurora, Cloud SQL, and Azure SQL, Eon runs the strongest of checks: a live test restore. Periodically, the backup is restored into a temporary database, table fingerprints are recomputed on the restored copy, and the results are compared with the fingerprints recorded at backup time. The comparison covers structure as well as data: tables, views, indexes, stored procedures, roles, and engine parameter settings. A match is empirical proof the backup restores correctly. Databases with a clean track record are checked less often; a single failure makes the checks frequent again. The native snapshot produced by the cloud is retained until verification passes, so a pending proof never leaves you without a recovery point.

The fingerprints are built for this comparison. At backup time every table is fingerprinted: each row is hashed, and the hashes are combined into a compact per-table signature that does not depend on row order, since a restored database will not return rows in the same physical order as the source. The full schema is dumped with the engine's native tools and stored alongside the data, so data corruption and schema drift are both detectable.

Capture is the simple part here. The managed service produces the snapshot itself, already consistent, so verification effort goes into proving the content rather than the capture.

You can also always run the check yourself, without restoring the whole database. Eon stores database backups as queryable Parquet, so a backup or data team can run SQL against a snapshot through Eon's APIs with engines such as Amazon Athena: sample rows from a critical table, filter the ranges that matter, and compare the results with production, with no instance provisioned and nothing rehydrated. The same mechanism supports selective restore, so a single table can come back without restoring the whole database.

Databases on VMs

Self-managed databases like Postgres, MySQL, SQL Server, or Oracle on a VM get the most direct proof in the platform: Eon starts the database on the backup. The snapshot is mounted on an isolated worker, the engine is started on those files, and its normal crash recovery runs, WAL replay for Postgres, InnoDB recovery for MySQL. An engine that comes up and answers queries has demonstrated, rather than implied, that the snapshot contains a recoverable database.

Capture works as it does for any VM: all disks snapshotted atomically, crash-consistent, with no agent inside the machine and no freeze or quiesce. The power-plug state is precisely what the engine's recovery machinery was built for, and the boot test confirms that the recovery actually works on this backup, not just in principle.

Every backup keeps two independent restore paths, and they read from different places. A full database restore comes from the volume blocks: Eon restores the disks, the VM boots, and the engine recovers itself. A single table or a single row comes from the Parquet copy that was extracted while the engine was running on the backup, so you can recover one table without rebuilding the machine around it.

Is crash-consistent safe for a database?

The engines answer this themselves. PostgreSQL's backup documentation describes a snapshot backup as saving the files in the same state as an unclean shutdown, so the engine assumes a crash on startup and replays the WAL, and the docs state plainly that "this is not a problem". MySQL treats it the same way: InnoDB crash recovery applies the redo log and rolls back uncommitted transactions on every start after an unclean stop, and the doublewrite buffer exists specifically to repair pages torn mid-write. Oracle goes further and makes crash consistency a formal supportability criterion: its recovery reference supports restoring from third-party storage snapshots provided the database is crash consistent at the snapshot point, write order is preserved, and the snapshot time is recorded.

The documented risk sits somewhere else. The PostgreSQL page above carries one warning: when data files and WAL live on different disks, the snapshots must be exactly simultaneous. A database smeared across volumes captured seconds apart may not recover, because its disks disagree about when the crash happened. Atomic multi-volume capture is Eon's answer to exactly that requirement, met by construction rather than by luck.

And the theory is never left as theory. Eon boots the engine on the backup, its crash recovery runs, and it has to answer queries. The question "will my database recover from this?" is settled by the database recovering from it.

NoSQL and CDC-protected databases

Databases like DynamoDB, Mongo Atlas, and Keyspaces change while you back them up, so consistency has to be constructed rather than snapshotted. Eon captures these databases through two paths, and both are confirmed to completion rather than assumed: reading the table directly in parallel segments, throttled so production is not affected, or using the cloud's native bulk export. A direct read is not by itself a consistent point in time, because the table keeps changing underneath it. Consistency comes from the pair: the full read plus the change stream covering the entire read window. A cloud export is already a point-in-time copy, and the stream advances from that boundary.

Backup files are verified against their manifests: the item count recorded in each export must match what the files actually contain, and export files are checked against the cloud's own checksums. The change chain gets a stronger test. Periodically, a fresh full backup is taken, and the previous full plus every change captured since it must equal the new full at its consistency point, so a lost or corrupted change event anywhere in the window surfaces as a difference. A stream that goes stale triggers a fresh full immediately.

Every backup writes a manifest, an index of what that backup contains. To restore a point in time, Eon reads the manifests to work out which full backup to start from and which change files to apply on top of it. The restore is then tracked to completion the same way the backup was, rather than assumed to have finished.

Object storage

The first problem in an object store is knowing what changed. Eon discovers it through one of three paths, chosen by bucket size and configuration: a full listing, the cloud's inventory service for buckets with hundreds of millions of objects, or a change stream of bucket events on top of an inventory baseline, re-verified with periodic full listings. Each object is compared with the previous backup by name, size, ETag, and last-modified, so only changed objects are read and nothing that existed is silently skipped. An object that changes in the middle of being read fails its conditional check and is recorded as changed, instead of being stored as a mismatched copy.

Inside the vault, data is chunked and hashed, and those hashes drive deduplication and integrity verification. A dedicated verification workflow walks the vault periodically, and always before any data is purged: every object recorded in the backup manifests must exist in the vault, and the stored hashes must still match the data. The walk proves the backup is complete and readable without paying for a full restore. Restores use resumable multipart uploads that abort cleanly on failure rather than leaving partial objects behind.

The same three answers, side by side

What the architecture guarantees

Not every workload gets the same proof, and claiming otherwise would put this article in the same category as the green dashboard. Every resource type gets completion confirmed by the cloud rather than assumed, and everything that enters the vault is hashed so corruption is detectable. The restore path itself is exercised where it matters most: filesystems are mounted and scanned on every VM backup, self-managed database engines are booted on their backups, and managed databases are periodically restored in full and compared, fingerprint by fingerprint, against what was captured.

Restorability is proven where it can be proven and measured everywhere else. The gap between "the job finished" and "the data is recoverable" is closed with mechanisms you can inspect, and the best inspection is watching Eon recover your own data. See it live in a PoC. Talk to Eon.