Most small business sites have a backup of some kind, and most of those have never been tested. The usual failure is not that the copy is missing. It is that the copy sits in the same account as the site, covers only half of what the site needs, or cannot actually be restored. This note covers what to copy, where to keep it, how often, and how to prove it works.
It is about the website itself. Email and shared documents are a separate job.
What to back up
A website is more than the pages you see. Think in four groups.
Files. The code, theme, plugins, uploaded images and documents, and configuration files. For WordPress, the project's own backup guidance says the database and the files are separate and that you need both. Its list of files includes core, plugins and themes, uploaded images and files, and configuration files such as wp-config.php.
Database. Anything the site stores as records: pages and posts, user accounts, comments, orders, and the form submissions you keep. This is often the part that changes most and the part people forget.
Original content. The master copies of your photos, logo files, price lists and written text, kept somewhere other than the site. If the site vanishes, these are what you rebuild from. On a hosted site builder where you cannot copy the site's files, check whether the platform offers an export, and keep your originals regardless.
DNS records. The records that point your domain to the site and to your email: A, CNAME, MX and TXT entries, including the ones for email authentication. Some DNS hosts can export them as a standard zone file. Where yours cannot, copy each record's type, name and value into a table or take screenshots of the full list. Without this, a restored site may still not be reachable, and a missing MX record can mean lost mail.
The 3-2-1 idea, in plain words
Canada's Cyber Centre states the rule as: keep three copies of your information (the original and two backups), on two different kinds of storage, with one copy kept off site. It also recommends keeping a backup offline, encrypting sensitive data, and testing your backups.
For a website that could look like this:
- The live site on the host (copy one).
- A backup the host or a plugin makes automatically, stored on the host or its backup storage (copy two).
- A copy downloaded to storage you control, away from the host, such as a cloud drive in your own business account or an external drive kept elsewhere (copy three).
The point of the third copy is that your hosting account can be suspended, hacked or closed, and a backup inside it goes down with it. If the files include customer details, such as saved form entries, protect the copy with encryption and limit who can open it.
How often
Match the schedule to how much you can afford to lose. The WordPress documentation suggests a small site with few posts might be backed up about weekly, a busy site daily, and any site before an upgrade or a move. The Cyber Centre likewise says to set the frequency, daily, weekly or monthly, according to what you cannot lose.
A simple rule to start from: a brochure site that changes a few times a year needs a backup after each change plus a monthly one. A site that takes bookings or orders needs the database copied daily.
Also keep several generations, not just the latest. A problem noticed three weeks late is no use if every copy already contains it. When files and database are both needed, take them at about the same time so they match.
Test a restore
An untested backup is a hope. At least twice a year, restore one into a separate place and check:
- The site loads and the main pages look right.
- Images and downloads appear.
- You can log in to the admin area.
- A test form submits and the message arrives.
- A purchase or booking flow works, if you have one.
Never test by restoring over your live site. Use a test copy or a local copy. For WordPress, the project's guidance is to restore the files first, then import the database, and to update the configuration file if the database credentials changed. If you rely on an automatic backup plugin, it also advises making a manual backup now and then to confirm the automation works.
Write down how long the restore took and what went wrong. That note is worth more than the backup in an emergency.
What to record in a handover
Anyone taking over the site, or you on a bad day, needs to find this in one place:
`` BACKUP RECORD - [site] - updated [date] What is covered: files / database / originals / DNS records Automatic backup: tool or host, schedule, where stored, retention Manual copy: who, how often, where kept (off site), encrypted? (y/n) Newest backup date seen: Last restore test (date, result): Restore steps, in order: DNS record export saved at: Who can access each location: Where the logins live (password manager, not in this file): Recovery method for two-step sign-in held by: ``
A fictional example
A fictional florist's site runs on a hosted platform with a plugin that makes a nightly copy. It is stored on the same server. The owner downloads a weekly copy to a business cloud drive, keeps product photos in a folder of originals, and saved a screenshot of the DNS records. In spring she restores a copy to a test address, finds the contact form's sending address was never copied across, and records the fix in the handover. The backup was fine. The restore test found the gap.
Sources
Prepared with AI assistance. Examples are fictional unless stated.