Skip to main content

Backups and restores

Backups and restores​

Backing up an application correctly is application-specific work. A relational database needs a pg_dump. A graph database needs its own dump tool. A stateless API server doesn't need any application-level backup at all — just its persistent volumes.

Styrmin's job is to make backups across a whole stack feel like a single operation, while still doing the right thing per component. This page explains how.

The pieces​

  • Velero — an open-source Kubernetes backup tool that snapshots volumes and ships them to S3-compatible object storage. Styrmin uses Velero under the hood.
  • A Backup Storage Location (BSL) — an S3-compatible bucket (DO Spaces, MinIO, AWS S3, …) that Velero writes backups to. You configure one per environment.
  • A backup strategy per component — declared by the driver. Tells Styrmin how to back up that specific component.

Backup strategies​

Each component in a driver can declare a backup kind. Styrmin maps kinds to strategies:

StrategyWhat it doesUsed for
diskSnapshot the component's volumes directly.Stateless workloads, or stores that are safe to snapshot live.
postgresRun pg_dump into a sidecar volume, then snapshot it.Postgres databases.
mariadbRun mariadb-dump into a sidecar volume, then snapshot it.MariaDB / MySQL databases.
mongodbRun mongodump into a sidecar volume, then snapshot it.MongoDB databases.
neo4jRun neo4j-admin dump into a sidecar volume, then snapshot it.Neo4j graph databases.
actionRun a custom driver-defined Python action.Anything that doesn't fit the patterns above.

The driver author picks the strategy per component. The operator runs the right one when a backup is triggered — you don't think about it.

What happens when you click "backup"​

  1. You trigger a backup for a deployment (UI, CLI, or GraphQL).
  2. Styrmin schedules a Prefect flow on the agent.
  3. For each component, Styrmin asks the strategy "what do I need to do before and after Velero takes its snapshot?" — for a Postgres component, that means running pg_dump first.
  4. The agent creates a Velero Backup object describing what to snapshot and which hooks to run.
  5. Velero does the snapshotting and ships the result to the BSL.
  6. Styrmin records the backup, including the underlying Velero backup name, so it can be referenced later.

What happens when you restore​

A restore is the same machinery, run in reverse:

  1. You pick a backup and a target deployment (the same one or a different one).
  2. Styrmin asks each strategy "what do I need to do to bring this backup back?" — for a Postgres component, that means restoring the dump and replaying it.
  3. The agent creates a Velero Restore object with the right hooks.
  4. Velero pulls the data back from the BSL and lays it down.
  5. The restore hooks run, the application comes back up, and the deployment is now serving the restored data.

Why one BSL per environment?​

A Backup Storage Location is attached to an environment, not to a deployment. That gives you a few useful properties:

  • All backups for an environment live in one place. Easy to retention-manage, easy to point at a different region per environment.
  • Cloning an environment can also copy its backup history. If you clone production into a test environment, the clone can be pointed at the production BSL (or a copy of it) without per-deployment fiddling.
  • A BSL is shared infrastructure. Setting it up once per environment is cheaper than setting it up per deployment.

What you set up vs what Styrmin handles​

StepWhat it covers
Once per environmentThe bucket, credentials, and Velero BSL configuration.
Once per driverThe backup kind per component, in the driver spec.
Per backupNothing — Styrmin orchestrates the rest.

Next​