A familiar case: the server fails on a Tuesday. The hosting panel shows a green tick next to "daily backup", every day for two years. The restore starts, runs for an hour, and produces a database from eight months ago, because that is when the backup job started saving an empty file after a password change. Nobody noticed, because the job never reported an error. It reported success.

The short answer#

A backup is only proven by a restore. Backups fail silently for ordinary reasons: the job backs up the wrong thing or only part of it, a credential change makes it save empty files while still reporting success, the copies sit on the same server or account that failed, retention is too short to go back before a problem started, or nobody knows how to put the data back together. Protect against this by keeping copies in a separate place and account that the main system cannot delete, including everything needed to rebuild, not just the database, checking that each backup file has a plausible size, and running a documented restore test into a separate environment on a schedule. Record how long the restore took and what was missing, and fix that before you need it.

Why backups fail when needed#

The job reports success regardless

A backup script that pipes a database dump into a compressed file can report success when the dump failed, because the compression step succeeded on empty input. The file exists; it is just empty.

Only part of the system is backed up

The database is saved but uploaded files, configuration, environment variables or the email server are not. The data comes back and the application does not work.

Copies live next to the original

Backups on the same server, disk or hosting account are lost with it. Ransomware and compromised admin accounts delete them too.

Retention is too short

If corruption or a compromise went unnoticed for three weeks and backups are kept for seven days, every backup already contains the problem.

Nobody has done a restore

The steps exist in one person's head, or not at all. Under pressure, restoring for the first time takes far longer than expected.

What a backup needs to include#

Databases.
Uploaded files and media.
Application code, or a reference to the exact version in a repository.
Configuration and environment settings, stored securely.
Anything needed to rebuild the server: a list of software and versions, or infrastructure definitions.
For email and documents in cloud services, check what the provider actually restores and for how long.

Where to keep copies#

A common rule of thumb is three copies of data, on two different kinds of storage, with one copy off site. In practice for a small company:

The live system.
A backup in a different account or provider, which the live system's credentials cannot delete.
A copy with versioning or write-once protection, so a compromised account cannot erase history.

Encrypt backups that contain personal data, and keep the key somewhere other than the backup location.

Running a restore test#

Pick a date and a system. Start with the one the business can least afford to lose.
Restore into a separate environment, never over the live system.
Start the application and check real data: recent orders, recent documents, user logins.
Record how long it took, from starting to a working system.
Record everything that was missing or had to be fixed by hand.
Update the restore instructions with what you learned.
Fix the gaps, then repeat the test on a schedule, at least quarterly for critical systems.

Also check the backups themselves regularly: file sizes that suddenly drop, or jobs that stopped running, are the early warning.

What to measure#

How recent is the latest backup that actually restores? That is how much data you can lose.
How long does a full restore take? That is how long the business is down.

If either answer is unacceptable, that is the next thing to improve.

When a system is already down, restoring is only one of the decisions in the first half hour, covered in the site is down: the first 30 minutes.

Nevo carries out cybersecurity audits. The cybersecurity audits page describes what an audit covers.

Backups that do not restore