Websites and Tech

Backup

Also called site backup, restore point

A restorable copy of a site's files and database, held where a server failure or suspension cannot reach it.

Quick facts: Backup

Category
Websites and Tech
Also called
site backup, restore point
Level
Beginner
Affects
Recovery time, update confidence, data loss risk
Where to see it
Hosting backup tools, UpdraftPlus, your control panel, off-site storage
In this article4
  1. How a backup works
  2. Why backups matter
  3. Common mistakes with backups
  4. How to act on it

How a backup works

A complete backup captures two separate things. The files — theme, plugins, uploaded images and documents — sit on the server’s disk. The content — posts, pages, settings, users, orders and form submissions — sits in the database. Copy one without the other and a restore gives you either an empty design or content with nothing to display it.

Backups usually run on a schedule and are kept for a set number of days before older ones are discarded. That retention window is the real question: if a problem takes a week to notice, a copy kept only overnight is already gone. Some tools take a full copy each time; others record only what changed since the last one, which is faster but means the chain has to be intact to restore.

Why backups matter

Sites are lost in ordinary ways, not dramatic ones: a plugin update that breaks the checkout, a compromised login, an accidental deletion, a hosting account suspended over an unpaid invoice. In each case the backup is the difference between an inconvenient afternoon and rebuilding a business asset from memory.

It also changes what you dare to do. Teams without a reliable backup postpone updates, avoid experiments and let the site age, which creates the very fragility they were afraid of. A restore you trust makes routine maintenance a normal task instead of a gamble.

Common mistakes with backups

The one that catches people is never testing a restore. A backup job that reports success every night can still produce an archive that will not restore, and you find out on the day it matters. Restoring to a staging copy once a quarter is what turns a hope into a safeguard.

The second is storing the only copy on the same server as the site. If the account is suspended, the disk fails or the server is compromised, the backups go with it. Keep at least one copy somewhere else entirely.

The third is a retention window shorter than your detection time, and the fourth is forgetting that backups contain customer data. An archive of your database holds every enquiry and order, so it deserves the same access control as the live site.

How to act on it

Confirm four things about your current arrangement, in this order: that files and database are both included, that copies are stored off the server, that the retention window is longer than the time you would realistically take to notice a problem, and that somebody has successfully restored one.

Take an extra manual copy before any risky change — a platform upgrade, a plugin replacement, a site migration — rather than relying on last night’s scheduled run. And know who can perform a restore and how long it takes, because that number is your real recovery time, whatever the backup tool promises.

Do and do not

Do

  • Include both files and database in every copy
  • Keep at least one copy off the server
  • Restore a backup to staging once a quarter

Do not

  • Trust a backup nobody has ever restored
  • Keep a retention window shorter than your detection time
  • Leave archives of customer data loosely accessible

Questions people ask about this

How often should my website be backed up?

Match the schedule to how much work you could stand to lose. A brochure site that changes monthly is fine with weekly copies. A shop taking orders needs at least daily, because every missing hour is missing orders. The other half of the answer is retention: keep enough history to reach back past a problem you noticed late.

Is my host's backup enough?

Sometimes, but check three things rather than assuming. Does it include the database as well as files, is a copy held outside your own server, and can you trigger a restore yourself or must you wait for support? Many included backups are intended for the host's disaster recovery, not for your convenience.

How do I know my backups actually work?

Restore one. A successful backup job proves a file was written, not that the file is usable. Restore a recent copy onto a staging site, then check that pages load, images appear, and recent orders or enquiries are present. Doing that once a quarter is what turns backups into genuine protection.

Related terms

Found this useful?

Share it, or ask an AI to summarise it

Back to the glossary

Knowing the term is the easy part

Applying it to your own site and budget is the work. Book a call and I will tell you what actually applies to you.