Most people building an app get a first bad day with their database eventually. You run a change against it, or an integration writes something it shouldn’t have, and a table you needed comes back empty. Nobody hacked you and you did nothing unusual, but the data is gone, and now you have to answer a question you have never had to think about: can you get it back?
Most people building with Lovable, Bolt or Replit assume the answer is yes, because backups feel like the kind of thing that happens quietly in the background. Sometimes they do. Often they don’t, or they do less than you think, and you find out on the day it counts. So let me walk through how to check, in the order I would do it.
1. Do you even have backups?
Managed databases usually offer automatic backups, but not always, and not on every plan. Free tiers frequently include none. The tier one step up might include daily snapshots kept for a week. You won’t know which one you’re on until you look, and “I use Supabase, so I’m fine” is a guess rather than an answer.
To check it: open your database provider’s dashboard - Supabase, Neon, Railway, or whatever manages your Postgres - and find the backups or recovery page. Read three things off it. Are automatic backups switched on at all? How often do they run? How far back do they reach? Write those three answers down somewhere you will find them again. If the page says backups are not included on your current plan, you have found the most important thing on this list.
2. Losing a day, or losing a few minutes?
There are two kinds of backup and the gap between them is large. A daily snapshot copies your whole database once a day. If disaster strikes at 4pm and your snapshot ran at 3am, everything between 3am and 4pm is gone. For an app taking sign-ups or payments, that can be a lot of people.
Point-in-time recovery is the better kind. It continuously records changes, so you can rewind to almost any moment, often to within a minute or two before the thing went wrong. The difference is losing a day versus losing a coffee break.
To check it: on that same backups page, look for the words “point-in-time recovery” or PITR. It is usually a paid feature on a higher tier, and it is one of the few upgrades I think is worth paying for the moment you have users whose data you cannot cheerfully recreate. If you only have daily snapshots, that is fine to launch on. You are choosing to accept losing up to a day, so make it a choice rather than a surprise.
3. The untested-restore trap
This is the part almost nobody does, and it’s the one that decides whether the rest was worth anything. Until you have restored a backup, you don’t really know you have one. You’re assuming a file exists, that it’s complete, and that it can be turned back into a working database, and any of those can quietly be untrue. A backup can run against the wrong database, capture a table but not the data inside it, or sit in a format nothing will read, and you tend to find out which at restore time, when you have no patience for it. Restoring into a scratch database takes about an hour and settles the question in advance.
To check it: create a new, empty database - a throwaway one, separate from your live app - and restore your most recent backup into it. Most providers have a “restore to a new instance” option that does this without touching production. Then look at the result. Are your tables there? Open the ones that matter and count the rows. Is your most recent real record present, the sign-up from yesterday, or does the data stop a week ago? Try a query your app runs in production. If the scratch database answers it correctly, your backup is real. If anything is missing or malformed, far better to know today. Delete the scratch database when you are done.
4. The disasters that are not hacks
When people picture losing their data they picture a hacker. In practice the everyday causes are much more ordinary, and backups are your defence against all of them:
- A migration that drops a column. A schema change meant to rename a field deletes it instead, and the values go with it.
- A
deletewithout awhere. One missing line turns “remove this one test account” into “remove every account”, and most people who work with databases have done it at least once. - An integration that overwrites records. A sync from another tool runs the wrong way and stamps your real data with blanks or duplicates.
- A founder testing in production. You try something on the live database because it was quicker than setting up a copy, and quicker is exactly how these go wrong.
These are ordinary mistakes rather than careless ones, and a backup is what keeps an ordinary mistake from being permanent.
5. Where do the backups live?
A backup sitting in the same account as the database it protects is weaker than it looks. Against a bad delete, same-account is fine. If the risk is the account itself - a billing failure that suspends everything, a provider incident, credentials that get compromised and used to wipe the lot - then a backup living inside that account can go down with the ship.
To check it: ask where your backups are stored. Are they inside the same provider account as your live database, or copied somewhere separate? You do not need a second cloud provider on day one. But for anything you genuinely cannot lose, having one recent copy that lives outside the account it protects is the difference between a rough afternoon and a business-ending one.
6. Retention, and knowing your steps in advance
Two loose ends worth tying off. First, retention: how long backups are kept before they’re deleted. Some problems, a slow corruption or a bad record that nobody noticed for a fortnight, only surface after your oldest backup has already rolled off. Know your window.
Second, write down your restore steps now, while nothing is on fire. A short runbook is enough: where the backups are, how to start a restore, roughly how long it takes, and who to contact at the provider if it goes wrong. On a bad day you’ll be stressed and reading unfamiliar dashboards, and a page you wrote calmly in advance is worth a lot.
7. A word on the people whose data it is
There’s a human side beyond your own stress. People handed you their data because they trusted you with it, and losing it’s a breach of that trust even when no rule was broken. Where that data is personal - names, emails, anything identifying - it’s also a matter of law. Under UK GDPR, a serious loss of personal data can be a reportable incident with real deadlines. Reliable backups are most of what stops a data loss from also turning into a reportable breach. This is one thread in a larger picture, and I cover the rest in the full launch checklist.
Where to start
Do two things this week. First, confirm your backups exist at all: open the dashboard, read off whether they’re on, how often they run, and how far back they go. That alone puts you ahead of most people.
Then, when you can spare an hour, run one test restore into a scratch database and confirm your real data comes back. Until you have done that once, everything above is still a guess.
If you would rather not do this alone, it’s the sort of thing I check for a living. I’ll find out whether your backups are real, how far back they reach, where they live, and what your restore would look like on the worst day, then hand you a plan you can act on. No obligation to go further.
