"You Own Your Data" Is Only True If You Can Restore It

Every self-hosted product page says some version of the same thing. Ours say it too:

"You get the full PHP source and your data lives in one database you own — nothing phones home, nothing expires."

That is a genuine advantage over a subscription, and it is the main reason people choose to self-host. It is also a claim that quietly transfers a responsibility, and almost nobody reads the transfer.

Because "you own your data" means: when it is gone, it is gone, and nobody is coming.

The uncomfortable arithmetic

A hosted vendor runs backups you never think about. Their business ends if they lose your data, so they have a team, a runbook, and a tested restore procedure. You are paying for that as part of the subscription, whether or not you have ever noticed it as a line item.

Self-host, and that team is you. Not conceptually — literally, at 7am on a Tuesday, with a customer waiting.

And the thing that makes this genuinely dangerous is not that people fail to take backups. Most people take backups. It is that an untaken backup and an untested backup fail identically, and only one of them feels like a risk.

What actually goes wrong

Not hardware. In practice, the failures that lose data on small self-hosted installs are these:

1. The backup was running and the database was not in it. cPanel's default account backup usually includes databases — but a rsync of public_html, or a hosting plan's "file backup," does not. The application files are replaceable; they are in the ZIP you bought. The database is the only irreplaceable part, and it is the part most likely to be missing.

2. The backup was in the same place as the thing it was backing up. A nightly dump written to /home/account/backups/ survives a bad UPDATE. It does not survive account suspension, a hosting company dispute, or a compromised account.

3. The backup was never tested and did not work. Truncated dumps, wrong character set, a mysqldump that silently failed on one table and returned zero anyway. These are invisible until the day you need them, which is the worst possible day to discover them.

4. The person who set it up left. The most common cause of an unrecoverable small business system is not a technical failure. It is that nobody currently employed knows where anything is.

The twenty minutes

This is the whole thing. It is not sophisticated and it does not need to be.

1 — Dump the database on a schedule (5 minutes to set up)

In cPanel, Backup Wizard will do a full account backup including databases. Better, if your host allows a cron: a nightly mysqldump of the one database, written to a dated filename.

Dated filenames matter. A backup that overwrites itself is one bad night away from being a backup of the problem. Keep seven daily and a few monthly.

2 — Get a copy off the server (10 minutes, and this is the step that counts)

A backup stored on the machine it protects is not a backup. It is a second copy of a single point of failure.

Any of these is fine:

Download the weekly dump to your own computer. Genuinely — a folder on a laptop that is itself backed up is a legitimate off-site copy for a small business.
Sync to a cloud storage account.
Have your host's backup service write off-account, if they offer it.

The test is simple: if your hosting account vanished today, could you still open a copy of the database?

3 — Restore it once. Today. (5 minutes, and it is the only step that proves anything)

Create a second, empty database in cPanel. Import your most recent dump into it. Point a copy of the app at it, or just browse the tables in phpMyAdmin and confirm your actual records are there.

That is it. That is the difference between a backup and a hope.

Until you have done this once, you do not have a backup — you have a file whose contents you have assumed.

Then write four lines down

Somewhere a successor will find them — a shared drive, the business's password manager, a printed sheet in a folder:

What is installed, and where (domain, folder)
Which database it uses (the full prefixed name)
Where the backups go, and how often
The date of the last successful test restore

The fourth line is the one that matters, and it is the one nobody writes. A dated restore test converts "we have backups" from a belief into a fact with an expiry date on it. Re-test when it is a year old.

How often is enough?

Ask one question: how much work can you afford to re-enter by hand?

A day → nightly backups are fine.
An hour → you need more than a small self-hosted setup comfortably provides, and you should think seriously about whether this system should be self-hosted at all.

That second answer is real advice, not a hedge. Some data justifies paying somebody else to worry about it — and knowing which of your systems those are is worth more than any backup script.

What this means for the buying decision

We sell software that runs on your server. The honest version of our own pitch is:

"You own your data" is a genuine benefit and a genuine obligation, and it arrives on the same day.

Own the things where a day of lost work is survivable — a rota, a leave register, an equipment log, a petty-cash ledger. Think harder about anything where losing the record is a legal, financial or safety problem — a waiver archive, a compliance register, a rent ledger. Those are still perfectly ownable, but only if you are actually going to do the twenty minutes above, and you should be honest with yourself about that before you buy rather than after.

And if the honest answer is that you will not do it — that is genuinely useful to know, and a hosted subscription is a reasonable thing to buy instead. We would rather say so than sell you a licence that becomes a liability.

The short version

Take a dump on a schedule. Get a copy off the machine. Restore it once and write down the date.

Twenty minutes, and it converts the best argument for self-hosting from a slogan into something that is actually true.

Skip the third step and you have not saved twenty minutes. You have deferred finding out, to the worst possible day.

Next steps

Installing a PHP app on cPanel — the whole click path — the companion to this one
Self-hosted software by category — every product's demo is ungated, so you can judge before you commit
Where the one-click half of this lives: every app in the catalog ships a backup button that produces JSON plus the raw database file — Gymora is a representative example; this article is about the restore half, which stays your job

This guide sells nothing. It exists because the strongest claim in self-hosted software is also its most commonly unearned one, and we would rather you earned it.