A website backup actually protects you when four things are true: it contains both the files and the database, at least one copy lives somewhere other than your web server, it runs on a schedule matched to how often your site changes, and you have personally seen it restore. Most small sites fail at least two of those — typically keeping 'backups' on the same server that would be lost with it, and never once testing a restore. This guide fixes all four, in order.
Backups are insurance against the specific disasters that actually happen to small sites: a bad update that whitescreens the homepage, a hacked site the host suspends, an accidental deletion, a billing lapse that wipes an account. Notice that in most of those, the server itself is the problem — which is why a backup that lives only on that server is a comforting fiction. The cost of doing this properly ranges from free to a few dollars a month; the cost of not doing it is rebuilding your business's home from memory.
What a Complete Backup Contains
Two halves, both mandatory. The files — your site's code, theme, plugins, and every uploaded image and document (for many businesses the media library is the irreplaceable part; code can be reinstalled, five years of product photos cannot). The database — pages, posts, products, orders, customers, settings: the actual content and records, which on a modern CMS live almost entirely in the database, not the files.
A 'backup' of only one half restores a shell: files without the database give you an empty site wearing your design; a database without uploads gives you text pointing at missing images. Check whatever your host or plugin calls a backup and confirm, in writing in its settings or report, that both halves are in it.
The 3-2-1 Rule, Translated for a Small Website
Backup professionals use a simple formula: 3 copies of your data, on 2 different kinds of storage, with 1 copy offsite. For a small website that translates practically to: the live site itself (copy one), an automatic backup kept by your host or plugin (copy two), and a copy in cloud storage you control — Google Drive, Dropbox, S3-style storage — or downloaded to your own computer monthly (the offsite copy).
The offsite copy under your control is the one owners skip and the one that saves them, because it survives the host suspending the account, the agency relationship ending badly, or the credit card expiring. Automate it — a backup that depends on you remembering is a backup that stops the first busy month. The table gives schedules by site type.
| Site type | Backup frequency | Keep how many? | Notes |
|---|---|---|---|
| Brochure site (rarely changes) | Weekly | Last 4–8 | Plus a manual backup before any edit session |
| Active blog / business site | Daily | Last 14–30 | Content changes daily; so should copies |
| WooCommerce / bookings | Daily minimum; real-time if busy | Last 30+ | Orders exist only in the database — protect them hardest |
| Before updates or changes | Immediately before, every time | Until change is proven | The backup you take last makes updates fearless |
How long a full site restore typically takes by preparation (minutes, illustrative) — hover or tap each bar for details.
Choosing the Method: Host, Plugin or Manual
Three routes produce a backup; they differ in cost, control and how much they ask of you.
| Method | Typical cost | Strengths | Watch out for |
|---|---|---|---|
| Host backups | Included or a small monthly add-on | Automatic, one-click restore, nothing to install | Lives on the same account; retention often short; 'courtesy' status in the terms |
| Backup plugin (CMS) | Free tiers exist; premium roughly $50–150/yr | Sends copies offsite to your own cloud storage; scheduled; restores anywhere | Needs configuration and the occasional check; free tiers cap size or frequency |
| Manual (files + database export) | Free | Total control; no dependencies; works on any stack | Only as reliable as your memory — use it as a supplement, not the system |
For most small sites the strongest practical setup is the middle row, watched by the first: a plugin sending scheduled copies to cloud storage you own, with the host's backups as the convenience copy. Manual exports earn their place at two moments — before a major change, and as the permanent pre-redesign archive described below.
The Restore Test: The Step Everyone Skips
A backup you have never restored is a hypothesis. Once a quarter — put it in the calendar now — restore your latest backup to a test location (a staging subdomain, a local install, or your host's staging tool) and check three things: the site loads, the content is current to the backup date, and the money features work (forms send, checkout opens, bookings save). Time it. That number is your real recovery time, and knowing it converts a 2 a.m. disaster into an inconvenience with a known duration.
Failed restores teach cheap lessons: missing database, backup too large for the tool, a plugin's proprietary format with an expired licence. All are fixable while your live site is healthy — and none are fixable at 2 a.m. with the site down. This is also why our website launch checklist insists the backup system and one test restore happen before go-live, not after the first incident.
How Much Storage and Retention Do You Actually Need?
The sizing maths is simple: backup size × copies kept. A typical small business site is 500 MB to 3 GB complete (media library decides it). Daily backups kept for 30 days at full size would be 15–90 GB — which is why real systems use two tricks you should confirm are on. Compression shrinks text and code dramatically (media barely compresses — it is already compressed). Incremental backups store the full site once, then only what changed, cutting the daily copy to a fraction. With both, a month of daily protection for a typical site fits comfortably in a standard cloud-storage tier.
Retention is a risk decision, not a storage one. The question is how far back a problem can hide before you notice it: a hack discovered after three weeks needs a copy older than three weeks, which is why the table above keeps 14–30 copies and why one permanent pre-change archive sits outside the rotation. If storage pinches, spend it on retention of the database (small, priceless) before the files (large, partly re-obtainable).
Stores: The Orders-in-the-Gap Problem
One limit applies to every restore: it returns the site to the backup moment, and orders placed after that moment are not in it. For a quiet site this is theoretical; for a busy store it is the difference between an inconvenience and lost sales records. Mitigations, in order of effort: keep the backup frequency matched to order volume (the table's daily minimum, real-time if busy); export orders separately on a schedule if your platform allows it — a small spreadsheet is easy to re-import; and if you ever do restore, email customers from the gap window using gateway or payment records, which exist outside the site entirely. Payment gateways keep their own transaction history, so money records survive even when a restore rolls the store back.
The Disaster Playbook: The First Hour, Step by Step
When the site is down or defaced, the first hour decides how much you lose. Work this order:
- Do not delete or 'clean' anything. If you have been hacked, the infected copy is evidence and sometimes the only record of what happened; restoring over it blindly can also re-import the problem. Take the site offline or into maintenance mode if you can, but preserve the state.
- Establish what actually happened. Host outage, expired domain or certificate, a bad update, a hack and a billing suspension look identical from the homepage and need opposite responses. Your host's status page and support chat answer most of this in minutes.
- Find your newest clean backup and date it. 'Clean' matters more than 'recent' after a hack: a backup from inside the infection window restores the infection. This is where the rotating window and the permanent archive pay rent.
- Restore to staging first if anything is uncertain — verify the money features there — then to live. If the failure is at account level (suspension, lost account), the offsite copy in your own storage is the one that lets you rebuild on a new host the same day.
- After recovery, change every password — hosting, CMS, database, FTP — and write down what happened while it is fresh. The hour you spend on notes now is the hour that makes the next incident boring.
Two Backup Myths That End in Rebuilds
Myth one: 'My host handles backups, so I am covered.' Read the hosting fine print and you will usually find backups described as a courtesy, retained for days not months, and restorable only while the account is in good standing — precisely the condition that fails in account-level disasters. Host backups are welcome as one copy; they are not a strategy.
Myth two: 'We are too small to be hacked, and nothing changes anyway.' Small sites are attacked by bots indiscriminately, not by villains choosing targets, and 'nothing changes' ignores the silent changes that do happen: automatic updates, expiring certificates, a plugin abandoned by its developer, a host migrating servers. The sites that lose everything are overwhelmingly the ones that assumed size was protection. The routine in this guide takes under an hour to set up and minutes a month to supervise — cheap certainty against the single most common way small businesses lose their web presence entirely.
The WordPress Version, Step by Step
Most readers run WordPress, so here is the routine above translated into that dashboard — the principles are identical on other platforms.
- Install a reputable backup plugin and connect it to cloud storage you control (Google Drive, Dropbox or S3-compatible storage) — not to a folder on the same server.
- Set the schedule to match your site from the table above: daily for most business sites, and make sure the schedule covers files AND database — some defaults quietly exclude the uploads folder or the database until you tick them.
- Turn on backup-before-update if the plugin offers it, so plugin and theme updates always leave a minutes-old restore point behind.
- Run one backup now and download it. Verify the archive opens and contains a database file (usually a .sql inside the archive) alongside the wp-content files — the two-halves check from the top of this guide, done with your own eyes.
- Do the quarterly restore test to a staging site, and put the date in the same calendar as your other maintenance. A WordPress restore through the plugin is normally a guided, few-clicks job — which you want to discover on a quiet Tuesday, not during an incident.
Backups Inside a Sensible Maintenance Routine
Backups sit inside a small monthly routine alongside updates and checks — the full picture, with realistic USA pricing for paying someone to do it, is in our website maintenance cost guide. The order of operations never changes: back up first, then update, then verify — so any bad update has a clean, minutes-old restore point. Keep login details for your backup storage somewhere you can reach without the website's email working; disasters have a sense of humour about which systems fail together.
One last distinction: backups are not archives. Keep one known-good copy from before any redesign or platform move permanently, separate from the rotating schedule, so a slow-burn problem discovered months later still has a clean ancestor to compare against. And if numbers and fingerprints matter to your verification habits, our guide to generating hashes shows how to prove a stored backup file is bit-for-bit the one you saved.
Do one thing after reading this: check where your backups actually live, and whether the database is in them. Then schedule the restore test. The Asad Webs blog has the maintenance guides to build the rest of the routine around it.
Rather not have backups be your job at 2 a.m.? Book a free consultation — our maintenance plans include scheduled, restore-tested backups, updates and monitoring, so a bad day never becomes a rebuild.
Frequently Asked Questions
How often should I back up my website?
Match the schedule to change: weekly for a static brochure site, daily for an active blog or business site, and daily at minimum — ideally near-real-time — for a store or bookings site, because orders exist only in the database.
Is my hosting company's backup enough?
Host backups are a good second copy but a risky only copy: they live on the same account that can be suspended, hacked or lost over billing. Keep an offsite copy in storage you control.
What is the difference between file and database backups?
Files hold code, themes and uploaded media; the database holds your pages, products, orders and settings. A restore needs both — either half alone gives you a broken or empty site.
How do I test a backup restore safely?
Restore to a staging or local environment, never over the live site, and verify the site loads, content is current to the backup date, and forms or checkout work. Do it quarterly and time it.
How long should I keep backups?
Keep a rotating window of recent copies (daily for 2–4 weeks is typical), plus one permanent known-good copy from before any major redesign or migration.
Can I back up my website completely for free?
Yes. Free plugin tiers plus free cloud-storage tiers cover most small sites, and a manual export costs nothing but time. What free usually limits is frequency, retention length and support — acceptable for a brochure site, riskier for a store taking orders daily. The non-negotiables stay the same at any price: both halves, offsite, restore-tested.
My site is already down and I have no backup. What now?
Do not start rebuilding yet. Check, in order: your host's own backups (many keep short-retention copies even if you never enabled them), your developer's or agency's files, cached copies of key pages in search engines, and the Wayback Machine for your public content. Hosts can sometimes recover recently deleted accounts if you ask quickly. Recover what exists first — then set up the system in this guide the same week, while the lesson is fresh.
Be the first to share a useful question or thought.