The backup that was not there
Every website owner believes their site is backed up. The host does it, or a plugin does it, or the developer set something up years ago. The belief is tested the day the site is hacked, or a bad update wipes a page, or the hosting account is deleted by mistake, and the answer to "restore from backup" is: the backups stopped in March, or they are on the same server that just died, or the file is there and nobody knows how to use it.
A backup is not a setting. It is a copy, somewhere else, that you have proven you can restore. Here is what that means in practice.
What a backup contains
A website is two things: files and a database. The files are the platform, the theme, the plugins and every image ever uploaded. The database is every page, post, setting, user and order. A backup that has one without the other is half a site. A files-only backup restores a design with no content; a database-only backup restores content into nothing.
A real backup is both, taken at the same moment so they match.
Where it should go
Not on the same server as the site. If the server fails, is compromised or is deleted, backups on it go with it. The copy has to live somewhere the site's own failure cannot reach: a separate cloud storage account, the backup service's own storage, or at minimum a different server.
Ideally two places. The host's own backups are convenient and are fine as the first line. A second, independent copy going to storage you control is what protects you if the host has the bad day.
How often
Daily, for a site that changes daily: new bookings, orders, posts. Weekly is defensible for a brochure site nobody edits, but daily costs almost nothing extra and removes the question. Before every update or change, an additional on-demand backup so there is a known-good point to return to.
Retention matters too. A daily backup that overwrites yesterday's is one day of protection. If a problem is discovered a week after it happened, you need the backup from before it. Keep daily copies for a month, weekly for a few months.
How it is tested
This is the step that separates backups from hope. Periodically, a backup is actually restored, to a staging copy rather than to the live site, and checked: does the site load, are the pages there, do the images appear, can you log in. If the answer is yes, the backup is real. If the answer is no, you have learned it on a Tuesday rather than during an emergency.
Quarterly is a reasonable rhythm for a full restore test. Monthly is better on a site whose bookings are its income.
A backup service that reports "backup completed" every day is reporting that it wrote a file. It is not reporting that the file is usable.
How a restore happens
When something goes wrong, the sequence is:
- Decide what to restore. A single deleted page might be restored from the database alone. A hack usually means a full restore of files and database from before the compromise. A bad update might be a files-only restore of the plugin folder.
- Choose the point in time. The most recent backup from before the problem. This is why retention matters and why knowing when the problem started matters.
- Restore to staging first, if time allows, and check it. Then push to live. If the site is down and time does not allow, restore to live and check immediately.
- Re-apply anything that happened since the backup. Orders, bookings, posts. This is why daily beats weekly: less to redo.
- Fix whatever caused the problem before it happens again, or the restore is temporary.
A practised restore takes under an hour. An unpractised one takes a day and a lot of guessing.
The questions to ask whoever manages your site
- Where do the backups go, and is it a different place from the server?
- How often are they taken, and how long are they kept?
- When did you last restore one, and did it work?
- If the site went down right now, how long would a restore take?
Clear answers to all four mean your site is backed up. Vague answers mean it is hoped for.
What we do
Daily backups of files and database to storage separate from the host, kept for a month, with a restore test to staging every quarter and an on-demand backup before every update. It is on every care plan tier, because a care plan without a tested backup is not looking after anything. And when a site arrives for a diagnosis, "when did you last restore a backup" is one of the first questions, because the answer tells us how much risk the business has been carrying without knowing.