Restore checks

Automatically prove your backups actually restore — Norcube periodically restores a backup into a throwaway database, checks the data came back, and tears it down, so a backup that won't restore is caught before you need it.

A successful backup job only tells you the dump ran. Restore checks tell you the backup restores — Norcube takes a real backup, restores it into a disposable database, confirms the data actually came back, then throws that database away. The result shows up as a Verified mark next to the backup and a Restore health score on the datasource.

A restore check is a normal restore under the hood, tagged as a verification run — so it rides the same isolated workers and produces the same full, redacted log — but it always restores into a throwaway database on a scratch server you nominate, never your live one.

Why verify restores

Backups fail silently in ways a green "backup succeeded" never shows: a subtly corrupt archive, an engine-version mismatch that only bites on restore, a retention rule that quietly aged out the copy you needed. The only real proof a backup works is restoring it. Restore checks automate that proof on a schedule you choose, so "can we recover?" is answered continuously instead of during an incident.

How a check runs

Every check — scheduled or on-demand — does the same four things:

Restores the backup into a fresh, uniquely-named database (norcube_verify_…) on your scratch target, in new-database mode. It never overwrites anything and never reuses the datasource's own credentials.
Validates the result to the depth you configured (see Validation depth).
Tears down the throwaway database it created.
Records the outcome — pass or fail, how deep it validated, duration, and the full restore log.

Because every run gets its own uniquely-named database and is dropped afterwards, repeated checks never collide with a previous run and can't false-pass on stale data.

Restore checks are never blocked by billing status, exactly like manual restores — confirming you can recover data you already backed up is data-care, not a new chargeable commitment.

Where you see the results

Once checks are running, results surface in four places on the dashboard:

Verified column — the Backup jobs table gains a per-backup mark: Verifying… while a check is in flight, Verified once it restores and validates, or Failed if it didn't. A tooltip shows when it last ran.
Restore health card — a status-page-style strip of recent checks on the datasource page, with the pass rate and when the last check ran.
Restore checks tab — the full history of verification runs for the datasource: status, result, validation depth, target, duration, and each run's log. This is where you drill into a failed check to read exactly why it didn't restore.
Datasource list — a compact health bar per datasource, so you can scan recoverability across every database at a glance.

Setting up automated checks

Open the datasource, then Configure on the Restore health card (or the datasource's Restore checks settings). Three choices drive everything:

1. Cadence — how often to check

Cadence	When a check runs
Off	Never automatically. On-demand Verify now still works.
Every N	After every N successful backups since the last check.
On a schedule	On a cron schedule (daily / weekly / fortnightly / monthly presets, or a custom expression).
Random sample	A random share of new backups (5–25%), so checks stay representative without verifying everything.

Scheduled checks always verify the latest successful, still-stored backup at the moment the cadence comes due. If a datasource has no successful backup yet, nothing is checked until the first one lands.

2. Target — where the check restores

Today, checks restore into a scratch database server you provide (customer_scratch): a throwaway Postgres/MongoDB server that isn't your production database. Norcube creates a uniquely-named database on it for each check and drops it afterwards, so the server only ever holds data mid-check.

You supply a write-capable connection string for that server. It's KMS-encrypted at rest with the same envelope as any restore target, never returned by any API, and only ever used to run checks.

The scratch server must be a different server than the one being backed up. Norcube rejects a scratch connection whose host matches the datasource's own host at save time — a restore check must never land on the production server it exists to protect.

The scratch server is reached from the same static egress IP as every backup and restore worker — 18.196.207.101. If it sits behind a firewall, allow that IP on the database port, exactly as for connecting a datasource.

3. Validation depth — how thoroughly to check

Each check climbs a ladder and records the deepest rung it reached:

Restored cleanly (L1) — the archive applied without error. The restore tool exiting 0 is itself a strong signal a backup is usable.
Data present (L2) — additionally, the restored engine is up and the restored database actually contains user tables/collections, not an empty shell.

Postgres checks run the full L1 + L2 ladder today; MongoDB checks currently confirm a clean restore (L1), with deeper data assertions landing next. A deeper custom-query (L3) rung — assert against a query you write — is planned and reserved in the settings, but not yet running.

Verify now (on-demand)

You don't have to wait for a cadence. On any successful backup row, the Verify now action queues a one-off check of that specific backup against your configured scratch target — useful right after connecting a database, or to confirm a particular backup before relying on it. The button is disabled while a check for that backup is already running, and the row's Verified mark switches to Verifying… until it finishes.

Verify now needs a scratch target configured first; without one it tells you to set it up.

Is it safe? What a check touches

Restore checks are built so a verification can never write to the database being backed up:

Always new-database mode. A check only ever restores into a brand-new, uniquely-named database on the scratch target. It never runs an overwrite.
Never the datasource's credentials. Overwrite restores reuse the datasource's stored credentials (your production database); a check never does — it uses only the separate scratch connection.
Refused at dispatch. As a backstop, the platform refuses to launch any verification run that isn't new-database mode, so even a malformed job can't point at production.
Different server, enforced. The scratch host is checked against the source host when you save the configuration (see above).
Cleaned up. The throwaway database is dropped after each check.

The blast radius of a check is therefore a single short-lived database on a server you chose specifically for the purpose.

Following checks

Each verification run uploads its full restore log — the same redacted pg_restore / mongorestore output as a manual restore — kept for passes and failures alike. Open a run in the Restore checks tab to read it; a failed check's log is usually the fastest way to see why a backup wouldn't restore.

A check that loses contact with the platform is marked failed within about an hour, never silently blessed — the same reaper discipline as manual restores.

A Norcube-managed target is coming

Providing a scratch server is the model available today. A fully managed target — where Norcube stands the database engine up inside the verification run itself, so you don't provide any server — is planned. Until it ships, configure a scratch server as above.