GuidesOnly show guides for your app
GuidesGuidesBackups only help if they cover the right things at the right cadence — and a server-files backup does not include your managed databases. Here's what to back up, how often, and how to compose files plus databases into one plan.
Everyone knows they should have backups. Far fewer discover, at the worst possible moment, that their backups didn't cover the one thing that broke. A backup is only as good as its coverage and its freshness — and on Falix there's a specific trap: a server-files backup does not include your managed databases. This guide turns "I take backups sometimes" into a real strategy: what to back up, how often, and how the two halves fit together.
| At a glance | |
|---|---|
| You need | Any Falix server; a managed database if your app uses one |
| Plan | Any — free backs up server files to your own Google Drive |
| Time | Twenty minutes to set up, then it runs itself |
Your data lives in two different places, and each needs its own backup:
| Half | Lives in | Backed up by | Covers |
|---|---|---|---|
| Server files | /home/container on your server |
The Backups page | Code, configs, worlds, save files, SQLite files, .env |
| Managed databases | A separate shared DB host | A database dump / export | Rows in MySQL / PostgreSQL / MongoDB |
⚠️ Heads up: This is the mistake that costs people their data. A managed database does not live in your server's files — it runs on a separate host and outlives your server's restarts and reinstalls. That's great for durability, but it means a Backups-page snapshot skips it entirely. If your bot or app keeps data in MySQL/Postgres/Mongo, you must export the database as well. See Database backups and, for MySQL, phpMyAdmin.
Back up things you can't cheaply recreate:
.env (store it somewhere safe; don't put secrets in a public repo — see keeping secrets out of Git).Don't waste backup space on things that rebuild themselves:
node_modules / target / .local / vendor — reinstalled automatically on the next start. Add them to exclude patterns when you create a backup.Match the frequency to how fast the data changes and how much a loss hurts:
| Project | Files | Database | Extra |
|---|---|---|---|
| Discord bot (SQLite) | Nightly | — (SQLite is a file, caught by the files backup) | Back up before schema changes |
| Discord bot (managed DB) | Weekly (code's in Git anyway) | Nightly dump | — |
| Web app + managed DB | Before each deploy | Nightly dump, more often if writes are heavy | Code in Git |
| Minecraft world | Nightly + before any big change | — | Worlds change every session; back up often |
| Static site | Git is enough | — | Nothing dynamic to lose |
The rule underneath the table: back up right before anything risky — a deploy, a major update, world surgery, or switching the server's application (which reinstalls and wipes files). A pre-change snapshot is the one you'll actually reach for.
A backup you have to remember is a backup you'll skip. Wire it up once: