How Flui protects data

This page explains which of your data Flui keeps and which it does not.

Flui protects three kinds of thing with three different mechanisms, and none of them replaces another: Flui itself, databases and volumes. Protecting a cluster uses the same three: it gives every application on the cluster the mechanism that fits it, including applications installed later.

What protects what

Subject	Mechanism	Runs	Restores as
Flui itself	encrypted dump of the control-plane database, sealed to a key only you hold	nightly	a new installation, by an operator, from a runbook
A database	continuous backup where the image allows it; scheduled dumps otherwise	continuously, plus a nightly base or dump	a new database, to a moment you pick (continuous) or to a dump
An application’s volumes	encrypted, deduplicated snapshots, one repository per application	nightly, before a deploy if you ask, or when you say	a new volume beside the app, or single files put back

Everything above is stored in object storage outside the cluster, in a destination you register. Ideally the destination is on a different provider from the cluster it protects.

Flui itself

The control-plane database holds every user, API key, provider token, cluster and application record Flui has. It is dumped, encrypted and sealed to an age key you generate on your own machine and keep in your vault. The private half never touches the server, because a key stored on the machine you are trying to recover is lost with it.

When the installation is gone, every other restore starts from this backup: the records say which applications existed, where, and with what configuration. There is no button for it. Rebuilding an installation from it is an operator procedure with a runbook; see Rebuild the control plane.

What it does not cover: your applications’ data. This backup holds only the platform’s own records.

A database

A database Flui recognises (PostgreSQL or MariaDB, from the catalog) is backed up by its own engine instead of by copying its files, because a file copy of a database that is being written to does not reliably open again.

Continuous backup, where the image supports it: every change is shipped off the cluster as it happens, on top of regular base copies it is replayed onto. You can restore the database to any moment you name inside the retained window, not only to last night.
Scheduled dumps, where the image cannot ship its changes, for instance a database inside another application’s bundle. Each dump restores to the moment it was taken, and dumps are kept for the retention you set, in days.

Recovery never touches the database you are looking at. It builds a new database beside it, with its own credentials, and you decide what to do next.

What it does not cover: a database Flui does not recognise. Flui does not quietly copy its files; it lists it as needing a decision.

An application’s volumes

Uploads, media, generated files: everything an application keeps on its volumes that is not a recognised database.

Each application gets its own encrypted repository in the destination, with a key derived from the destination’s passphrase and never stored. Each snapshot stores only what changed since the previous one, so a nightly snapshot of a large volume that barely changes costs very little.

What is kept:

Nightly snapshots: the last 7 daily and 4 weekly, and always the most recent one. You can add 3 monthly snapshots, for about 30% more space and two more months of history.
Snapshots you take yourself stay until you delete them. They do not push a nightly one out.
Snapshots taken before a deploy have their own history, separate from the nightly one.

You can restore in two ways:

Whole, into a new volume beside the application (or into another application). The running app is left alone until you switch to the restored volume.
File by file: browse a snapshot, pick files or folders, and write them back into the live volume or into a folder beside the current files.

When a database is writing to a volume, Flui copies the volume only if it knows how to pause that database for a consistent copy (Redis, Valkey, SQLite). Anything else is refused and listed as needing a decision instead of being copied half-written.

What it does not cover: data outside the application’s volumes, and container images.

Protect a cluster

You can set these up one application at a time, which is how you protect a single thing. Protecting a cluster does it for all of them:

a recognised database gets continuous backup, or dumps when its image cannot do continuous backup, and a first base copy right away;
every other application with volumes gets nightly snapshots;
Flui’s own components are skipped (the platform backup covers them), and so are applications that keep no data;
an application that already has a policy keeps it unchanged;
an application a person decided is not backed up (flui app backup skip) gets no policy;
applications installed later get a policy too, within minutes of their first successful deploy.

The policies it creates are ordinary policies: you can see, pause or delete each one. Stopping the protection of a cluster only stops new applications from getting one; the policies already created keep running.

Needs a decision

Two things end up here instead of being copied badly:

a database Flui does not recognise (an engine it has no consistent backup for, or an application marked as a database that does not say which engine it runs);
a volume the last nightly snapshot had to refuse because a database was writing to it.

Each one is a question for a person, shown per cluster in flui backup status and on the Backup overview, with two answers:

stop the application during each copy, so the volume is copied at rest (a short, scheduled outage every night);
leave the volume out, and protect that data another way.

Until someone answers, the volume is not backed up, and Flui says so instead of producing something that looks like a backup.

Backup before each deploy

This is set per application and is off by default. When it is on, each deploy first takes:

a restore point for a database with continuous backup. The deploy waits the few seconds this takes, and restoring to that point returns the database to just before the deploy;
a dump for a database kept by dumps, and a snapshot of the other volumes. Both are started but not waited for.

With required, a deploy stops when the backup before it cannot be taken. Otherwise the deploy goes ahead and the failure is logged.

Copies on the cluster

Separately from all of the above, an application’s volume can be copied inside the cluster. These copies are faster and cheaper to make, and faster to restore. A copy lives on the same disk as the application and is deleted with it, so it protects against a bad upgrade but not against losing the application or the cluster.

When a whole cluster is lost

Applications come back from Flui’s records and their data from the backups: databases from their continuous backup or their last dump, volumes from their most recent snapshot, whichever was taken last (nightly, by hand or before a deploy). See Rebuild a lost cluster.

When the lost cluster was the one running Flui, Flui itself comes back first, from the platform backup, followed by the applications that ran beside it. See Rebuild the control plane.

Which one do I want?

“I want to be able to go back to before that migration.” Use continuous backup for a database, with a backup before each deploy. For anything else, take a snapshot first.
“Someone deleted a folder of uploads.” Restore a volume snapshot file by file.
“I want to survive losing the whole cluster.” Protect the cluster, and answer what needs a decision. A copy on the cluster does not survive this.
“I want to survive losing Flui itself.” Use the platform backup, and keep the key somewhere else.

Summary

If you protect a cluster and answer everything it lists as needing a decision, every application on it, including those installed later, has its data off the cluster, except the ones a person decided not to back up. Databases can be restored to a moment, and volumes whole or file by file. Flui’s own records are covered by the platform backup, which is a separate decision because you keep its key.