Backups

Trinium backs itself up. Choose where the bundles go and which kind each one is, then copy them, and your master key, somewhere off the server.

Configure backups inside the app under Settings → Backup. You do not need pg_dump; Trinium backs itself up.

Where they go. A Local backup is a file in the backups folder beside your compose.yaml (/trinium/backups inside the container). Step 2 of the install page creates that folder owned by uid 10001, the user Trinium runs as, and closed to everyone else (a portable backup is not encrypted), so on a Linux host reading a backup back out needs sudo, the same as secrets/. On Enterprise a backup can go to S3, Azure Blob or Google Cloud Storage instead.

To keep Local backups on another disk or a network share, mount it at that folder. Create a compose.override.yaml beside compose.yaml (Compose reads it automatically, and an upgrade never replaces it), naming the service your profile runs (trinium, core or controller):

services:
  trinium:
    volumes:
      - "/mnt/backup-disk/trinium:/trinium/backups"   # ← your path

Then docker compose up -d. The user Trinium runs as (uid 10001) must be able to write there, and Trinium never changes a folder's owner itself, because nothing in it runs as root. On a local disk: sudo chown 10001:10001 /mnt/backup-disk/trinium && sudo chmod 700 /mnt/backup-disk/trinium; on a network share, give uid 10001 write access on the share itself. Test on the Backup Destination card says whether Trinium can write there.

Moving the folder later? Copy the bundles already in backups/ to the new place before you switch. History remembers each backup by its file name inside the folder, so for one left behind it says Unable to locate the backup, beside where it was written and which server took it. Copy the file across, or delete the row.

Disk space while a backup is taken. Trinium writes the backup to disk, never to memory: each table first, then the backup file built from them, in a hidden .trinium-work folder inside backups/ that it empties when it is done. So while a backup is being taken, the disk holding backups/ needs about twice the backup's size free, even when the backup then goes to cloud storage.

Choose what a backup carries. There are two kinds. You choose one each time you press Back up now (the confirmation asks), and a scheduled backup is always the default kind:

A portable backup is the one that survives losing secrets/master.key. Everything comes back (pipelines, flows, versions and deploy history, schedules, users, run history), and each connection, your notification destinations, the SMTP relay, your sign-in providers, file storage and the backup destination need their password entered again. Because it is not encrypted, it is readable by anyone who has the file: it still holds your pipeline definitions, user names and email addresses, and your connection settings (hostnames, ports, database names and usernames, but never a password). Store it where you would keep those.

If you take the default kind, your master key is part of what you must back up. The key is not inside the bundle, the bundle is encrypted with it, so a default backup on its own is not enough to rebuild anything. Copy backups/ and secrets/ somewhere off this server: a backup that exists only on the machine it protects does not survive losing that machine. A portable backup needs no key and stands alone.

Restoring. Under Settings → Backup, press Restore on a backup in History, or Restore… to send a backup file from your computer. Once the file has arrived, the restore runs on the server: the page shows Restoring…, closing it does not stop it, and the result shows when it ends. A file Trinium cannot restore (another server's master key, a damaged file, a backup from a newer version) is refused before anything is changed, and a restore that fails part way changes nothing. There is no size limit on the file you send, but a reverse proxy in front of Trinium may have its own (nginx's client_max_body_size, for one).

Two things Trinium's own backup does not cover, so back them up yourself if they matter:

• the trinium_filedata volume: files uploaded to the file library and run outputs;
• the trinium_pgdata volume, if you would rather manage the database directly (or use your provider's snapshots if you brought your own Postgres).