30 August 2026 · 8 min read
Do your backups actually restore?
Every operator says they have backups. Far fewer have ever restored one, and a backup nobody has restored is a file, not a safety net.
What is actually at stake?
Not the website. The website can be reinstalled in an hour.
What cannot be reinstalled is the record: who deposited, how much, which plans are running, what has accrued, what has been paid, and what you owe. Lose the database and you have lost the answer to every question a user will ask you the following morning.
What has to be in the backup?
| Priority | What | Why |
|---|---|---|
| 1 | Database | Every balance, plan and transaction lives here |
| 2 | Uploaded files | Documents and images users provided |
| 3 | Configuration | Faster than reconstructing settings from memory |
| 4 | Application code | Reinstallable, but convenient to have |
If you only ever get one thing right, make it a verified database backup.
An admin controlled investment platform, installed and configured for you. Full admin control, live in 6 to 12 hours, from $149.
How often is often enough?
Turn the question around: how much activity could you afford to lose?
If you take twenty deposits a day, a nightly backup means losing up to a day of them, and you would be reconstructing those from gateway records and user messages. That is survivable but unpleasant.
Daily is the floor. More frequent database snapshots are cheap because the database is small compared with everything else, and they shorten the window you would have to rebuild by hand.
Where should backups live?
- Not only on the same server: a failure that takes the machine takes them too
- At least one copy elsewhere: different provider, or an object store, or somewhere you control
- Encrypted: they contain everything about your users, so treat the file as sensitive rather than as an archive
- Access controlled: a backup is a complete copy of your platform, and it should not be reachable by anyone who should not have that
That last point connects to admin access generally, which is covered in multiple admins: who should see and do what?
The test that makes it real
Once, before launch, and once every few months afterwards:
- Take a backup
- Restore it onto a separate server or a local copy
- Log in to the restored copy and check a few known accounts and balances
- Note how long the whole thing took
That last number is the one that matters during an incident. Knowing a restore takes forty minutes changes how you talk to users; not knowing means guessing while people wait.
What to do when you need one
Stop the platform first. Restoring underneath a running site, while the scheduler continues and users transact, produces a mixture of old and new data that is worse than either.
Then: put the site in maintenance mode, stop the scheduler, restore, verify your totals, and only then bring it back. That is the same discipline as a server move, described in how do you move a live platform to a new server safely?
What a backup cannot give you back
A restore returns you to the moment the backup was taken. Everything after that moment is gone, and on a platform taking deposits that gap has to be filled by hand.
Say the backup ran at midnight and the failure happened at four in the afternoon. Sixteen hours of deposits, withdrawals, plan starts and support decisions are missing from the restored copy, while the money itself really did move.
Three sources let you reconstruct it:
- The payment provider or the network: every deposit that arrived is recorded on their side, with amounts and times
- Your outgoing transactions: withdrawals you actually sent exist in the wallet or gateway history, whatever your database says
- Email: the notifications your platform sent before it failed are a record of what users were told
That last one is worth noticing. Emails you sent are evidence that survives the server, which is one more reason to send them for every money event, per the platform email guide.
Reconstruction is manual, slow and error prone, and every hour between backups makes it longer. That is the real argument for frequent database snapshots rather than a nightly job you never think about.
Common questions
What exactly should be backed up?
The database first, because it holds every balance and transaction. Then uploaded files, then configuration. The application code you can reinstall.
How often should backups run?
At least daily on a platform taking deposits, and more often if volume is high. The question to ask is how much activity you could afford to lose.
Is a backup on the same server enough?
No. A backup that dies with the server is not a backup. Keep at least one copy somewhere else.
How long should backups be kept?
Long enough to catch a problem discovered late. A common pattern is daily for a month and monthly for a year.
Do backups contain user personal data?
Yes, which makes them sensitive. Encrypt them, and be careful where copies are stored and who can reach them.
What is the most common backup failure?
A backup that has been running for months and produces a file that cannot be restored. Nobody notices until the day it matters.
Question this did not answer? Ask on Telegram. Reader questions get written up first.