Backups you can actually restore: why verification matters
A backup that has never been verified is a hope, not a guarantee. Why integrity checks — not just successful dumps — are the difference between recovery and disaster.
Here's the uncomfortable truth about backups: the moment you find out yours are broken is almost always the moment you need them. The dump ran every night for a year. The job said "success." The file was there. And then, mid-incident, the restore fails — truncated, corrupted, or silently missing half the tables.
"The job succeeded" is not "the backup is good"
A backup pipeline has many places to fail after the part everyone watches. A dump can complete and still be corrupted by a flaky disk. An upload can report success while dropping bytes in transit. Encryption can scramble a file that was already broken. "Exit code 0" tells you the process finished — it tells you nothing about whether the artifact you now hold can be read back.
This is why so many teams discover their backups are worthless at exactly the wrong time. They optimized for backups that run, not backups that restore.
Verification: checksums, end to end
xbackupman computes a SHA-256 checksum of every backup at the moment it's created, and stores it alongside the artifact. Verification re-downloads the backup from your storage, decrypts it, and re-computes the hash. If the two don't match — bit rot, a partial upload, a storage-side corruption — you find out on your schedule, not during an outage.
- Integrity at rest: catch silent corruption in your bucket before it's the only copy that matters.
- Round-trip proof: verification exercises the exact decrypt-and-read path a real restore uses.
- Confidence on demand: trigger a verify from the dashboard, the API or the xbm CLI whenever you want fresh proof.
Restores that assume the worst
Verification is only half the story. A restore should be as boring and predictable as a backup. xbackupman restores into an empty destination by default and requires an explicit confirmation before it will overwrite a live target — so a recovery never turns into a second incident because someone pointed it at the wrong database.
Build the habit, not just the tooling
The teams who sleep well don't just take backups — they routinely prove they can restore them. Schedule verification. Do the occasional real test restore into a scratch environment. Treat an unverified backup as unproven, because it is.
A verified backup is a promise you've actually kept. An unverified one is a promise you're hoping you won't have to break.