Get in touch
Have a project in mind? Tell us a bit about it.
Ask ten small business owners whether their website is backed up, and nine will say yes. Ask them when the backup last ran successfully, whether it’s stored somewhere other than the same server as the site, or whether anyone has actually tried restoring from it, and the confidence usually drops fast. A backup you’ve never tested is a theory, not a safety net. It’s only proven the moment you need it, which is exactly the wrong time to find out it doesn’t work.
Disaster recovery for a small business website isn’t complicated, but it does require deciding on a few things in advance rather than improvising during an outage. Here’s what an actual plan looks like, not the version that exists only as a checkbox in a hosting dashboard.
What you’re actually protecting against
“My site could go down” covers a lot of different failure modes, and the right backup strategy depends on which ones you’re realistically exposed to. A bad plugin update that white-screens the site is recoverable in minutes if you have version history. A compromised admin account that a bad actor uses to inject malicious code is a different problem, because the malware might sit in your backups too if you don’t catch it before your retention window rolls over. Accidental deletion, a wrong click in the database, or a developer running a migration script against production instead of staging is another category entirely, and it’s more common than most owners assume. Each of these wants a slightly different kind of protection, and lumping them all under “we have backups” is how gaps get missed.
The 3-2-1 rule, applied to a website instead of a server closet
The old IT backup rule still holds: three copies of your data, on two different types of storage, with one copy stored somewhere physically separate from the original. For a website, that translates to something like this. One copy lives on the same server as an automated daily snapshot, which is fine for quick same-day rollbacks. A second copy goes to off-server storage, an S3 bucket, a separate cloud storage account, anywhere that isn’t the same host account as your site, because if that account gets compromised or the host has an outage, a backup sitting in the same place is worthless. A third copy, updated less frequently, sits somewhere you control directly, downloaded and kept off any third-party platform entirely. If your only backup lives in the same hosting account as your live site, you don’t have a backup strategy, you have a snapshot feature, and those aren’t the same thing when the whole account is what’s at risk.
Database and files are not the same backup job
A full website backup has two parts that often get treated as one: the file system (themes, plugins, uploaded media, core files) and the database (posts, pages, settings, form entries, everything that actually changes day to day). Files change slowly, most weeks nothing but a plugin update touches them. The database changes constantly, especially on a site actively generating leads or content. If your backup schedule treats both the same way, say, a weekly full backup, you’re fine for the files but potentially losing days of database changes, form submissions, orders, published content, in a worst-case restore. A more sensible split is daily database backups and weekly (or post-update) file backups, which matches the backup frequency to how fast each part actually changes.
Retention windows matter more than people think
A backup that overwrites itself every 24 hours protects you against almost nothing except a single bad night. If malware sits dormant for three days before doing visible damage, and your retention window is 48 hours, every backup you have is already infected by the time you notice. A reasonable minimum for most small business sites is 30 days of daily backups, with weekly snapshots retained for a few months beyond that. It costs more storage. It’s also the difference between a clean restore and starting over.
The restore test is the part almost everyone skips
This is the step that separates a real disaster recovery plan from a backup plugin left on default settings. At least once a quarter, actually restore a backup, ideally to a staging environment, not production, and confirm the site comes back up, the database connects, and nothing’s missing. This catches the failure modes that never show up until it’s too late: a backup that’s been silently failing for weeks while the plugin dashboard shows a green checkmark, a database dump that’s missing a table because of a permissions issue, a file backup that excludes an upload directory nobody remembered to include. None of this is visible from a backup log that just says “success.” It’s only visible when you actually try to use it.
Who has access, and what happens if they don’t answer the phone
The last piece isn’t technical, it’s operational. If your site goes down at 11pm on a Saturday, does anyone know how to log into the hosting account, the backup service, and the domain registrar without waiting for someone else to wake up? Password manager access, a documented list of where each credential lives, and at least two people who can act on it, not just one developer who happens to be reachable, turns a potential multi-day outage into a same-day fix. Write it down before you need it. Reconstructing “who has the login” during an actual outage adds hours to a problem that backups alone were supposed to solve.
What this actually costs
A proper setup, off-server storage, a backup plugin or managed host feature with a real retention window, and the discipline to test restores, runs a small monthly cost that’s genuinely trivial next to the cost of rebuilding a site from scratch or losing a week of leads while you figure out what happened. The gap between “we have backups” and “we have a disaster recovery plan” is mostly about testing and separation, not about spending significantly more. It’s one of the few places in website maintenance where doing it properly barely costs more than doing it in a way that only looks like it works.
