Quick Answer
If you built your app with Lovable, Bolt, Cursor, or Claude Code on a free plan, you almost certainly have no backup you could actually restore from. The fix is not one toggle — it is a small plan: automate a nightly copy of your database, turn on point-in-time recovery if your plan allows it, keep one copy somewhere other than your app, decide how much data you can afford to lose, and run one test restore before you launch. The whole thing takes an afternoon to set up. The part everyone skips — proving the backup works — is the part that saves you.
You shipped something real. It works, people are signing up, and their data is piling up in your database. Then one day a bad change, a corrupted table, or a hacked login wipes it. You go looking for your backup, and that is when you find out the truth: there isn't one you can use.
This is the quietest way an AI-built app breaks. Not a crash. A loss you cannot undo.
Why Your AI-Built App Probably Has No Real Backup
Your AI assistant built the app to run. It did not build it to survive a disaster. Those are different jobs, and nobody told the AI to do the second one.
Most vibe coders launch on a free database plan, and free plans are not built to save you. Supabase, the most popular database behind AI-built apps, does not keep restorable automatic backups on its free tier. Instead it tells free users to export their own data and store copies off-site (Supabase docs). Paid plans do get daily backups — 7 days on Pro, 14 on Team, up to 30 on Enterprise — but if you are on free, the backup system is you.
Definition
A paid feature that lets you rewind your database to any second in the past — say, to the moment before a bad change wiped a table. It is finer than a once-a-day backup, but it only exists on paid plans.
The Mistake That Turns a Backup Into a Guess
Here is the part almost every guide skips. Making a backup is the easy half. Restoring it is the half that fails.
Definition
A test where you actually rebuild your app's data from a backup, start to finish, to prove the backup works. A backup you have never restored is not a backup — it is a hope that the file is good.
The numbers are brutal. Across the industry, roughly 30 to 40% of backup restores fail when people finally try them, usually because nobody ever tested the restore ahead of time (Sequentur). And in a 2023 study, 31% of businesses — more than one in four — could not restore their data during a ransomware attack, even though 92% of them said they had backups (At-Bay 2023).
They had backups. They just could not get their data back. That is the gap this plan closes.
The 6-Point Backup Plan
Run through these before you launch. Each one is a setting or a habit, not a coding task.
| # | Step | What it means in plain English |
|---|---|---|
| 1 | Know your starting point | On a free plan, assume zero restorable backups. You are the backup system. |
| 2 | Automate a nightly copy | A free scheduled job saves a fresh copy of your database every night, no server needed. |
| 3 | Turn on point-in-time recovery | If you are on a paid plan, switch it on so you can rewind to any second. |
| 4 | Keep a copy off-site | Don't store the only copy next to the live app. One copy lives somewhere separate. |
| 5 | Decide what you can lose | Pick how many hours of data loss is survivable, and how long you can be down. |
| 6 | Run a restore drill | Actually rebuild from a backup once before launch, then once a month after. |
A few of these deserve a plain-English note.
The off-site copy follows a rule professionals call 3-2-1: three copies of your data, on two kinds of storage, with at least one kept somewhere else entirely (Cohesity). Five copies in the same place all die together. One copy somewhere else survives.
Deciding what you can lose sounds technical but isn't. Ask two questions: if disaster hits, how many hours of new data can I afford to lose, and how many hours can my app be down? Your answers tell you how often to back up and how fast you need to recover.
You Do Not Have to Set This Up By Hand
Honestly, wiring up a nightly job, turning on the right settings, and running a real restore test is fiddly — and it is exactly the kind of thing a non-coder dreads. Miss one step and the whole safety net has a hole you cannot see.
So we built the plan into a drop-in skill for Claude Code. You add it to your project, run one command, and it sets up your automated backup, checks your recovery settings, and walks you through a real restore drill in plain language. No terminal expertise. No guessing whether it worked.
Key Takeaways
- Free-plan databases like Supabase free tier keep no restorable automatic backups — on free, you are the backup system.
- The risk is not making a backup; it is the restore. About 30-40% of restores fail because they were never tested.
- In 2023, 31% of businesses could not recover their data during a ransomware attack despite having backups.
- A real plan has six parts: know your starting point, automate a copy, enable recovery, keep an off-site copy, set your loss limits, and run a restore drill.
- A drop-in skill can set the whole thing up and run your first restore drill for you.
Your Next Step
Your AI built the app. Now make sure that if the worst happens, you can bring it back. Set up the plan before your next deploy, and run one restore drill so you never have to find out the hard way that your backup was only a hope.
Want the plan done for you? Get the Backup & Disaster Recovery Blueprint — it sets up your automated backups and walks you through your first restore drill, step by step.
Read Next
- Database Settings Every Vibe Coder Forgets Before Going Live
- The 10-Step Security Check Before Your AI App Goes Live
- GDPR + AI in 2026: The 12-Point Checklist
- The Best AI Coding Assistant for Non-Developers
- How AI Builds Your Passive Income While You Sleep
Frequently Asked Questions
A backup is a snapshot of your data taken at a moment in time, usually once a day. Point-in-time recovery, or PITR, lets you rewind your database to any second in the past, not just the last daily snapshot. That matters when a bad change happens at 2pm and your last backup was midnight — with daily backups you lose the whole afternoon, while PITR can take you back to 1:59pm. PITR is a paid feature, so most vibe coders on free plans rely on automated daily copies instead. Both are valid; PITR is simply the finer-grained, paid upgrade.