A backup is not a file you keep — it's a restore you've proven you can do. That distinction is where most backup plans quietly fail. The copy exists, the nightly job runs green, and then the day you actually need it you discover the database was never included, the archive is corrupt, or nobody knows how to put it back. You didn't have a backup; you had a folder that looked like one.
So set the goal correctly: the point of backing up a website is to rebuild it — quickly and completely — after anything from a bad plugin update to a full server loss. Everything below serves that outcome: what to capture, how many copies to keep and where, how often, and the step almost everyone skips — testing the restore.
What a complete website backup includes
A website is two things wearing one address: a set of files and, for most modern sites, a database. Back up only one and you cannot restore.
- Files — everything in your document root: the application or CMS code, themes and plugins, and your uploads/media folder. The media folder is the one people underestimate; it holds every image and document you have ever added and is usually the largest, most irreplaceable part.
- Database — for any dynamic site (WordPress, most stores, most apps), the database holds your posts, pages, products, orders, users, and settings. A files-only backup of a database-driven site restores an empty shell.
- The bits people forget — web server and PHP configuration, cron jobs, TLS certificates, redirect rules, and any environment variables or API keys the site needs to run. You may not need all of it in every snapshot, but write down where it lives so a rebuild is not archaeology.
The non-negotiable: capture files and database close together in time. Back up the files at midnight and the database at noon and you can "restore" to a state that never existed — media referenced by rows that are not there, or orders pointing at missing files.
The 3-2-1 rule: the backbone of the strategy
The 3-2-1 rule is the foundation of every serious backup plan, and it is simple: 3 copies of your data, on 2 different types of storage, with 1 copy offsite.
A concrete mapping for a typical site:
- Copy 1 — the live site on your host. This is your working data, not really a backup.
- Copy 2 — an automated backup stored on a different system from the host.
- Copy 3 — an offsite copy somewhere independent: separate cloud storage, a different provider, or a download you keep.
The "offsite and independent" part matters more than it looks. Your host's built-in backup is convenient, but it usually lives in the same account and infrastructure as the site — so if that account is compromised, billing lapses, or the provider has a bad day, the backup can disappear alongside the original. A backup that shares a single point of failure with the thing it protects is not a second copy; it is the same copy twice. Keep at least one copy a problem with your host cannot reach.
How often to back up
Frequency is not about being cautious; it is about a number you can name: how much work are you willing to lose? Recovery-point objective (RPO) is just that question in a suit. Match your backup interval to how fast your site actually changes.
- Rarely-updated brochure site — content changes monthly. A weekly backup, plus one before any change, is plenty.
- Active blog or business site — new content most days. Back up daily.
- Store or app with orders and accounts — losing even an hour means losing real customer data. Back up hourly, or use continuous/database transaction-log backups so you can restore to a point minutes before an incident.
Just as important as frequency is retention — how far back you can reach. Not every problem announces itself: malware, a bad edit, or slow corruption can sit unnoticed for days, so if you only keep last night's copy you will back up the broken site over your last good one. Keep a ladder instead — daily for the last two weeks, weekly for a couple of months, monthly for a year — so you can jump back past a problem you caught late.
Where to store backups
Where a backup lives decides whether it survives the event you are insuring against.
- Offsite and independent — the core of 3-2-1. Object storage, a second cloud, or a dedicated backup service all work; the requirement is that it is reachable when your host is not.
- Encrypt it — a database backup contains user data, password hashes, and sometimes secrets. Encrypt backups at rest so a leaked archive is not a breach on its own.
- Separate the credentials — ideally the keys to your backup storage are not sitting on the web server. If a site compromise can also read and delete your backups, an attacker takes both. Push backups to storage the server can write to but cannot freely browse and wipe.
How to actually create a backup
There is no single right tool, only the right trade-off between effort, control, and independence. The common options:
| Method | Effort | Independence | Restore granularity |
|---|---|---|---|
| Host snapshot / one-click | Very low | Low (tied to host) | Whole site |
| Control-panel backup | Low | Medium | Site or account |
| CMS backup plugin | Low | Medium–High | Files, DB, or both |
| Manual CLI (scripted) | Medium | High | Anything you script |
| Managed backup service | Low | High | Point-in-time |
For full control and true independence, a scripted backup is hard to beat. A manual backup is just two archives — files and database — pushed offsite:
tar -czf site-files-$(date +%F).tar.gz /var/www/example.com
# 2. Dump the database
mysqldump -u DB_USER -p DB_NAME > db-$(date +%F).sql
# 3. Move both copies to independent, offsite storage
# (upload the two files to your object storage / backup bucket)
Then automate it with a scheduled cron job so a real person never has to remember. A backup that depends on human discipline is a backup that stops the first busy week.
Test the restore — the step everyone skips
This is what separates a real backup from a hope, and it is the one almost everyone leaves out: restore your backup on a schedule, before you need it.
Push a recent backup to a staging site, a local environment, or a temporary subdomain and confirm the site comes back to life. Do it quarterly at least. While you are there, time it — your recovery-time objective (RTO), how long a full restore takes, is something you want to learn on a calm Tuesday, not during an outage.
A restore-test checklist:
- [ ] The archive extracts and the database import completes without errors.
- [ ] The homepage and a few inner pages load correctly.
- [ ] Images and uploaded media are present, not broken links.
- [ ] Logins work and an admin can sign in.
- [ ] Forms, checkout, or other dynamic features function.
- [ ] Scheduled tasks (cron) and configuration are in place.
- [ ] You noted how long the whole thing took.
The same complete, portable copy that passes this test is also exactly what lets you move hosts cleanly — see our guide to migrating to a new host without downtime for the cut-over side of that.
Frequently asked questions
How often should I back up my website?
Match the interval to how much work you can afford to lose. A brochure site is fine on weekly backups; an active blog should back up daily; a store handling orders should back up hourly or use continuous, transaction-log backups so it can restore to minutes before an incident.
Is my web host's backup enough on its own?
Usually not, because it typically lives in the same account and infrastructure as your site, so a compromise or provider problem can take the backup with the original. Treat it as a convenient first copy and keep at least one independent, offsite copy as well.
What's the difference between a backup and a snapshot?
A snapshot is a point-in-time image of a server or disk, usually tied to your host and great for quick rollbacks. A backup is an independent copy you can restore elsewhere entirely — and only that independent copy protects you when the host itself is the problem.
How long should I keep old backups?
Keep a ladder rather than a single copy, because some problems go unnoticed for days. A common pattern is daily for about two weeks, weekly for a couple of months, and monthly for a year, so you can restore to a point before a slow-burning issue.
Do I really need to back up the database separately?
For any dynamic site — WordPress, most stores, most apps — yes. The database holds your content, users, and settings while the files hold code and media, so a files-only backup restores an empty shell. Capture both, close together in time.
How do I back up a WordPress site?
Back up the files under your document root (including wp-content, where themes, plugins, and uploads live) and the MySQL database together. A reputable backup plugin can do both on a schedule, or you can script tar plus mysqldump — then store the result offsite and test a restore.
Back up so you can restore
Everything here reduces to one habit: don't collect backups, prove restores. Capture files and database together, keep three copies across two locations with one offsite and encrypted, match your frequency to how much you can afford to lose, and restore-test on a schedule so recovery is boring rather than frightening. Do that and the worst day your site has becomes a short one. If you would rather run this on hosting where dependable backups and recovery are part of the plan, explore what Just-Server offers at just-server.net.
