The thing nobody checks
"Backup succeeded" does not mean the file contains your data. It does not mean the file loads. It does not mean anything comes back out of it. It means a write finished.
Developers find this out at the worst possible moment, and they say so:
"We tried to restore 3 backups as a test, and they all failed."
"Finding out your backup is broken during a critical migration is not fun."
Three out of three. That is the normal case, not the horror story.
What verification actually requires
A backup is only verified if something loaded it and read data back. Checking the file is non-zero proves nothing. Checking a checksum proves the file did not corrupt in transit, not that it contained rows in the first place.
The only honest check is a restore:
- Load the backup into a throwaway database
- Run a real query against it
- Count what came back
- Throw the database away
CrescoDB does this on a schedule and reports the result. If a backup restores empty, it is reported as a failure, not a success. That one word is the whole difference.
The honest cost
Restoring on a schedule uses your own disk and your own CPU, because it runs on the server you own. So it runs off-peak, it is capped, and there is a per-app switch. Anyone telling you verification is free has not implemented it.
The same problem with uptime
A container in a crash loop reports "running" to every tool that asks, because it just started, again. A process check will tell you everything is fine while your app is unreachable.
The only useful check asks the app whether it can answer. CrescoDB does that and alerts you by email or WhatsApp when it stops, so you hear it from us rather than from your client.
How to check this yourself, on any platform
Whatever you use, do this once this month: take your most recent backup, restore it somewhere disposable, and count the rows. If it works you have learned your backups are real. If it does not, you have learned it on a Tuesday instead of during an outage.