Almost every business says it has backups. A much smaller number have restored one on purpose. The gap between those two is where data loss lives.
The only test that counts
Restore something. Pick a file, or better a whole system, and bring it back into a test environment. Until that has happened, a backup is an assumption about a process nobody has watched end to end.
Do it on a schedule. Backups fail silently — a changed password, a full disk, a job that has been erroring for months into a mailbox nobody reads.
Three copies, two media, one elsewhere
The old rule holds: at least three copies of the data, on two different kinds of storage, with one off-site. A backup on the same server is protection against a deleted file and nothing else — not fire, not theft, not a compromised machine.
What usually gets missed
- Databases, when the backup copies files but not a consistent dump.
- Uploaded files, when the database is backed up but the media directory is not.
- Configuration and environment variables — recoverable in theory, a bad week in practice.
- Anything living only in a SaaS account: mail, accounting, design files.
- Somebody's laptop, which turns out to hold the only copy of something important.
Ransomware changes the requirement
Backups reachable from the machine being backed up can be encrypted along with it. This is why off-site and versioned matter: you need a copy from before the incident, that the compromised system could not reach or overwrite.
How long recovery takes
Two questions worth having answers to: how much work can you afford to lose, and how long can you be down? Those decide backup frequency and how the restore path is built. "Nightly" sounds fine until you realise it means a full day of orders.
How we approach it
Backups and restore testing are part of our server management, not an optional extra — a server without a tested restore is a server waiting to lose something.
Ask us to review what you have. Related reading: what website maintenance actually involves.