Backups and Disaster Recovery for Small Business Websites

A website backup is a complete, restorable copy of your site's files and database, taken regularly and stored somewhere separate from the live server, so that if your site is hacked, corrupted, or the hosting server fails, you can put it back exactly as it was rather than starting over. Disaster recovery is the broader plan for what happens next: who restores it, how long it takes, and how you keep the business running while that happens. Most small businesses have neither in any real, tested form, which is fine until the day it very much isn't.

What a Real Backup Actually Includes

A backup that only saves your files, and misses your database, isn't a full backup, and the reverse is true too. A complete website backup needs both: your files (CMS core files, themes, plugins, and uploaded media like images and documents), and your database (every page, post, product, order, form submission, and setting, which for most CMS platforms is where the actual content lives). Losing the database while keeping the files, or the reverse, still means losing your site in any practical sense, since neither half works without the other.

Where Backups Should Actually Be Stored

A backup stored only on the same server as your live site protects you from almost nothing, because if that server fails, gets hacked, or gets deleted, your backup goes with it. This is one of the most common backup mistakes: assuming a backup exists because the hosting dashboard shows one, without checking where it's physically stored.

• Store backups in at least one location separate from your live server, such as cloud storage (Google Drive, Amazon S3, Dropbox) or a dedicated offsite backup service.
• Keep more than one recent backup rather than only the latest one. If corruption happened a week ago and nobody noticed, your most recent backup could already contain the problem.
• A common, sensible pattern is the "3-2-1" rule: three copies of your data, on two different types of storage, with one copy kept offsite.

How Often Should Backups Run?

This depends entirely on how often your site's content changes. A simple brochure site that rarely changes might only need weekly backups. An active e-commerce store taking orders every day needs daily, or in some cases near-continuous, database backups, because losing even a day of order data is a genuine business problem, not just an inconvenience. Ask yourself honestly: if you lost everything that happened on your site since the last backup, how much would that actually cost or disrupt you? That answer tells you your ideal backup frequency.

Backups You Never Test Are Not Backups

This is the single most overlooked part of backup strategy. A backup file that exists but has never been restored might be corrupted, incomplete, or incompatible with your current server environment, and you'd have no way of knowing until the moment you actually need it, which is the worst possible time to find out. Periodically, restore your backup to a separate staging site, not your live site, and confirm the result actually works: pages load, forms function, the database is intact. Do this at least a few times a year, and definitely after any major change to your hosting environment. It's the same discipline we recommend in our guide to ongoing website maintenance: things you assume are fine tend to stay fine only because nobody's checked.

What Disaster Recovery Adds on Top of Backups

Having a backup answers "do we have a copy." Disaster recovery answers the harder questions: who's responsible for restoring it, how long will that realistically take, and what do customers see in the meantime. A basic disaster recovery plan for a small business website should cover who to contact (your hosting provider's support process, and your developer or agency's emergency contact, written down somewhere accessible even if your main systems are down), access (login credentials for hosting, domain registrar, and CMS admin, stored securely but accessibly, a password manager with shared access works well for this), restore steps (even a rough written outline of "restore the latest backup, verify these key pages, check the database, update DNS if the server changed" saves real time under pressure), and a communication plan (a simple way to let customers know if the site will be down for a while, such as a status update on social media or a holding page hosted elsewhere).

What Realistic Recovery Time Looks Like

For a well-prepared small business with tested backups and a clear process, restoring a website after most disasters (hacking, accidental deletion, server failure) typically takes anywhere from under an hour to most of a day, depending on site size and complexity. Without tested backups or a clear process, the same recovery can stretch into days or, in bad cases, become impossible if no usable backup exists at all.

Common Disaster Scenarios Worth Planning For

A site that's hacked or infected with malware needs cleaning and restoring from a backup taken before the compromise, not the most recent one if that one's also infected. For prevention, our website security basics guide covers the fundamentals that stop most of these incidents before they start. Accidental deletion happens more often than most owners expect: someone on your team deletes a page, product, or the entire site by mistake. Hosting server failure is rare with reputable hosts, but not impossible, and it's the reason offsite backups matter regardless of how much you trust your host. A failed update, where a plugin or software update breaks the site, is often fixed fastest by rolling back to the pre-update backup. And domain expiry or loss isn't technically a hosting disaster, but it produces the same result, a site that's unreachable, and it's entirely preventable with auto-renewal.

Ransomware Changes the Backup Calculus

Ransomware attacks encrypt or lock a website's files and database and demand payment to restore access. What makes this scenario different from ordinary hosting failures is that a backup connected directly, and constantly, to the live server can sometimes be encrypted right along with everything else, especially if the backup storage is mounted as an accessible drive rather than kept genuinely separate. The National Cyber Security Centre and other national cybersecurity bodies specifically flag this as a reason offsite, disconnected backup storage matters: a backup an attacker can reach and modify isn't meaningfully different from having no backup at all. Keeping at least one backup copy in storage that isn't continuously writable from the live server, sometimes called an immutable or air-gapped backup, is worth asking your host or developer about if this scenario concerns you.

Choosing a Backup Tool or Service

Backups generally come from one of three sources, and it's worth knowing which one you're relying on: a plugin installed on the site itself (convenient, but it stops working if the site itself is badly compromised), a feature built into your hosting plan (often the easiest option, but check what it actually covers and where it stores copies), or an independent third-party backup service that connects to your site externally (more resilient since it doesn't depend on the site being healthy to take a backup, though it usually costs extra). For anything beyond a simple brochure site, layering at least two of these, for example a host-level backup plus an independent offsite copy, is a sensible middle ground between cost and real protection.

Making This Someone's Actual Responsibility

The most common reason backup and recovery plans fail isn't a lack of tools. Most hosting providers include backup features by default. It's that nobody in the business actually owns checking that they're working. This is exactly the kind of decision covered in our comparison of managed IT support versus building an in-house team, since "who owns this" is really the core question either way. Assign it explicitly to someone, whether that's an in-house person, your hosting provider, or a maintenance service, and put a recurring reminder on the calendar to actually verify a restore, not just assume the backup succeeded because no error email arrived. The US government's cybersecurity agency, CISA, publishes similar recommendations aimed at small organisations if you want a second, independent source to point a skeptical business partner toward. If you'd rather have this set up and tested properly rather than guessed at, get in touch and we'll walk through what your specific site actually needs.

Frequently asked questions