Why website backups are not enough

Most website owners can say that backups are taken. Far fewer can say what is in them, how long they are kept, where they are stored or when they were last restored. The existence of a backup file is a weak form of assurance.

A backup is a copy of something at a point in time. Recovery is the process of turning that copy back into a working service. The second part is where most backup arrangements are actually tested, usually during an incident.

A backup is not automatically a recovery plan

A file archive without the database may restore the application but not its content. A database dump without uploaded files may restore the records but leave every document missing. A backup stored on the same server protects against an accidental deletion but not against the loss of that server.

Recovery also takes time. Restoring a large site, applying database changes that happened after the backup and reconfiguring DNS or email can take hours. If the business has an expectation of how quickly it must be back, that expectation needs to be compared with the actual recovery route.

What to verify

• What is included: code, database, uploads, configuration and email?
• How often copies are taken, and how much data loss that implies.
• Where copies are stored and whether they are isolated from the server.
• How long copies are retained and how deletion is handled.
• Who can access and restore them without depending on one person.
• Whether a restore has been tested, and what the result was.
• How long a realistic recovery takes, including verification.

Backups need an owner

A backup that runs on a schedule is useful only if someone checks that it completed and responds when it does not. Disk space fills, credentials expire, retention policies delete more than intended and a job can fail silently for weeks.

The owner also needs the authority to restore. In some organisations the hosting provider holds the backup, the developer holds the application access and nobody holds the recovery decision. That ambiguity is the problem a recovery plan should remove.

Write the recovery route down

A short runbook is more valuable than a complicated policy. It should name the systems, the backup locations, the restore steps, the verification checks and the people responsible. It should be kept somewhere accessible when the website is not.

The question is not whether backups exist. It is whether the business can get back to a known working state, and how long that takes.

Backups are necessary. They are not sufficient. The difference is made by testing, by documenting the recovery route and by giving someone clear responsibility for both.