A backup is useful only if you can turn it back into a working website. A dashboard saying “backup complete” is a good start, but it does not tell you whether important files were excluded, whether the copy is recent enough or whether you can access it during an outage.

A practical backup plan answers four questions: what must be recovered, how much recent work could be lost, where the copies live and who will restore them. This guide helps a small website owner put those answers in writing.

1. Know what makes up your website

For a typical self-hosted WordPress website, a complete recovery needs both the database and the files. The database holds content and settings; files include uploads, themes, plugins and configuration. WordPress's own documentation explains why both parts matter. A content export alone should not be assumed to rebuild the whole installation. [1]

Other platforms work differently. Ask your provider what its export or backup includes. Make an inventory of the database, uploaded media, application files and configuration you would need. Note any separate email service, booking system or payment integration. These may require their own recovery arrangements.

Do not save backups in a publicly accessible website folder. They may contain customer details, password hashes or configuration secrets. Protect them with restricted access and encryption where supported, and keep recovery keys available through a separate secure process.

2. Choose a schedule based on acceptable loss

Ask: “If I restored yesterday's copy, what would be missing?” A portfolio updated monthly is different from a shop receiving orders all day.

A daily backup can leave almost a day's changes missing if failure happens just before the next run. If you cannot afford that loss, discuss more frequent backups or database recovery options with your provider. Also decide how long the business can tolerate being offline. Recovering the data and recovering quickly are separate goals.

For example, a weekly-updated brochure site might start with automated daily backups and an extra copy before each significant change. This is an illustrative starting point, not a rule for every business. A busy store needs a plan based on its order volume and tested recovery capability.

3. Keep copies that do not all fail together

The 3-2-1 approach means keeping three copies of important data, on two different media or devices, with one copy offsite. The live data counts as one copy. NCSC guidance also explains that this arrangement does not automatically give you an offline backup. [2]

A backup in the same hosting account may disappear with that account or be affected by the same compromise. Keep a separate copy outside the live hosting environment. Consider an offline copy, or properly configured immutable storage that prevents alteration or deletion for an agreed period. Check who can delete the copies and whether the same compromised login would expose them all.

Use multi-factor authentication on the backup account where available. NCSC's small-organisation guidance recommends protecting online backups with two-step verification and checking that you know how to restore the data. [3]

4. Keep useful history

The newest copy is not always the right copy. You might discover an accidental deletion several days later, after the unwanted change has entered recent backups.

Agree a retention period that fits how quickly problems are likely to be noticed. For a small brochure site, keeping a month of daily versions could be a starting point to discuss with the provider. Check storage costs and any limits. Adjust the plan for the information you hold rather than keeping every copy forever.

Record the date of major updates so you can identify a suitable restore point. Keep the database and files from a matching backup set together.

5. Test a restore safely

Use a private test environment rather than overwriting the live site just to find out whether a backup works. Follow your platform's restore procedure or ask the host to demonstrate it.

Before starting, stop the test copy from sending real emails, charging payments or running scheduled jobs against live services. Protect access to copied customer information.

Then check these outcomes:

  • The homepage and important internal pages load.
  • Recent content, images and downloads are present.
  • The administration area opens.
  • Expected settings and record counts look right.
  • Forms and integrations can be tested safely.
  • Someone can repeat the process using the written instructions.

Record the backup date, what you restored, problems found and the time required. For a small site, a monthly reminder can be a useful starting point; choose a frequency that reflects the cost of failure and repeat the test after major platform changes.

6. Make failures visible

Send backup failure alerts to an inbox someone checks. Review storage capacity and retention settings. A silently failing job can leave you relying on an old copy for weeks.

Write a short recovery sheet with the responsible person, provider support details, backup location and restore instructions. Keep it somewhere accessible if the website is unavailable. Store passwords in a password manager, not in the sheet.

If the website breaks today

Avoid rushing to overwrite everything. Record what happened and preserve a copy of the current state where practical. Choose a known-good restore point and identify what newer data would be lost.

For a shop, restoring an older database may remove orders already paid for. Reconcile orders, bookings and other changes before reopening. If an attack is suspected, involve the host or a qualified specialist: restoring a backup alone may leave the original vulnerability or stolen credentials in place.

Frequently asked questions

Are my host's backups enough?
They may be useful, but confirm the included data, frequency, retention, restore fees and access during an account problem. Keep a separate copy when the consequences of losing access justify it.

Is synchronising files the same as backing them up?
Not necessarily. A synchronised deletion can reach every connected copy. Check version history and recovery behaviour instead of assuming that another folder is a protected backup.

What is the most valuable first step?
Restore one recent backup into a safe test environment. It turns an assumption about recovery into evidence and shows what the instructions are missing.

Sources and further reading

[1] WordPress — Backups: https://developer.wordpress.org/advanced-administration/security/backup/

[2] NCSC — Offline backups in an online world: https://www.ncsc.gov.uk/blog-post/offline-backups-in-an-online-world

[3] NCSC — Backing up your data: https://www.ncsc.gov.uk/collection/small-organisations-guide-to-cyber-security/backing-up-your-data

Additional recovery planning: https://www.ncsc.gov.uk/collection/disruptive-cyber-attacks/preparing/3-prepare-technical-recovery

Guidance checked: 9 November 2026. Example schedules are starting points to adapt to your business, not guarantees of recovery.