A website backup is a copy you can restore from when something breaks. It helps only if it is complete, recent, stored elsewhere and tested.
A website backup should include the site's files, its database, its settings and the records needed to rebuild it, such as domain and login details. How often to back up depends on how often the site changes, so stores and busy sites need more frequent copies. Keep copies away from the server that holds the site, and test a restore, because an untested backup may fail.
What is a website backup?
A website backup is a saved copy of everything needed to bring your site back as it was. You need one when a hack, a failed update, an accidental deletion, a server fault or a bad edit damages the live site. A recent backup turns a crisis into an afternoon of work. Without one, you rebuild from memory and whatever scraps you can find.
A backup is not the same as hosting that happens to be reliable. Servers fail, accounts get locked and people delete the wrong thing. It also differs from the undo history in an editor, which covers one page and disappears with the site.
The rest of this guide answers three practical questions: what to include, how often to do it, and where to keep the copies. It ends with how to prove that the backup works.
What a website backup should include
A site is more than the pages visitors see. The table lists the parts that normally need saving.
| Part | What it contains | Why it matters |
|---|---|---|
| Site files | Theme or templates, code, plugins or extensions, scripts | The site cannot run without them |
| Uploaded media | Images, documents and videos added through the site | Often the biggest part, and not in the code |
| Database | Pages and posts, product and order records, user accounts, form entries and settings | It holds the content that makes the site yours |
| Configuration | Server settings, redirect rules, configuration files, scheduled tasks | A restored site can behave differently without them |
| Domain and DNS records | The settings that point your domain to the host, and your email records | They are kept at the registrar or DNS provider, so write them down |
| Account and access records | Which logins exist, who holds them and when the domain and certificate renew | A new host or developer cannot start without them |
Not every site has a database. A site built from plain files has none, which makes it simpler to save. On a typical WordPress site, the content sits in the database while themes, plugins and uploads sit in files, and WordPress's own documentation says you need both to restore it fully.
Files, database or both?
Both, on any site that uses a database. Saving only the files is the most common mistake. You can restore the design and the images, and still find the pages, products and orders gone. Saving only the database fails the other way: the content returns, but the theme, plugins and uploads it refers to are missing.
Make the two parts at about the same time so they match. A database from Monday paired with uploads from the previous Friday may point to files that do not exist yet, or miss files added since.
Third-party services hold their own data and sit outside the backup. Newsletter lists, form tools, booking systems and payment accounts keep records on their side. Export what you could not recreate, and check what each provider keeps for you.
How often should you back up your website?
Back up as often as you can afford to lose work. Ask how much new content or how many orders you could lose and re-enter by hand. The answer sets the rhythm.
| Type of site | How it changes | Sensible rhythm |
|---|---|---|
| Brochure site that rarely changes | A few edits a year | A copy after every change, plus a regular scheduled one |
| Blog or news site | New posts and comments | Daily, or after each batch of posts |
| Online store | Orders and stock change all the time | Frequent automatic copies of the database, with files saved whenever they change |
| Booking or membership site | New records throughout the day | Frequent automatic copies of the database |
Whatever the schedule, make an extra copy before any change that could break the site: a software update, a new plugin, a redesign launch, a change of host or a change to server settings. WordPress's documentation gives the same advice for updates.
Also keep older copies. A problem such as a hack or a slow database fault can go unnoticed for a while, and a single copy that overwrites itself each night will save the damage along with everything else. Keep enough older copies to reach back past the time a problem could hide.
Where to store website backups
Store at least one copy away from the server that holds the site. A copy kept only on that server is lost in the same failure or break-in. The National Cyber Security Centre in the UK advises keeping backups separate from your main systems and offsite, partly because attackers go after backups, and says the device holding a backup should not stay permanently connected to the original.
Common places, with their limits:
- The host's own backup service. It is convenient and often automatic, but it sits within the same provider and account as the site, so it may not survive a lockout or a provider failure.
- A cloud storage account that is separate from the hosting login, so one stolen password does not expose both.
- A download to a computer or external drive, kept apart from the live site. This is a good offline copy, as long as someone remembers to refresh it.
Protect the copies as carefully as the site. A backup contains customer records, settings and sometimes credentials. Limit who can open it, use strong logins with two-step verification, and encrypt copies where the tool allows. Privacy rules on keeping and deleting personal data differ by country, so ask a lawyer how long customer data in old backups may be held.
Who should look after your backups?
Somebody must be named, and it is rarely you by default. The host, a tool inside the content management system, the developer under an agreed arrangement, or the platform itself may do it. A hosted builder or store platform holds the site for you, so check what export and backup options it offers in its current documentation, and keep your own copies of text, images and product data.
Whoever does the work, ask these questions in writing:
- What is backed up: files, database, or both?
- How often, and how long are copies kept?
- Where are they stored, and is that place separate from the site's server?
- Can I download a copy myself?
- Who restores the site, how is a restore requested, and does it cost extra?
- When was a restore last tested?
Settle this at handover, not after a failure. The guide to who does what in a website project shows where the launch and care stages sit, and the guide to writing a website brief is the place to put your expectations about backups in writing.
How to test a restore
A backup nobody has tried to restore is a hope, not a plan. Test with a copy and never on the live site.
- Choose a recent backup and restore it to a separate test location, which your host or developer can set up.
- Open the home page and several inner pages. Check images, menus and forms.
- Try the functions that earn money or collect leads: search, login, booking and checkout.
- Compare the restored content with the live site, and note anything missing.
- Write down how long it took and what steps were needed, so the next restore is faster.
- Fix the gaps, such as uploads that were not included, and test again.
The National Cyber Security Centre also advises testing backups regularly, so that you know how to restore before you must do it for real. Repeat the test after major changes to the site or the hosting.
If you ever restore after a hack, deal with the cause first. Change passwords, update software and remove unknown users. Otherwise the same weakness comes back with the restored copy. The NCSC also advises scanning backups for malware before restoring from them.
Backups for different kinds of site
| Kind of site | What to watch |
|---|---|
| Simple site built from files | No database to save. Keep the source files and the hosting settings. The guide to single-page and multi-page websites explains how site size affects the work. |
| Site on a content management system | Files and database, saved together, plus any custom settings. |
| Online store | Restoring an older backup can erase orders placed since it was taken. Keep order records in the payment or order system too, and back up the database often. |
| Hosted builder or store platform | The platform holds the site. Find out what you can export and keep your own copies of the content. |
| Custom web application | Code, database, server configuration and environment settings. Secrets must be stored securely and not in plain backups. |
It also helps to know what a failure costs in time. Restoring a backup takes a fraction of the time that a rebuild does. A rebuild repeats work that took weeks or months the first time, which the guide to how long it takes to build a website breaks down by stage.
Common website backup mistakes
- Saving the files and forgetting the database, so the restored site has a design but no content.
- Keeping every copy on the same server as the site.
- Never testing a restore, then finding out during a crisis that the copies are incomplete.
- Relying on one rolling copy that overwrites itself, so a problem noticed late has already been saved over the good version.
- Forgetting the domain and DNS records, which sit outside the site and cannot be recovered from its files.
- Assuming the host or platform covers everything without checking what is included, for how long, and who can restore.
- Leaving backups unprotected, so a stolen copy exposes customer data.
- Having no named person responsible, so nobody notices when scheduled copies stop running.
The website development service page describes the work Liftup does.
Questions and answers
What should a website backup include?
A website backup should include the site files, uploaded media, the database if there is one, and the configuration such as redirect rules. Also keep a record of your domain and DNS settings, logins and renewal dates, because they sit outside the site and are needed to rebuild it.
How often should I back up my site?
Back up as often as you can afford to lose work. A site that rarely changes needs a copy after each change plus a scheduled one, while a store or booking site needs frequent automatic copies of the database. Always make an extra copy before updates or a redesign.
Where should I store backups?
Keep at least one copy away from the server that holds the site, such as in a separate cloud storage account or on a drive that is not permanently connected. Protect copies with strong logins and two-step verification, because they contain customer data.
Does my host back up my website for me?
Many hosts do, but what is covered varies. Ask in writing what is included, how long copies are kept, where they are stored and how a restore is requested. Do not rely on the host's copy alone.
How do I test a website backup?
Restore a recent backup to a separate test location, not the live site. Check the home page, inner pages, images, forms and key functions such as login or checkout. Note how long it took and fix anything missing.
Do I need a backup if I use a website builder?
The platform holds your site, but you should still check what export and backup options it offers in its current documentation. Keep your own copies of text, images and product data so you are not tied to one provider.
How long should I keep old backups?
Keep several older copies, not just the latest. A hack or fault can go unnoticed for a while, and a single copy that overwrites itself may contain the damage. Keep enough history to reach back past the time a problem could stay hidden.