To back up a website properly, copy both the files and the database on an automatic schedule, store the copies somewhere other than the web server, keep several dated versions, and test a restore before you need one. A backup that has never been restored is a guess. Static sites kept in version control are already backed up.
Much of our work on WordPress sites is done by script. On one law firm's site a script converted 552 blog posts to a new layout and another placed more than a thousand internal links. Work like that touches hundreds of pages in a minute. You do not run it unless you are certain you can put everything back.
So we think about backups less as insurance against disaster and more as the thing that makes change safe. A site you can restore is a site you can improve without fear.
Having a backup and having one that would work are different things. This post is about the second.
What does a complete website backup include?
A complete website backup includes every file on the server and, for any site with a content system, the database. On WordPress the files are the core software, themes, plugins, and uploaded media. The database holds the posts, pages, settings, and users. Either half alone cannot rebuild the site.
| Part | What it holds | What happens without it |
|---|---|---|
| Database | Posts, pages, menus, settings, user accounts | You have images and a theme, and no content |
| Uploads folder | Every image and document ever added | Pages load with broken images |
| Themes and plugins | Design and features, plus any custom code | The content exists but the site looks and works differently |
| Configuration | Database connection, keys, server rules | The site may not start, or redirects are lost |
People often forget the things around the site. DNS records, the domain registrar login, email settings, and redirect rules are not in a file backup. Write them down somewhere safe. We cover who should hold those keys in who owns your website.
How do you back up a website step by step?
Back up a website by automating a full copy of files and database, sending it off the server, keeping dated versions, and proving you can restore it. The schedule should match how often the site changes: daily for a site that publishes daily, weekly for one that rarely changes.
- List what the site is made of. Files, database, and the outside pieces such as DNS and redirects.
- Pick a tool that captures files and database together. A backup plugin, your host's backup feature, or a script.
- Schedule it. A backup that depends on someone remembering will stop happening.
- Send copies off the server. Cloud storage or another provider, not a folder beside the site.
- Keep several versions. Daily copies for a couple of weeks and a few older ones, so you can go back past a problem you noticed late.
- Protect the backups. They contain your whole database, including user details. Restrict access and do not leave them in a public folder.
- Restore one to a test location. Confirm the site loads, pages display, and you can log in.
- Take a manual backup before every big change. Updates, redesigns, bulk edits.
- Check it monthly. Look at the date and size of the latest copy. A backup that silently failed weeks ago is common.
Step seven is the one that separates a backup from a hope.
Where should website backups be stored?
Website backups should be stored somewhere separate from the web server, ideally with a different provider. If the only copy sits on the same server or the same hosting account as the site, then a server failure, a closed account, or an intruder can take the site and the backup together.
A common mistake is trusting the host's backups alone. They are useful and convenient. They are also under the same account, subject to the same billing problem or the same compromised password. Treat them as the first copy, not the only one.
A sensible arrangement is one copy with the host for quick restores and one copy elsewhere for real trouble. Off-site storage for a small business site is inexpensive.
How do you test a website backup?
Test a website backup by restoring it somewhere other than the live site and checking that it works. Load several pages, confirm images appear, log in to the dashboard, and submit a form. Do this when the backup is first set up and again after any major change to the site or hosting.
A staging copy is the natural place, and it gives you a safe space to try updates too. We explain that setup in staging vs production.
Time the restore while you are at it. Knowing that recovery takes twenty minutes, or four hours, changes how you plan a risky update. It also tells you whether the instructions are clear enough for someone else to follow on a bad day.
Do static sites need backups?
A static site kept in version control is its own backup. The repository holds every file needed to rebuild the site, along with the full history of changes, and copies exist on each developer's machine and on the hosting service. There is no database to capture, because the site does not have one.
This is one of the quieter reasons we like static builds. When we moved a realtor's site off WordPress, the database was retired entirely. For a site built that way, restoring means deploying the repository again, and rolling back a bad change means deploying the previous version.
There are two things to watch. Anything outside the repository still needs its own copy: form submissions, large media kept elsewhere, and settings on the hosting platform. And the repository should live in more than one place. For background, see Git and version control for business owners.
What are the most common backup mistakes?
The most common backup mistakes are backing up only half the site, storing the copy on the same server, keeping only the latest version, and never testing a restore. Each one leaves you with something that looks like a backup until the day it is needed.
- Files without the database, or the reverse.
- One copy, on the same account as the site.
- Only the newest version kept. If a problem went unnoticed for a week, every copy contains it.
- No one knows how to restore. The person who set it up has left.
- Backups nobody has looked at. The job failed quietly months ago.
Frequently asked questions
How often should a website be backed up?
Match the schedule to how often the content changes and how much you can afford to lose. A site that publishes or takes orders daily needs daily backups at least. A brochure site that changes monthly is fine with weekly copies plus one before each update.
Is my hosting company's backup enough?
It is a good first layer and should not be the only one. Host backups live under the same account as the site, so losing access to the account can mean losing both. Keep a second copy with a different provider that you control.
How long should backups be kept?
Long enough to reach back past a problem you were slow to notice. A few weeks of daily copies and several months of monthly ones is a reasonable pattern for most small sites. If your industry has record retention rules, check those with your own adviser.
Can I back up a WordPress site without a plugin?
Yes. Export the database with your host's database tool and download the site's files over SFTP, or use the backup feature in the hosting control panel. A plugin or script is still worth having, because manual backups tend to stop happening.
Do backups slow a website down?
A backup uses server resources while it runs, so schedule it for quiet hours. Outside that window it has no effect on visitors.
If you are not sure your backup would work, get in touch and we will check it and tell you what is missing.