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.
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.
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.
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.
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.
Be the first to share a useful question or thought.