Almost every business believes it has backups of its website. Few can confidently answer three questions: what exactly is being backed up, where is it stored, and when was it last checked that it can be restored? Backups are only appreciated on the day they’re needed, and that day is too late to discover they don’t work.
What can go wrong
You don’t need a sophisticated attack to lose information:
- Human error: someone deletes a section, overwrites a file or runs an update that breaks the database.
- An automated attack: malware or ransomware exploiting a known vulnerability.
- A provider failure: servers going down, incidents at the data centre or, simply, a hosting company closing.
- A missed payment or admin problem: if the hosting account is suspended, backups stored in the same place disappear too.
What needs backing up
A website isn’t just “the website”. It usually includes:
- The database: customers, bookings, orders, content. It’s usually the most valuable part and the one that changes most.
- Uploaded files: images, documents, PDF invoices.
- The code: ideally in a version-controlled repository, which already acts as a backup.
- The configuration: environment variables, server settings, domain and email configuration.
If only the files are backed up and not the database (or vice versa), the backup is incomplete.
The 3-2-1 rule
It’s the most widely used standard and is still valid:
- 3 copies of the data: the original and two copies.
- 2 different media or services: for example, the server itself and external storage.
- 1 copy outside the main provider: if everything is with the same company, a problem with that company affects everything.
Frequency: it depends on how much you can afford to lose
The key question is: if you had to restore tomorrow, how many hours of data could you afford to lose? A content website that changes once a month doesn’t need the same as a booking system in peak season.
For a business with online bookings or orders, a sensible minimum is usually a daily backup, and in many cases automatic database backups every few hours.
Retention: don’t keep only the latest one
If the only backup available is last night’s, and the problem started a week ago without anyone noticing, that backup is already “contaminated”. It’s worth keeping several versions: daily ones for the last week, weekly ones for the last month and monthly ones going back several months.
The part almost nobody does: testing restores
A backup that has never been restored is an assumption, not a guarantee. At least a couple of times a year, it’s worth restoring a backup to a test environment and checking that the website starts up, that the data is complete and how long the process takes.
That time matters: if restoring takes a whole day, that’s a day you can’t operate.
What to ask your provider
- What exactly is included in the backups?
- How often are they made, and how many are kept?
- Where are they stored? On the same server?
- How long does a restore take, and who does it?
If the answers are vague, that’s a good sign you should review it before you need it.