GuidesOnly show guides for your app
GuidesGuidesManaged databases have their own backups, separate from server file backups — take them from the Databases page, export SQL dumps from phpMyAdmin, and practise the restore before you need it.
A server backup captures the files in /home/container — but a managed database doesn't live there. It runs on a separate always-on host, so it needs its own backups. Falix gives you two ways to take them: the panel's per-database backups (a couple of clicks) and, for MySQL, a SQL export from phpMyAdmin (a portable file). This guide does both, plus the step everyone skips — actually testing that a restore works.
| At a glance | |
|---|---|
| You need | A managed database on your server's Databases page |
| Plan | Any — free stores backups to your Google Drive; premium stores them on the node |
| Time | Ten minutes, then a five-minute restore drill |
| Panel backup | phpMyAdmin SQL export | |
|---|---|---|
| Where | Databases page → Manual / Automatic tabs | phpMyAdmin → Export |
| Produces | A managed backup you restore in one click | A .sql file you download and keep |
| Types | MySQL, PostgreSQL, MongoDB | MySQL only |
| Best for | Routine safety before risky changes | A portable copy, or moving data elsewhere |
Use both: panel backups for quick day-to-day rollbacks, and an occasional SQL export you download so a copy exists off Falix entirely.
Open Databases from your server menu and pick a database. Its backups live under two tabs:
Where they're stored depends on your plan:
🎯 Good to know: Take a manual backup right before anything risky — a schema change, a bulk
DELETE, a migration, a big import. It's the cheapest insurance on the platform, and it's the backup you'll be glad exists when a query does more than you meant.
For MySQL, the Databases page has a phpMyAdmin button — a full web interface for your database. It's the way to get a copy you fully control:
.sql file containing every CREATE TABLE and INSERT needed to rebuild the database.Keep that file somewhere safe. It's plain text, it's portable, and it restores anywhere that speaks MySQL — including a brand-new Falix database.
💡 Tip: A
.sqldump is also how you seed a new database or move between plans: create the new database, open its phpMyAdmin, and use the Import tab to load the file. Same tool, opposite direction.
A backup you've never restored is a guess, not a safety net. Both routes restore easily:
.sql file, and run it.Now the part almost nobody does — practise it once, deliberately, before you're relying on it:
Five minutes now tells you your backups are real and you know the buttons. Discovering the process for the first time during an actual incident is how people lose data they technically had a backup of.
⚠️ Heads up: A restore overwrites the database's current contents with the backup's. That's the point — but it means you lose anything written since that backup was taken. When in doubt, take a fresh backup first, then restore the old one, so you can go either direction.
Not every database is a managed one, and the backup route differs:
/home/container, so a server backup captures it like any other file — or copy app.db after a WAL checkpoint (see the SQLite guide). It is not on the Databases page.The neat rule: managed database → Databases-page backups; anything living in /home/container → server backups.
After a backup, it appears in the Manual (or Automatic) list with a timestamp — that's confirmation it ran. After a restore, open phpMyAdmin (or query from your app) and check a row you know should be there. For a SQL export, the downloaded .sql file opening in a text editor and showing your CREATE TABLE statements means it's a real, complete dump.
s{serverId}_... database in the sidebar before Export..sql file can time out in the browser. Split it, or import table-by-table.