Website Backups That Actually Restore: What to Back Up and How to Test It

Most business owners find out whether their website backup works at the worst possible moment: after the site has been hacked, broken by an update or wiped by a hosting problem. By then a missing database or a corrupted archive is not a technical detail. It is weeks of lost orders and enquiries.

The fix is not complicated. Keep more than one copy, keep one of them somewhere an attacker or a host failure cannot reach, and restore it on purpose before you have to. This guide uses the backup guidance of the US cybersecurity agency CISA, the UK National Cyber Security Centre and the WordPress handbook.

What a website backup must contain

A website is not one thing. The WordPress handbook says a WordPress site consists of the core installation, plugins, themes, images and files, JavaScript, PHP and other code files, and additional files and static pages. It also notes that the database holds every post, comment and link, and that it is stored separately from the WordPress directory, so a file-only backup does not capture it.

In practice, check that your backup includes all of these:

• The database. Content, orders, users and settings. The WordPress handbook says its database export steps do not back up your WordPress files, so file and database backups are two jobs.
• The files. Themes, plugins, custom code and configuration files. The handbook lists wp-config.php and .htaccess among them.
• Uploads and media. Product photos, PDFs and video are usually the biggest part of the site and the part a lazy backup skips.
• Anything outside the site folder. Our recommendation: write down DNS records, SSL arrangements, API keys held by third-party services and scheduled jobs. They sit outside a standard file and database backup, and rebuilding them from memory is slow.
• Email is a separate system. Our recommendation: if your business email runs on the same hosting account, it needs its own backup plan. A website backup does not cover mailboxes.

The same applies to a custom-built site: if the code lives in a repository, that repository is part of the backup, along with the database and any uploaded files.

Host backups are not your backups

Most hosting plans offer some form of backup, and that is useful. It is not a plan. The WordPress handbook says most hosts back up the entire server, including your site, but that it takes time to request a copy of your site from them. Its advice is to learn to back up and restore your own site files.

Check what your own plan actually promises, in writing: what is covered, how often, how long copies are kept, and whether you can download one without opening a ticket. If you cannot get a clear answer, assume you have no usable backup from the host and build your own.

The 3-2-1 rule, and the copy that matters most

CISA calls the 3-2-1 rule a trusted guideline for small businesses:

• 3 copies of important files,
• 2 different types of storage media (CISA's example is a hard drive and the cloud),
• 1 copy stored off-site, away from your business location.

For a website, translate that like this. The live site is copy one. A backup on the same hosting account is copy two, and it is only as safe as that account. The copy that matters is the third: stored somewhere your hosting login cannot reach.

The UK NCSC explains why. It warns that ransomware actively targets backups to increase the likelihood of payment, and advises offline backups kept separate, in a different location and ideally off-site, from your network and systems. If someone takes over your hosting account, they can delete everything inside it, including the backups stored there. A copy in a separate account, with a separate password and its own two-factor login, survives that.

The NCSC adds two protections worth asking for. One is to ensure that previous versions of files are protected from accidental or malicious deletion. The other, from its ransomware-resistant backup principles, is to use credentials for the backup system that are separate from those used to administer everything else, and to block deletion or alteration requests on a backup. Write-once storage is one way to do that. Most small business sites will meet this with a cloud storage account configured to keep older versions, plus separate credentials.

How often: match the backup to how fast your content changes

The WordPress handbook gives a starting point for WordPress sites: weekly for smaller sites with fewer posts, daily for high-activity sites with a lot of posts. It also advises backing up the database at regular intervals and always before an upgrade.

Our recommendation for working out your own schedule: ask how much you could afford to lose. A brochure site that changes twice a year can tolerate a weekly backup. A store that takes orders all day cannot lose a day of them. Run the database backup as often as orders or form entries arrive, and the file backup less often. Whatever the interval, take a manual backup immediately before any plugin, theme or PHP update. Updates are the moment a site is most likely to need a rollback. Server-level patching matters too, as in our guide to the critical PHP vulnerability website owners must act on.

CISA's small business guidance adds that you should choose a backup solution that runs automatically and regularly. A backup that depends on someone remembering will stop the first busy week.

How long to keep them

One rolling copy is a trap. If the site was infected last Tuesday and your only backup was taken last night, you have saved the infection. The NCSC says to retain backups for a period of time rather than have a single rolling backup, and to consider how long it may be before something is detected and keep backups for longer, at least a month. CISA's guidance asks for the ability to roll data back at least seven days.

The WordPress handbook suggests keeping at least 3 to 5 recent backups, in different places. Between the three sources, a sensible small-business floor is several recent copies and at least a month of history, with older versions that cannot be quietly deleted from the same account.

How to test a restore

The NCSC puts it plainly: test your backups regularly and ensure you know how to restore files from a backup before you have to do it for real. CISA asks for backup procedures that let your team restore data both fully and partially, and rapidly. The WordPress handbook says to back up your automatic backups with a manual backup once in a while to confirm the process works.

None of these sources gives a step-by-step test for a website, so the following is our practice, not theirs.

1. Restore somewhere safe. Never restore over the live site as a test. Use a staging copy or a separate hosting space, on a hostname that is kept out of search.
2. Restore everything: files and database, from the off-hosting copy, not the convenient one on the server.
3. Check the site works, not just that it loads: log in to the admin, open a product page and a form, search the site, confirm recent uploads show their images and that the latest content is there.
4. Do a partial restore. Recover a single page, a media file or one table. You will rarely need the whole site back at once, so prove you can recover one piece.
5. Time it. How long did it take from start to a working site? That is your real recovery time, and the number to compare against what your business can tolerate.
6. Scan the restored files. The NCSC says to ensure files are scanned with up-to-date antivirus software when they are restored, since malware may persist in backups.
7. Write down what you did, including where the credentials live. The person who needs this document may not be you.

How often? Neither CISA nor the NCSC sets an interval for website restores. Our practice: a full test after setting up or changing the backup system, and then on a regular schedule, with a calendar entry that someone owns. Quarterly is a reasonable starting point for a business site.

Who owns it

This part is organisational, and it is where backups quietly fail. Our recommendation is that three questions have named answers, in writing:

• Who checks that backups ran? Failure alerts are useless if they go to a mailbox nobody reads.
• Who holds the credentials to the off-hosting copy? If the only person with access leaves, the backup is unreachable.
• Who performs and signs off the test restore, and when is the next one?

If your site is built and maintained by an agency, ask them these questions directly, and ask to see the last restore test. Our website security guide for UAE businesses covers the rest of the checklist: accounts, two-factor login, updates and monitoring.

A short checklist

• Database, files, uploads and configuration are all in the backup.
• At least one copy sits outside the hosting account, with separate credentials.
• Older versions are kept, at least a month of history, and cannot be deleted by a single compromised login.
• Backups run automatically, plus a manual one before every update.
• A full restore has been tested, timed and documented, and the next test is scheduled.
• A named person owns each of the above.

If your site runs on WordPress and nobody can say when the last test restore was, that is the gap to close first. Our WordPress service covers the build and care of WordPress sites, and if you are weighing whether to stay on the platform, our comparison of WordPress and a custom website covers the maintenance side honestly. Tell us what you are running and we will tell you where your backups stand.

Guidance is as published by CISA, the UK NCSC and the WordPress.org handbook on or before 13 November 2026. The NCSC advice is written for UK organisations but applies to any business. Check the sources for later updates.