Skip to main content

Backups

One piece of Maintenance's technical layer, but it deserves its own treatment — get it wrong and every other maintenance practice is just delaying the day something unrecoverable happens.

Four things this rests on​

Not invented for this project — this is how backup and disaster-recovery planning works generally:

  1. The 3-2-1 rule. Three copies of anything that matters, on two different mechanisms, one of them genuinely off-site. Not three copies of the same kind of thing — three different kinds, so a single failure mode can't take all of them out together.
  2. Snapshot ≠ backup. A snapshot lives on the same storage backend as the thing it protects — fast, cheap, but it fails right alongside the original if that backend fails. A backup, properly defined, is independent of the primary storage entirely. Conflating the two is a common, real mistake, not a pedantic distinction.
  3. Organize by intent, not by where data lives. The right question isn't "what files are involved" — it's "what failure am I recovering from, and how fast does that recovery need to be" (a recovery point/time objective, in the standard terms). Different intents justify genuinely different mechanisms, even when they touch overlapping data.
  4. Credentials are their own concern, not a backup detail. A perfect backup of encrypted data is worthless without whatever decrypts it. That's not a data problem solvable with more copies — it's custody, and it needs handling separately from whatever mechanism copies the data itself.
  5. A backup only protects what it actually captures. A blind copy gets whatever's physically sitting on disk, not whatever the app's data model claims exists. An app storing files in object storage rather than locally keeps only a reference in its database — the blind copy gets the pointer, not the object.

Three layers, by intent​

Infrastructure recovery — get the whole platform back if something fundamental failed, not one service misbehaving. This itself splits by how broad the failure is, not by how bad the mistake was:

  • The storage backend is still healthy, but the instance or its data isn't — recoverable fast, locally, because what it's recovering onto is still intact.
  • The storage backend itself is what failed — the pool, the datacenter, the provider. Nothing local can help here by definition; this is what actually needs to be off-site.

Project recovery — revert one thing, without touching everything else. The premise is narrower: the host and the platform on top of it are both healthy, only what one project holds needs to go back. A different trade-off follows from that: frequent and cheap rather than rare and heavy, fine-grained retention (revert to an hour ago) rather than coarse, and no need for the geographic diversity infrastructure recovery requires — reverting a corrupted service doesn't require surviving a datacenter loss.

Credential recovery — get back in when what's lost is the thing that unlocks everything else, not the data itself. This is principle 4 as its own layer rather than a footnote: a perfect Infrastructure or Project recovery is worthless without whatever decrypts what it restores, so this layer's job isn't copying data at all, it's making sure there's still a way in once the primary path to a credential disappears.

Evaluating a new app​

Not a one-off analysis — the same questions apply every time a new service gets added to this stack:

  1. Does it hold state at all? A stateless service needs nothing here — there's nothing to lose that redeploying doesn't already restore.
  2. Where does its data actually live? On the volume, or referenced from object storage it doesn't own (principle 5)? If the latter, confirm what actually gets captured before assuming coverage.
  3. Does it have its own native backup path? One that understands its data model — a database dump, an app-level export — beats a blind copy every time it exists.
  4. If not, does Coolify's own per-resource schedule cover it? That's the default before reaching for anything heavier.

Whatever's left after that — genuinely stateful, no native tool, needs disaster-level protection regardless — is what infrastructure recovery exists to catch as a blunt, whole-volume net underneath everything else.