Backing up your databases

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.

Two kinds of database backup

Use both: panel backups for quick day-to-day rollbacks, and an occasional SQL export you download so a copy exists off Falix entirely.

Panel backups: the Databases page

Open Databases from your server menu and pick a database. Its backups live under two tabs:

• Manual — backups you take yourself. Hit create, optionally name it, and it captures that database's contents. Each one has Download, Restore, and Delete buttons.
• Automatic — scheduled backups the panel keeps for you. It retains the most recent 20 and rotates out older ones automatically.

Where they're stored depends on your plan:

• Free plan: database backups save to your own Google Drive, exactly like server backups — connect a Google account first when the page prompts. They don't count against any limit.
• Premium node: manual backups are stored on the node and count against your plan's backup limit. Automatic backups keep their fixed 20 and never consume that limit.

🎯 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.

phpMyAdmin: a portable SQL dump (MySQL)

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:

1. Open phpMyAdmin and sign in with the database's own username and password from the Databases page (not your Falix login).
2. Select your database in the left sidebar, then open the Export tab.
3. Leave the format on SQL (the "Quick" method is fine for most databases), and click Export. Your browser downloads a .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 .sql dump 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.

Restoring — and the drill that proves it works

A backup you've never restored is a guess, not a safety net. Both routes restore easily:

• Panel backup: on the Databases page, find the backup and press Restore. Confirm in the dialog, and the panel rolls that database back to the backup's contents.
• SQL dump: open phpMyAdmin, select the database, open the Import tab, choose your .sql file, and run it.

Now the part almost nobody does — practise it once, deliberately, before you're relying on it:

1. Create a throwaway database on the Databases page (or a spare table).
2. Put a little data in it, then take a backup.
3. Change or delete the data.
4. Restore the backup and confirm the original data is back.

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.

What about SQLite and self-run database servers?

Not every database is a managed one, and the backup route differs:

• A SQLite file lives in /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.
• A database engine you run yourself (the Redis / Mongo / Postgres application) stores its data in that server's files too, so a server backup captures it — but for a clean copy, take it while the engine is stopped, or export from inside the engine. These don't get Databases-page backups either.

The neat rule: managed database → Databases-page backups; anything living in /home/container → server backups.

Verify it works

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.

Troubleshooting

• phpMyAdmin asks for a login — use the database's username and password from the Databases page, not your Falix account.
• The Export button gave an empty or tiny file — you exported the wrong (empty) database, or didn't select one first. Pick your s{serverId}_... database in the sidebar before Export.
• Restore "succeeded" but data looks old — that's expected: a restore rolls back to the backup's moment in time. Anything newer than the backup is gone. Take a current backup before restoring an older one.
• Free plan: backups won't save — connect a Google account first; free-plan database backups go to your Google Drive and the page prompts you to link it.
• Import failed partway — a huge .sql file can time out in the browser. Split it, or import table-by-table.

Next steps

• Add a database
• Automate and manage backups
• phpMyAdmin walkthrough
• Cleaning up old data