A proper website backup is a recoverable copy of everything needed to restore the site after loss, corruption, a bad update or account problem. What needs backing up depends on the architecture: a WordPress site usually needs both files and database; a static site may be reproducible from its source files and deployment configuration.
The word backup sounds reassuring.
It is only useful if you can restore from it.
A folder named website-backup-final-final2.zip on the same server as the live website is not a strong recovery plan.
The first question is not:
Do I have a backup?
It is:
If the live system disappeared, what would I need to recreate it?
WordPress needs more than the visible files
A typical WordPress website stores important information in more than one place.
The database contains content and settings.
The file system contains WordPress files, themes, plugins and uploads.
A complete recovery plan therefore needs to account for both.
WordPress's own security guidance recommends regular backups and specifically warns about having a solid database backup plan before certain updates.
That is sensible.
If an update fails badly, the backup gives you a known point to return to.
A database backup is not the whole WordPress site
Likewise, backing up only the database may not capture uploaded images, custom theme files or other assets.
The exact recovery requirement depends on how the site is built.
Managed WordPress hosts often provide backup features.
Plugins can also provide backup workflows.
Those can be useful.
Just understand what the backup contains and where it is stored.
Static websites have a different recovery model
A static site may be much easier to reproduce.
If the authoritative source files are safely stored and versioned, the live deployment can potentially be rebuilt from that source.
There may be no live CMS database to recover for the ordinary pages.
That is one of the operational advantages of static architecture.
But there can still be things outside the site source.
Forms.
External data.
Images.
DNS configuration.
Environment variables.
Third-party accounts.
Those need their own continuity plan.
Version control is not exactly the same as a traditional backup
Version control is excellent for website source because it records changes and gives the developer previous versions to return to.
But it does not automatically contain every external service or data source.
If a form submission lives in another service, the source repository does not contain those submissions.
If a CMS stores content elsewhere, that content needs separate consideration.
The recovery model should match the real system.
Deployment history is useful, but not enough on its own
Platforms can keep previous deployments.
Cloudflare Pages, for example, currently supports rolling a production project back to a previous successful deployment.
That is extremely useful when a new release causes a problem.
But if the entire account becomes inaccessible, platform history may become inaccessible too.
A rollback feature and a backup are related.
They are not identical.
Gavin's take
I care less about being told a site is "backed up daily" than knowing somebody can actually restore it. Ten automated copies inside the same account are not necessarily stronger than one well-understood independent recovery copy. The right setup should be proportional to the business, but a backup only earns the name if it gives you a realistic route back after a failure.
Keep backups away from the failure they protect against
If the only backup is stored inside the same compromised hosting account, you may lose both.
A stronger plan separates recovery copies from the live system where practical.
The exact setup depends on the size and importance of the site.
A five-page brochure website does not need an enterprise disaster-recovery programme.
It does need enough independence that one failed account does not destroy the only copy.
How often should backups run?
It depends on how often the data changes.
A brochure site updated twice a year has a different risk profile from a busy e-commerce store receiving orders every minute.
For dynamic sites, backup frequency should reflect how much data the business could tolerate losing.
If losing one day's orders would be unacceptable, a once-a-month backup is obviously not enough.
For static source, every meaningful change should normally become part of the stored/versioned source anyway.
Again, architecture determines the answer.
Back up before risky changes
This is one of the simplest useful habits.
Major CMS update.
Plugin changes.
Theme work.
Migration.
Database work.
Infrastructure change.
Take or verify a recovery point first.
WordPress's own plugin documentation recommends having a current backup before updating plugins because update problems can happen.
That is not alarmism.
It is ordinary change management.
What I'd do
Before a risky migration or major change, I would make the recovery point explicit: where is the current source, where is the database or content export if one exists, and what would I use to restore the site? For a small static site that may be very straightforward. For WordPress it may involve files and a database. The important part is knowing the answer before the live site is the thing being repaired.
Test restoration
This is the part people skip.
A backup can exist and still be unusable.
Corrupt archive.
Missing database.
Unknown password.
Incomplete files.
Wrong version.
No documentation.
You do not need to perform a full disaster drill every week.
But for an important website, someone should know that the backup process can actually produce a working recovery.
Otherwise the first restore test may happen during the emergency.
Backups do not protect domain ownership
This is another important distinction.
You can have a perfect copy of the website and still have a serious problem if you lose the domain.
The site can be rebuilt on another URL, but the public address and domain-based email may still be inaccessible.
Backups protect website data.
Domain control protects the address.
Both matter.
What about third-party services?
The website may only be the front door.
Bookings might live elsewhere.
Payments elsewhere.
CRM elsewhere.
Newsletter subscribers elsewhere.
Analytics elsewhere.
Those systems have their own data and retention policies.
A website backup does not necessarily cover them.
If the service contains business-critical information, understand how that service protects or exports it.
Backups make changing developers easier
A clean handover is safer when the current state of the site is recoverable.
Before a migration, create a known good backup.
Then the new developer can make changes without the old system becoming the only copy.
This is one of the steps I would expect during a move to another web designer.
Gavin’s perspective
Built by Gavin's approach
I prefer websites whose recovery story is understandable.
For a static site, that means the source should not exist only on one laptop or only inside one deployment account.
For a more dynamic site, the important data needs an appropriate backup process.
The client does not need to manage all of this personally.
They should be able to ask:
If this broke tomorrow, how do we recover?
and receive a concrete answer.
The bottom line
A website backup is useful only if it contains what you actually need and can be restored.
WordPress generally needs files plus database recovery.
Static sites can often be rebuilt from safely stored source.
Third-party data may need separate protection.
Keep recovery copies independent enough to survive the failure they are meant to protect against.
And test the process before you need it.
Not sure whether your current website is actually backed up?
Send me the site and tell me what platform it uses.
I can help you identify what should exist before anybody starts changing or moving it.
---