A backup is a complete copy of your website, files and database together, stored somewhere other than the server it came from. Both halves matter. Files without the database gives you a design with no content. The database without the files gives you content with nowhere to live.
Backups are the least interesting part of running a website and the only part that determines whether a bad day is an inconvenience or a catastrophe. Nobody thinks about them until the exact moment when thinking about them is too late to help.
An untested backup is only a guess
Most businesses discover their backup was broken at the worst possible moment. Backups fail quietly and in predictable ways: the scheduled job stopped running months ago after a plugin update, the database was never included in the job, or the copy sits on the same server that has just failed.
None of that is visible until the day you need it, which is precisely the day you have no time to discover it. A backup that has never been restored is a theory rather than a safeguard, and the number of businesses running on that theory is remarkable.
Retention is the decision most people get wrong
A backup reaching back three days cannot help with a problem introduced a month ago. Slow moving problems are common: a corrupted import, a quietly deleted page, a plugin that has been mangling content since an update, a compromise that sat dormant before being used.
By the time these are noticed, a short retention window has already overwritten every clean copy. Longer retention costs very little in storage and is the difference between recovery and rebuilding.
How we handle backups
- Store copies away from the origin server, so a server failure does not take the backup with it
- Verify restores by actually performing them rather than trusting that a job reported success
- Keep retention long enough to cover slow moving problems, not just yesterday
- Back up files and database together so the two stay consistent with each other
- Document the restore process, since the person who needs it may not be the person who configured it
- Check that backup jobs are still running, because silent failure is the normal way they stop
The documentation point is easy to dismiss and matters enormously during an actual incident. Restores are usually needed under time pressure, sometimes by someone unfamiliar with the setup. Written steps and current credentials turn a stressful hour into a routine task.
What you receive
- Off server backups on a schedule matched to how often your site changes
- Restore testing rather than assumed reliability
- Retention long enough to be genuinely useful
- A documented restore procedure with current access details
- Monitoring so a stopped backup job is noticed within days rather than months
Questions we get asked
My host says they back up. Is that enough?
Sometimes, and it is worth checking rather than assuming. Ask three questions: how far back does it reach, can you restore a single file or only the entire site, and is the copy stored on different infrastructure. Host backups are frequently shorter and less flexible than people expect, and some exclude the database.
How often should backups run?
Match it to how often the site changes. A brochure site updated monthly does not need hourly backups. A site taking orders needs to be able to restore without losing transactions, which is a materially different requirement and usually needs more than a nightly copy.
How long does a restore take?
For a typical small business site, usually under an hour once someone starts. The delay in real incidents is almost never the restore itself. It is working out who has access, which copy to use, and whether anyone has tried this before.
Where should backups be stored?
Somewhere independent of the hosting account, ideally with a copy in a second location. Storing backups on the same server they protect covers you against a bad update and not against a server failure, a hosting account suspension, or a compromise with access to everything.
Do I need backups if my site rarely changes?
Yes, and possibly more urgently. A site that rarely changes is a site nobody is watching, so a problem can sit undetected for a long time. The value of a backup is not proportional to how often you edit the site.
What about the database specifically?
The database holds your pages, posts, settings, and any form entries stored locally. It is the part most likely to be excluded from a poorly configured backup and the part hardest to rebuild from nothing. Always confirm it is included rather than assuming.
We will check whether your current backups would actually work, which is a short job and occasionally an uncomfortable one.
Backups are not a security measure on their own
Backups are frequently described as protection against hacking, which is only half true. They let you recover from a compromise. They do nothing to prevent one, and a backup taken after a site was compromised will faithfully preserve the compromise.
This is why backups and maintenance belong together. Backups without updates means restoring a vulnerable site repeatedly. Updates without backups means no way back when one goes wrong. Either alone leaves a gap that becomes obvious at the worst moment.
Can I keep backups on my own computer?
As an additional copy, certainly, and it is a sensible extra layer. As the only copy it is fragile, since laptops fail and get lost. The practical standard is more than one copy, in more than one place, with at least one somewhere you can reach if the office is unavailable.
What about form submissions and orders?
Those live in the database, so they are covered if the database is included. The gap appears with sites that store enquiries only in email, where a restore does not recover anything sent since the last backup. Worth knowing which category your site falls into before you need to.