Skip to content

Backup and restore

Central has one state carrier — PostgreSQL. Which means the installation's entire backup is a regular dump of one database; neither the streamers' state directories nor the archive belong in it, and neither is needed to restore the control plane.

Take dumps

pg_dump -U catena catena > catena-$(date +%F).sql

The credentials are in DATABASE_URL from /etc/catena/secrets.env. Put it on a timer and move the copies off the machine: the dump is small (configuration and records, not media), so taking it even hourly costs nothing.

Save the /etc/catena/secrets.env file itself once, at installation time: it is not in the dump, and a restored installation will need the same passwords.

Restore

The procedure is verified end to end — from the dump to a cluster back alive:

  1. Stop central: systemctl stop catena.
  2. Recreate the database and load the dump:
psql -U catena -d postgres -c 'DROP DATABASE catena WITH (FORCE);' -c 'CREATE DATABASE catena OWNER catena;'
psql -U catena -d catena < catena-2026-07-21.sql
  1. Start central: systemctl start catena.

Nothing else is needed: the channels, the registry and the settings came back with the dump, and the streamers — which kept broadcasting on their own all along — reconnect automatically, within the minute-long retry pause. If the dump turns out older than what the streamers have applied, they get an explicit signal from central and take its state as the truth — a version rollback does not tear the cluster.

Complete destruction of central — broadcasting never stops

This is the core guarantee of the Catena architecture: losing the central machine whole — disk, database, everything — does not interrupt the air. The streamers broadcast autonomously, viewers keep watching, and while you build a new central, none of them notices.

  1. Install Catena on a new machine (installation) without entering the console.
  2. Return the saved /etc/catena/secrets.env (or put the old DATABASE_URL into the new one, if the database was external and survived).
  3. Restore the database from the dump as above, and start the service.

The streamers find the new central at the old address and reconnect — their keys arrived in the dump together with the registry. The control plane died and was rebuilt from scratch, and broadcasting never noticed: the air did not stop for a second.

If there is no dump — the control plane is built anew: an empty central, channels created from scratch, and every orphaned streamer re-attached with a state reset and a fresh join token. The air keeps running in this scenario too — but the channel configuration has to be recreated by hand. One regular pg_dump spares you rebalancing the whole cluster.

What not to back up

  • The streamers' state directories — that is a machine's identity; when the machine dies, you simply join it anew.
  • The DVR archive — media on the streamers' disks; its safety is a matter of disks and replication, not of the database dump.
  • The metrics store — in memory, the history accumulates again.