Skip to content
💾

Backup verification — the part everyone skips

A backup that's never been restored is a hopeful blob of bytes. Vloud verifies every archive on a schedule, and surfaces failures the moment they happen.

The most expensive thing about a backup isn’t the storage. It’s discovering, the day you need it, that it doesn’t restore.

We’ve watched too many teams operate on the silent assumption that their nightly cron-job + tarball + S3 upload constitutes a backup strategy. It doesn’t. It’s a hopeful blob of bytes that might restore. If nobody’s tried, you don’t know.

What “verified” means in Vloud

Every backup archive Vloud creates carries:

  • An embedded manifest at ./.vloud/manifest.json with the file count, byte count, and source kind
  • A SHA-256 of the archive’s contents
  • A reference to the parent archive (for incremental chains)

After upload, the archive’s SHA is recorded in backup_runs.archive_sha256.

Once a day, every job runs a fast verify against its newest run: re-stream the archive (or a head/tail sample for very large ones), recompute the hash, compare. Once a week, every job runs a full verify: stream the entire archive, decompress, validate the manifest matches.

What “incremental chain integrity” means

If you run incremental backups, every nth run is a fresh full (we call it the chain root) and every other run captures only what changed since the previous one. A corrupt link in the chain means restoring to anything past that link is impossible. Vloud:

  • Verifies the chain integrity after every incremental
  • Forces a fresh full on the next run if it detects corruption
  • Refuses to delete a parent run while its child incrementals are still active

What happens on a failed verify

The run transitions to corrupt. A critical-severity notification fires. The job’s Backup Health sub-score drops to zero until the next clean run. The dashboard’s hero score reflects it within seconds.

This isn’t a quiet log entry buried in a config file. It’s the same class of alert as “malware detected” or “intrusion event.” A corrupt backup is an emergency.

What we deliberately don’t do

We don’t auto-delete corrupt archives. We preserve them for inspection. We don’t automatically re-run the failed job (which might just produce another corrupt one). We surface the failure, document it, and let the operator decide.

Same value as the rest of the platform: backup is real or it’s a lie. There’s no in-between. We chose to do the work that makes it real.

← Back to all posts