In this guide 6 sections
Restore a recent backup onto a clean server. Compare record counts and uploaded files with production, log in, run a normal task such as raising an invoice, and note every step that fails. Whatever fails, such as uploads, environment files or scheduled jobs, is what your backup was missing, and each gap needs an owner.
A green backup job proves very little
Most backup tools report success once the file is written, yet none can tell you whether that file holds the invoices and uploads you need. An empty dump still counts as a pass.
The only proof is a restore. Treat the first drill as a discovery exercise, since you will probably find gaps, and finding them before a real failure is the whole point.
Pick a quiet afternoon. Tell the team. Warn support. Keep production untouched throughout.
Prepare a clean server and the right backup
Start a fresh virtual machine with the same operating system and runtime versions as production, and do not copy the old server. A clean machine exposes everything the backup forgot.
Choose last week’s backup, not last night’s. Fetch it from the offsite storage location the way a stranger would, using only the written instructions, and write those steps down as you go if none exist.
Note the time each step takes. That total becomes your real recovery time, and it is usually far longer than owners expect, because downloading a dump and rebuilding indexes takes hours nobody planned for.
- Same OS and runtime versions
- Backup fetched from offsite storage
- Written steps followed exactly
- Start and finish times logged
Rebuild it and compare the numbers
Restore the dump into an empty instance. Watch for schema errors, then count rows in the main tables, such as customers, orders and invoices, and compare them with production counts taken at the same moment.
Next, check attachments. Pick ten uploaded files, such as scanned purchase orders or profile photos, and open each from the restored copy to confirm none is a zero-byte stub. Then compare the uploads folder size with production.
Look at the most recent records. A backup that stopped capturing data three weeks ago can still pass a total count check, so inspect the latest dates and the newest invoice number.
List what the backup did not contain
Try to start the application. It will often fail on a missing environment file holding database passwords, mail settings and API keys, which are rarely in the dump and sometimes exist nowhere else.
Then check scheduled jobs. Cron entries, queue workers and invoice reminders usually live on the server, so note every job that did not come back, along with certificates, firewall rules and DNS settings.
Log in as a staff member and run a real task, such as raising an invoice and printing it with the next invoice number. If that works, the restore is genuine.
- Uploaded files and attachments
- Environment and config files
- Cron jobs and queue workers
- SSL certificates and DNS records
- Third party webhooks pointing at the old host
Fix the gaps and repeat the drill on a schedule
Give each gap an owner. Add the uploads folder to the backup, store the environment file in a secrets vault and export the cron list alongside the database.
Repeat the drill after every fix until the clean server runs without help, and book it quarterly for important systems with a different engineer each time so knowledge spreads. It is a small habit. It pays off.
Ask who last restored a backup, and when. If nobody remembers, book the drill today.
Restore drill record
One record in three parts. Part one holds the backup file name, date, storage location and server specification, so a stranger can repeat the drill exactly as written. Part two is a checks table covering row counts per table, sample files opened, login, a test task and scheduled jobs restored from the cron list. Part three records each gap found, its owner and fix date, plus the total restore time measured from the first command to the first successful login.
Open a blank worksheet to printQuestions owners ask
How often should I test a restore?
Quarterly suits most business critical systems, and again after any major change to hosting, database version or backup tool, since any of them can break the restore path. Small internal tools can be checked twice yearly.
Can I test a restore on the production server?
Avoid it. Restoring over live data can destroy it, so use a separate machine and keep production credentials out of the test environment, including database passwords and mail settings.
What is the difference between a backup and a snapshot?
A snapshot captures a disk at one moment and usually lives with the same provider, which means one account problem can remove the server and its snapshots together. A backup is a separate copy, ideally offsite. Both need restore tests.
Who should run the drill?
Someone who did not set up the backups should run it, following only the written steps and asking nobody for help until they are properly stuck. That shows whether the written steps would survive a real emergency, when the original engineer is on leave or has left the company.