A nightly dump that has run successfully for two years proves that the dump command exits zero, which is a different claim from the data being recoverable.
#!/usr/bin/env bash
set -euo pipefail
file="/backup/shop-$(date +%F).sql.gz"
mysqldump --single-transaction --routines --triggers shop | gzip > "$file"
# the checks that make the exit code mean something
[ "$(stat -c%s "$file")" -gt 1000000 ] || { echo 'suspiciously small'; exit 1; }
gzip -t "$file"
zcat "$file" | tail -1 | grep -q 'Dump completed'The trailing marker is what distinguishes a complete dump from one truncated by a disk filling halfway through, and a truncated dump restores without complaint right up to the point where the data stops. --single-transaction gives a consistent snapshot on InnoDB without locking, and omitting --routines is how a restore ends up missing every stored procedure. The size floor catches the case where the database name was wrong and the dump is a valid, empty file.