Backups

Website backups you can actually restore.

Two things catch people out, and both look identical to a working backup until the day you need one: a schedule that quietly stopped months ago, and an archive that does not restore.

Off-site Job verified Restores tested
The problem

Almost everyone has backups. Fewer have restores.

Backups are the easiest thing in hosting to appear to do. A schedule is configured once, everybody relaxes, and nobody looks again. The failure modes are silent by nature: a plugin that stopped running after an update, a storage account that filled, a credential that expired. Nothing announces any of it.

The second failure is worse because it only appears at the moment of maximum stress. An archive exists, it is the right size, and it does not restore — a truncated database dump, a missing uploads directory, a file somebody will have to explain.

So the useful question is not whether you have backups. It is when somebody last confirmed the job ran, and when anybody last restored one.

Able Web Services Ltd.UK web development
200+PROJECTS DELIVERED
140+CLIENTS SUPPORTED
15+YEARS ESTABLISHED
UKBASED & HOSTED

What we do

  • Bespoke websites and custom CMS development
  • Ecommerce, custom checkout and subscriptions
  • Web applications, portals and internal tools
  • API, CRM and business systems integration
  • Retained support, maintenance and managed hosting
  • White-label development for agencies

Working UK-wide and internationally — directly with businesses, and white label behind design and marketing agencies.

Discuss a project
How ours work

What the service actually does.

Held away from the server

Off-site, so losing the machine does not lose the backups with it. A backup on the same server protects you from mistakes, not from losing the account.

The job is verified

The platform checks a backup job exists and that it ran, and reports when it did not. A schedule that silently stops is the commonest failure there is.

Restores are exercised

We restore from real archives rather than assuming they work. A backup nobody has restored is an assumption.

14-day retention as standard

Daily, kept for fourteen days. Longer retention is available by arrangement where you need it.

Database and files together

Both, consistent with each other. A database from Tuesday and files from Thursday is not a restore point.

A way back from an update

Taken before scheduled changes, so a bad update is reversed rather than debugged live.

Straight answers

Being straight about it.

Retention is a real limit

Fourteen days is fourteen days. If something goes wrong and nobody notices for a month, the clean copy has rolled off. Tell us if you need longer.

Backups are not version control

They let you go back to a point in time. They do not tell you what changed or why, which is a different tool for a different problem.

Restoring costs time

A restore is not instant, particularly on a large site. Knowing roughly how long yours takes is worth establishing before you need the answer.

Related services

The wider picture.

Related work

Projects of a similar shape.

A lot of our work is delivered white label or under agreement, so these describe the problem and the approach rather than naming the client.

Related

Also worth reading.

Questions

What people ask about backups.

Our host says backups are included. Is that enough?
Possibly, and it is worth asking three specific questions: are they held off the same server, how long are they kept, and has anybody restored one. Many included backups fail at least one of those, and you find out at the worst moment.
How often are backups taken?
Daily as standard, with more frequent database copies available for busier sites where a day of lost orders would matter.
Can we get a copy of our own backups?
Yes. It is your site and your data. We would rather you had your own copy than felt locked in by not having one.
What happens if a restore fails?
That is exactly why restores get exercised rather than assumed. If an archive turns out not to restore cleanly we would rather discover it during a test than during an incident, and fix the cause.
Next step

When did anybody last restore one of your backups?

If the answer is never, that is worth knowing now rather than later. Send us the site and we will tell you what the backup position actually is.