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 |
The two halves you must back up separately
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.
What's worth backing up (and what isn't)
Back up things you can't cheaply recreate:
- Your source code — though if it's in Git, Git is a backup of your code. Push it and this box is ticked.
- Config and secrets — configs you hand-tuned, and
.env(store it somewhere safe; don't put secrets in a public repo — see keeping secrets out of Git). - Save/world data — Minecraft worlds, game saves, anything generated at runtime.
- Database contents — via a dump, as above.
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.- Logs and caches — noise you'll never restore.
How often — a cadence by project type
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.
Automate it so you don't have to remember
A backup you have to remember is a backup you'll skip. Wire it up once:
- The Backups page has an Auto tab for scheduled snapshots.
- The Backup task on the Schedules page folds a backup into a routine — nightly at 4 AM, or right before a scheduled restart. (The Backup task is a premium schedule task; on free, take backups from the Backups page.)
- Attach a webhook to that schedule so a task-completed or task-failed message lands in Discord — now you hear about a backup that quietly broke instead of finding out when you need it. See Automation recipes.
The strategy in three habits
- More than one copy, more than one place. Falix keeps your snapshots; for anything you truly can't lose, Download a copy off-Falix too. On premium, lock the backup you never want auto-deleted (a full backup limit auto-removes the oldest unlocked one).
- Test your restores. A backup you've never restored is a hope, not a plan. Do a restore drill onto a staging instance or a clone and confirm the data really comes back.
- Know what survives what. Backups survive a reinstall. Free-plan (Google Drive) backups survive deleting the server; premium node backups don't — download before you delete. Managed databases survive restarts and reinstalls on their own.
Troubleshooting
- Restored files but the data's still gone — your data was in a managed database, which a files backup doesn't include. Restore from the database dump instead.
- Restore won't start — the server is busy with another job (install/transfer/another restore); wait for it to finish. For a clean restore, stop the server first.
- Backup/restore failing — see Backup and restore issues.