Menu

Backup

Copies taken on a schedule, kept somewhere else.

A backup is the copy nobody has to remember to make. It runs on a schedule, keeps a history rather than only the latest state, and lives somewhere other than the machine it is protecting — because a copy on the server is not a copy at all.

On a schedule
nobody has to remember
History kept
not just last night
Held off the server
separate from what it protects
Restore tested
a copy nobody has restored is a rumour

What it is

Most data is not lost to a failed disk. It is lost to a command typed against the wrong database, a plugin update that corrupted a table, or a deletion nobody noticed for three weeks. Against all of those, the only thing that helps is history — the ability to go back to a Tuesday, not just to last night.

That is what a scheduled backup is for, and it is why it has to be kept away from the server. A copy that lives on the machine it protects shares that machine's fate, and a copy nobody has ever restored is a belief rather than a backup.

What it does for you

Six things Backup changes about how your infrastructure behaves.

It runs whether anybody remembers or not

A schedule, not a habit. The backup nobody took is the one you needed.

Enough history to be useful

Retention across days and weeks, so a mistake discovered late is still recoverable rather than already backed up over.

Kept away from the server

Stored separately from the machine it protects, so losing the machine does not lose the copies as well.

A whole server or a single file

Rebuild the machine after a disaster, or pull back the one table somebody dropped on a Thursday.

Restores that have been tried

We will run a restore with you so you have seen it work, rather than finding out on the day it matters.

It covers the volumes too

Data on attached storage is included — the place most data lives once an application has been running a while.

How this differs from a snapshot
A snapshot is one manual image of one machine, taken before a change and usually thrown away after. A backup is automatic, keeps history, and is stored elsewhere. Snapshots protect a change; backups protect against time — against the mistake you have not noticed yet.
What a backup does not do
It does not keep your site up. Restoring takes time proportional to how much there is, so a backup is what limits how much you lose, not how long you are down. If being down is the thing you cannot afford, that is a load balancer and a second server, and backups underneath both.

What it costs

Backups are priced by how much is stored and how long you keep it, which depends on your data and your retention. Tell us the size and the history you need and we will quote it.

We would rather quote you than publish a number we have not checked. Everything on the pricing page is a figure the order form actually charges — this will join it the day the same is true here.

Questions

How often should they run?

The honest question is how much work you are willing to redo. Nightly means up to a day; hourly means up to an hour and costs more. Pick the interval from the answer, not from a default.

How long should I keep them?

Long enough to cover how late you might notice. Two weeks catches most mistakes; a monthly copy kept for a year covers the rest and costs very little.

Can I restore just one file?

Yes. A full-server restore is for a disaster; day to day, most restores are one database or one directory.

Do I still need snapshots?

Yes, for a different job. Take a snapshot before a change you are about to make; keep backups running for everything you are not expecting.

Something not answered here? Ask us — it is a short answer or it is a phone call, and either is fine.

Not sure whether you need this?

Tell us what you are running and what is going wrong with it. We will say which of these actually helps — including when the answer is none of them.