A backup you have never restored is not a backup

Ask any hosting provider whether backups are taken and the answer is yes. Ask when a restore was last performed from those backups, and the answer is often silence.

The second question is the only one that establishes anything.

How backups fail quietly

They rarely fail loudly. The job was configured once, it ran, and everyone stopped thinking about it.

Then something changes — a disk fills, a credential expires, a path moves, a database grows past a limit. The job now fails, and unless something is watching for failure, nobody knows. The dashboard shows the last successful run, which was months ago, and nobody looks at the date.

Backups that stopped silently are the standard way this goes wrong. Not corruption, not disaster — just a job that quietly stopped and a folder nobody opened.

Backed up is not the same as restorable

A file existing does not establish that it can be restored into a working system.

Files get truncated when a disk fills mid-write. Compressed archives corrupt. Databases dumped while transactions are in flight can be inconsistent. Backups covering the database but not uploaded files leave you with records referring to documents that are gone.

The only way to know is to restore one, into a separate environment, and open it.

The three questions

1. When was a restore last performed, and by whom? If the answer is never, treat the backups as unverified.
2. How long would a full restore take? Not whether it is possible — how many hours. This is what your business would actually be down for.
3. How much work would be lost? Daily backups mean up to a day of transactions gone. Whether that is acceptable is a business decision, not a technical default.

Those two numbers — downtime and data loss — are the ones to agree deliberately rather than inherit.

Where the copies live

A backup on the same server as the database protects against accidental deletion and nothing else. Hardware failure, ransomware and a compromised server take both.

At least one copy should be somewhere else, and reaching it should not depend on credentials stored only on the machine that failed.

What else has to come back

The database is the obvious part. It is rarely all of it.

• Uploaded files — attachments, logos, documents, scanned records
• Configuration and environment settings
• Any customisations, and the code they depend on
• Integration credentials and certificates

A restore that recovers the database and nothing else produces a system full of broken references. Worth testing what a restore actually gives you.

A proportionate routine

For a small business this does not need to be elaborate:

• Automated daily backup, with failure alerts to a person — the alert matters more than the schedule
• At least one offsite copy
• A restore test every quarter, into a scratch environment, taking under an hour
• A written note of the last successful restore date, kept where someone will see it
• Retention long enough to cover a problem discovered late — corruption noticed after two weeks needs a backup older than two weeks

That last point catches people. Seven-day retention is fine for an outage and useless for a problem nobody noticed for a fortnight.

The honest summary

Backups are a cost that produces nothing until the day they produce everything. It is genuinely difficult to justify testing them, and that is exactly why so few are tested.

The quarterly restore is the whole discipline. Everything else is configuration.

If you want hosting where restores are tested rather than assumed, see our managed ERPNext and Odoo hosting, or talk to us.