Quick answer: A backup is only proven when you have restored from it. Test on three levels: automatic checks that files arrived (sizes, checksums), tool-level verification (restic check, gzip -t), and a periodic full restore drill onto a scratch server. Schedule all three — hope is not a strategy.
Overview
Backups fail silently: a cron job that stopped months ago, dumps of a database that was already corrupt, archives truncated by a full disk. Each failure mode is invisible until you need the backup — unless you test. The good news: most testing can be automated.
Before you start
- A working backup pipeline (example setup) and access to its target.
- A scratch environment for restore drills — a small temporary VPS works perfectly.
- A checklist of what "restored correctly" means for your app: site loads, logins work, latest data present.
Step-by-step guide
- Every run — existence and freshness: alert if today's backup is missing or suspiciously small:
find /srv/backups -name 'db-*.sql.gz' -mtime -1 | grep . || echo "ALERT: no fresh backup" - Every run — archive validity:
gzip -t db-2026-07-15.sql.gz && echo OK tar -tzf files-2026-07-15.tar.gz > /dev/null && echo OK - Weekly — checksums or repo check:
sha256sum -c backups.sha256 restic check # or: borg check - Monthly/quarterly — restore drill: spin up a scratch server, run your restore procedure end-to-end, click through the app, note how long it took.
- Record results — a one-line log per test builds the confidence (and the paper trail) that your recovery actually works.
Common issues
- Testing only that files exist: a truncated dump "exists"; only an import proves it loads.
- Restoring to production as the test: drills belong on scratch machines — never risk live data to verify a backup.
- One good test, then years of faith: pipelines rot as apps evolve; put drills on the calendar.
When to contact support
Need a short-lived VPS for restore drills, or seeing I/O errors during verification on a Storage VPS? Open a ticket — hardware-level checks are on Cloud2Y.
Frequently asked questions
How often should I run a full restore drill?
Quarterly for most setups, and after any major change to the stack or the backup scripts. A drill on a scratch VPS also measures your real recovery time, not a guessed one.
What is the quickest automated integrity check?
Verify archives after each run: "gzip -t" for compressed dumps, "tar -tzf" for tarballs, or "restic check" / "borg check" for repositories — plus an alert if today's backup is missing.
Is checking file existence enough to trust a backup?
No. A truncated or corrupt file still exists. Only tool-level verification and an actual test import or restore prove the backup can really bring your data back.
Related articles
- How to restore a website from backup
- How to create a disaster recovery plan
- How to automate backups with cron
- Common backup mistakes
Need a hand? Contact Cloud2Y support →
