Website backups, restores and uptime: what ‘looked after’ should mean

A website is looked after only if a copy of everything it needs is kept away from where it runs, encrypted, and has been restored at least once to prove it works. Anything less is a hope. Before you trust anyone with your site, ask where the copies live, who holds the keys, when a restore was last tested, what the copy contains, and what you get if the provider stops trading.

This guide is for any business whose website is run by a web designer, an agency or a host, and who has never seen a backup restored. It covers what a backup should hold, where it should be kept, who should hold the keys, how to know a restore works, what happens if your provider disappears, who notices when the site goes down, and the questions to ask, in one list at the end.

What a website backup should include

The National Cyber Security Centre’s advice for small organisations starts from the business, not the technology: make a copy “of all the data that your business needs to operate”, and “this could include your website, emails, invoicing, documents, presentations, contacts and customer information”.

For a website, that means everything it would need to run again somewhere else:

• The code or files. For a site we build, that is a code repository; for a WordPress site, the theme, the plugins and the configuration.
• The database. Posts, pages, products, bookings, and the enquiries your forms have collected. This is the part most often left out, and the part you cannot rebuild by hand.
• Uploaded media. The images, documents and downloads added since the site was built.
• Settings. Redirects, the email the site sends, and anything else that took a day to get right.

Two things are usually kept somewhere else, so ask about them separately. Your business email lives with your email provider, not your website host, and it needs its own backup. And the keys and passwords the site uses should never sit in a backup at all: they belong in a password manager or a secrets store, and a new one is issued when the site is restored.

Where backups should live: off-site, and out of reach

A copy kept on the same server, or in the same account, as the website is lost with it. A server can fail, an account can be closed for an unpaid bill, and ransomware locks what it can reach.

The Information Commissioner’s Office uses exactly this case to explain what the law expects. Its guide to data security describes an organisation that follows “the well-known ‘3-2-1’ backup strategy: three copies, with two stored on different devices and one stored off-site”. Ransomware takes the first two, “However, the third backup, being stored off-site, allows the organisation to restore its systems in a timely manner.”

The NCSC adds a point about reach. A backup drive “should not stay connected to your device when not in use, as some viruses will also affect devices that are connected to an infected computer”. The same idea applies to a hosting company’s backups: if the account that runs your site can also delete its backups, an attacker who takes that account can delete both. The NCSC’s principles for cloud backups ask for backups that are “resilient to destructive actions”, and for a service that allows a customer “to restore from a backup version, even if later versions become corrupted”.

Who holds the keys

A backup should be encrypted, so that a copy that leaks is unreadable. That moves the risk to the encryption key. The NCSC puts it plainly: “an attacker doesn’t need to actually delete the data itself if they can simply delete or modify the encryption key.”

So ask who holds the keys, and where a spare copy of them is kept. The right answer names a small number of people, and a copy held somewhere separate from the systems it protects. “The hosting company handles it” is an answer about someone else’s keys, not yours or your provider’s.

Has a restore ever been tested?

A backup nobody has restored is a hope, not a backup. Backups fail quietly: a job that stopped running months ago, a copy that is missing the database, a file nobody can decrypt. The only way to find out is to restore one.

The NCSC’s advice is that once you have made a backup, “it’s important you know how to restore it, and to check that it contains all your important data”. UK data protection law asks for the same thing where personal data is involved. Article 32 of the UK GDPR lists, among the measures appropriate to the risk, “the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident” and “a process for regularly testing, assessing and evaluating the effectiveness” of the security measures. The ICO’s checklist turns that into a sentence a business can sign: “We make sure that we can restore access to personal data in the event of any incidents, such as by establishing an appropriate backup process.”

Your website’s enquiries are personal data, so this is your concern as well as your provider’s. Ask when a restore was last rehearsed, what was restored, and whether the database came back with the files.

What happens if your provider disappears

Providers close, sell up or stop answering. If your site and its only copies are in their accounts, their problem becomes yours overnight.

Where a provider handles personal data for you, such as the enquiries your forms collect, it is a processor, and Article 28 of the UK GDPR requires a written contract. That contract must commit the provider to take “all measures required pursuant to Article 32”, and, when the service ends, to delete or return all the personal data “at the choice of the controller”, which is you. Read your provider’s data processing agreement for both.

Then ask the practical version: can you have a full copy, the code or files and a database export, on request, in a form another developer could use? A provider who answers yes, and tells you how long it takes, is one you can leave. Our guide to what to check before you sign a maintenance plan covers the rest of what you should keep if you cancel.

Uptime: who notices when the site goes down

A site can be down for hours before anyone who looks after it notices, especially overnight or at a weekend. Uptime monitoring checks the site from outside and raises an alert when it stops answering.

Three questions decide whether monitoring is worth anything. Is the site checked from a different provider, so that an outage at the host cannot also silence the check? Who receives the alert, and is that someone who can act on it? And has an alert ever been tested by making a check fail on purpose? Monitoring nobody has seen fire is, like an untested backup, a hope.

Domain and DNS: the part a backup cannot bring back

Every backup in this guide can rebuild a website. None of them can bring back the domain name if it lapses or sits in someone else’s account, and without the domain, a restored site has no address and your email has nowhere to arrive. The domain is the one thing a backup cannot bring back, so it has to be yours before anything goes wrong.

Our guide to who owns your domain name explains how to check the registrant, the registrar lock and the DNS account, and what to ask a designer who registered it for you. The checks before you sign off a new website put the same keys on the list to collect at launch.

The questions to ask any website provider

Ask these by email, so the answers are in writing:

1. What does a backup contain? The files or code, the database, uploaded media and the settings. If the database is not in it, the enquiries and bookings are not either.
2. Where are the copies kept? Off-site, with a different provider or in a separate account from the one that runs the site.
3. Are they encrypted, and who holds the keys? Named people, with a spare copy of the keys held separately.
4. Can the account that runs the site delete its backups? It should not be able to.
5. When was a restore last rehearsed, and what came back? A date and an answer, including the database.
6. How often, and for how long? Expect a specific answer. A provider may give it under a confidentiality agreement rather than on its website; that is reasonable, and refusing to give it to you at all is not.
7. Can we have a full copy on request? Code or files and a database export, in a form another developer could use.
8. What happens to our data when we leave? It should be in the data processing agreement: returned or deleted, at your choice.
9. Who notices when the site goes down? Monitoring from a second provider, an alert to someone who can act, and an alert that has been tested.
10. Whose name is the domain in? Yours, in your own registrar account.

What we commit to

For the data we hold for clients, our data processing agreement states the commitment, in section 6: the database is backed up regularly, encrypted, and kept off-site, and restoration is rehearsed on a schedule. Every backup is encrypted on the server before it is stored off-site, and only we hold the keys. Sites on our current platform are watched by monitoring from a second provider, and their code lives in version control, so the site itself can be rebuilt from it.

What we do not publish is the operational detail behind those commitments: how often, how long copies are kept, and how a restore is rehearsed. It is useful to an attacker as well as to a client. It is part of the information we make available to clients under section 12 of the data processing agreement, shared under a confidentiality agreement, and we give it to businesses considering us on the same terms. If you leave, the domain goes with you, the code is yours once the build is paid for, and your data is returned or deleted, as the agreement says.

If you are not sure what your current provider keeps, or whether it has ever been restored, our website care service starts by finding out: tell us about your site and we will send a written quote.