Website Backups That Actually Restore
Almost every business has backups. A startling number find out on the worst morning that they do not work. What to have, where, and how to test it.
There is a specific silence that follows the question "when did we last test a restore?". Everybody has backups. Almost nobody has ever put one back.
An untested backup is not a backup. It is a hope with a filename. The difference only becomes apparent on the morning you need it, which is also the morning you have the least time to discover it.
Short version. You need nightly backups, kept somewhere your host is not, retained for at least 30 days, covering both files and the database — and you need to have actually restored one. If you do only one thing after reading this, do the restore test.
What a Complete Backup Contains
A website is two things, and losing either loses the site:
- The files — the code, the theme, the uploaded images and documents. Bulky, changes rarely.
- The database — the pages, posts, products, orders, users and settings. Small, changes constantly, and the part people forget.
A files-only backup restores a website with no content in it. A database-only backup restores your content into nothing. This is the most common way a backup turns out to be half a backup.
Worth backing up alongside them, because they are not on the server: your DNS zone file, your email if it is hosted with the site, and a note of which registrar holds the domain.
The Four Rules
1. Off the Server
A backup stored on the same server as the website protects you against exactly one scenario — deleting a file by accident. It protects you against nothing that actually takes sites down: the server failing, the account being suspended, the host going under, or ransomware, which specifically looks for and encrypts local backups.
2. Nightly, and More Often If You Sell
A weekly backup means your worst case is losing six days. For a brochure site that is survivable. For a shop it means six days of orders, which is not a backup strategy but an incident. If you take orders, you want the database backed up far more frequently than the files.
3. Thirty Days of History, Minimum
Because the problems that need backups are frequently not noticed immediately. A site quietly compromised three weeks ago, or a plugin that has been mangling uploads since a Tuesday nobody remembers. If your retention is seven days, every copy you hold is already infected. Thirty days is a reasonable floor; ninety is better for anything with money in it.
4. Tested
Covered below, because it is the rule everyone skips.
The Twenty-Minute Restore Test
Do this once. Then put a recurring reminder in the calendar for every six months.
- Download a backup to your own machine. Not "confirm one exists" — actually download it. If this step is difficult, you have already learned something important.
- Open the archive. Confirm it contains both a files directory and a database dump, and that the database dump is not 0 bytes. A zero-byte dump is astonishingly common and completely invisible from a dashboard that says "backup successful".
- Restore it somewhere that is not your live site — a staging subdomain or a local environment. Never test a restore over production.
- Click around. Do the images load? Is the newest content there? Does the contact form exist? Can you log in?
- Write down how long it took. That number is your real recovery time, and it is the number to quote when somebody asks how long the site would be down.
If you cannot complete this, you do not have backups, whatever the control panel says. Better to find out on a quiet Wednesday.
The Traps
- "Our host backs up." Many do — for their own disaster recovery, not yours. Check whether you can restore a single site yourself, on demand, without opening a ticket. Check whether it is included or billed. Do not assume.
- Backup plugins that back up to the same disk. Very common, and rule one.
- Silent failures. A job that stopped running in March and never said so. Configure failure alerts, and treat a month with no email from your backup system as suspicious rather than reassuring.
- Backups nobody can reach. Stored in an account belonging to a developer you no longer work with. Ask where they are and who has access.
- Backing up the compromise. Thirty days of retention exists largely for this. See choosing hosting for what to ask a provider up front.
Take One Before You Change Anything
Separately from the schedule: take a manual backup immediately before a plugin update, a theme change, a migration or any bulk edit. It costs two minutes and it is the difference between an inconvenience and an afternoon.
This is also why competent suppliers work on staging rather than live — the whole category of "we changed something and now it is broken" stops applying. It is step four of how we work, and every site on a care plan is backed up nightly, kept off-site and restorable by us, which is the version where nobody has to remember any of this.
Four Questions for Whoever Holds Your Backups
- How often, and does it include the database as well as the files?
- Where are they stored, and is that physically separate from the site?
- How far back can I go?
- Can I restore one myself, today, without raising a ticket — and has anyone ever actually tried?
Hesitation on the fourth is the answer to the fourth.
Common Questions
How Often Should a Website Be Backed Up?
Nightly at minimum. If you take orders or bookings, the database should be backed up more frequently than that, because a weekly backup means a worst case of losing six days of transactions. Files change rarely and can be backed up less often than the database.
Where Should Website Backups Be Stored?
Somewhere physically separate from the website itself. A backup on the same server only protects against accidentally deleting a file — not against the server failing, the account being suspended, the host going under, or ransomware, which specifically seeks out and encrypts local backups.
How Long Should I Keep Website Backups?
Thirty days as a floor, ninety for anything handling money. The problems that need backups are often not noticed immediately — a compromise three weeks old, or a plugin quietly mangling uploads. With only seven days of retention, every copy you hold may already contain the problem.
How Do I Know If My Backups Actually Work?
Restore one somewhere that is not your live site. Download an actual backup, confirm it contains both files and a database dump that is not zero bytes, restore it to staging or a local environment, and click around. Write down how long it took — that number is your real recovery time.
Does My Web Host Already Back Up My Site?
Many hosts back up for their own disaster recovery rather than for you. Ask specifically whether you can restore a single site yourself, on demand, without raising a support ticket, and whether that is included or billed. Do not assume the answer is yes.
