How often should I test a restore?

Monthly for anything the business depends on, and immediately after any change to what is being backed up. The test is not "did the archive extract"; it is "did a working system come back, and how long did it take". Write down the elapsed time; that number is your actual recovery time, and it is usually several times longer than people assume.

Is my hosting provider already backing this up?

Usually they snapshot the whole VM on a schedule, which is useful but not the same thing. Provider snapshots typically live in the same account you might lose access to, retain for a short window, and restore the entire machine rather than one database or one directory. Treat them as a convenience, not as your backup strategy.

Does GDPR require backups?

Article 32(1)(c) requires the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident. It does not name products or schedules, but an untested backup is difficult to argue as an appropriate measure if you are ever asked to demonstrate it.

Backups

Backups that actually restore

Almost every small business has backups. A surprising number discover, at the worst possible moment, that they have archives instead.

By David Kabel · Updated 2026-09-01 · 3 min read

The short answer

Back up the application files, the database and the configuration as three separate jobs. Dump databases rather than copying their files. Store at least one copy in a different failure domain from the machine, using credentials production cannot use to delete it. Then restore one on a schedule and time it, because a backup you have never restored is a file, not a backup.

The four ways backups fail

These are not exotic. They are the ordinary ones, and they share a property: everything looks healthy right up until you need it.

Something was excluded and nobody reviewed itAn exclude pattern written on day one quietly stops covering a directory that mattered by month six. The archive extracts perfectly. The data you needed is not in it.
The backup ran against a live databaseCopying database files while the engine is writing produces an archive that restores into a corrupt database. You need a dump or a snapshot, not a file copy.
The copy is in the same failure domainA second disk in the same machine survives disk failure and nothing else. A bucket at the same provider in the same region survives host failure and nothing else.
The credentials that write backups can also delete themRansomware and a compromised host both use the same credentials you do. If production can delete the backups, the backups are part of production.

What "off-site" actually means

Off-site is not a folder. It is a different failure domain: infrastructure that can fail independently of the thing it protects. Ask one question of any backup destination: what single event takes out both this and the server? If you can name one easily, it is not off-site enough.

The credential point matters just as much and gets less attention. If the server holds keys that can delete the backup bucket, then anything that compromises the server can delete your backups. Append-only or write-once retention removes an entire category of bad day.

The restore test is the whole thing

Everything above is preparation. The test is the product. Restore to a scratch machine, bring the application up, log in, and check that the data is actually there and current. Then write down how long it took, because that number, not your backup schedule, is what you would tell a customer during an outage.

A restore that worked

In May 2026 a client hit a serious failure and needed everything back. Their words afterwards: “We had a serious issue and he restored everything from backup quickly.” That outcome is not luck; it is the difference between a backup regime that has been exercised and one that has only ever been configured.

WaterArchery, May 2026. More client feedback.

[OPTIONAL: add the elapsed restore time if you recorded it. A real number here is the single most quotable sentence on the page.]

Want backups you have proof of?

Wardio backups are integrity-checked automatically, written to versioned storage with credentials that cannot delete, and come with a written restore procedure. Full restore rehearsals of large datasets are scoped as separate work. See pricing.

Free server review