Website Backups That Actually Save You When Things Break
Learn what a complete website backup includes, how often to run it, where to store copies and how to test a restore so recovery works when you need it.

Most people think about backups only after something goes wrong: a failed update, a hacked admin account, an accidental deletion, or a hosting problem. At that moment you discover whether your backups are a safety net or just a comforting idea. This guide explains how to build backups that genuinely work, in plain terms.
What can go wrong
It helps to picture the situations you are protecting against, because each one affects which backup you need.
- Human error: you delete a page, overwrite a file or break a setting.
- Bad updates: a plugin, theme or software update conflicts with something and the site stops working.
- Malware or hacking: someone injects malicious code or locks you out.
- Hosting failure: a server fault, a suspended account or a provider problem.
- Account loss: you lose access to the hosting account entirely.
Notice that in the last two cases, a backup stored only on the same server or account is useless. That is why where you keep copies matters as much as making them.
What a complete backup includes
A website is usually made of two parts, and you need both.
- Files: the platform core, themes, plugins, uploaded images and documents, and configuration files.
- Database: the posts, pages, comments, users and settings stored by the platform.
Also keep a note of things that live outside those two parts: DNS records, email settings, SSL details, and any third-party services connected to the site. They are easy to forget and slow to rebuild from memory.
Types of backups
| Type | What it copies | Pros | Cons |
|---|---|---|---|
| Full | Everything, every time | Simple to restore | Uses more space and time |
| Incremental | Only what changed since the last backup | Fast and small | Restoring needs the chain of copies |
| Database only | Just the content database | Quick, good for frequent runs | Does not include uploaded files |
| Snapshot | A point-in-time image of a whole server | Restores everything at once | Often stays with the same provider |
How often should you back up?
Ask a simple question: how much work can I afford to lose? If you publish once a week, a daily backup is plenty. If you run a shop that takes orders all day, you may need the database backed up several times a day. A static brochure site that rarely changes can be backed up weekly or after each edit.
Also take a manual backup right before any risky change, such as updating a major plugin, changing themes or moving to a new host.
The 3-2-1 idea, explained simply
A well-known guideline suggests keeping three copies of your data, on two different kinds of storage, with one copy kept in a different location. For a website, that could look like this:
- The live site itself (copy one).
- A backup stored by your hosting provider (copy two).
- A backup downloaded to a separate cloud storage account or an external drive (copy three, off-site).
If your host has a problem or your account is compromised, the off-site copy is the one that saves you.
Ways to make backups
Your hosting control panel
Many hosts offer automatic or one-click backups. They are convenient, but check how many copies are kept, for how long, and whether you can download them. Do not rely on them alone.
Plugins and tools
If you use a content management system, backup plugins can schedule backups and send them to remote storage. Pick one that supports restoring as well as saving, and keep it updated.
Manual export
You can download your files through FTP or SFTP and export the database with the tools your host provides. It is slower, but it is a reliable fallback and helps you understand what your site is made of.
Protect the backups themselves
- Backups contain user data and configuration secrets, so store them in a private location with a strong password and two-factor authentication.
- Encrypt copies that leave your control when the storage service allows it.
- Never leave a backup archive in a public folder on your own web server, where anyone who guesses the address could download it.
- Decide how many old copies to keep. Too few and you cannot go back past a slow-burning problem; too many and costs and risk grow.
Test your restore
An untested backup is a hope, not a plan. At least a few times a year, and after any change to your setup, try a restore.
- Create a staging area, such as a subdomain or a local copy, rather than touching your live site.
- Upload the files and import the database from a recent backup.
- Update the configuration so it points to the test database.
- Open the site and check that pages, images, logins and forms work.
- Write down the steps and how long it took, so you have a ready recovery guide.
Common mistakes
- Keeping the only backup on the same server as the site.
- Backing up files but forgetting the database, or the reverse.
- Assuming the hosting provider will always have a recent copy ready.
- Setting up automatic backups and never checking that they still run.
- Storing backups next to the site where they can be downloaded by strangers.
Frequently asked questions
Are my host's backups enough?
They are a useful layer, but not a complete plan. Policies vary, copies may be short-lived, and they disappear if the account is closed. Keep at least one copy somewhere you control.
How much storage will backups need?
It depends on your site size and how many copies you retain. Images and uploads usually take most of the space. Incremental backups and a sensible retention period keep it manageable.
Can a backup restore a hacked site?
Restoring a clean copy helps, but you must also close the hole that allowed the attack, such as outdated software or weak passwords, or it can happen again. Change all passwords after a restore.
How long does a restore take?
For a small site it can take minutes, while large sites take longer. Practicing a restore tells you how long to expect.
Conclusion
Good backups are not complicated: copy both files and database, run them as often as your content changes, keep at least one copy away from your hosting account, protect those copies, and test a restore. Spend an hour setting this up now, and the day something breaks becomes an inconvenience instead of a disaster.


