Disk space

Trinium keeps its data in three Docker volumes and two folders. One of the volumes grows and shrinks with every large run, and it is worth knowing which.

Besides the volumes below there are two folders beside your compose.yaml. They are bind mounts, not Docker volumes, so a tool that backs up volumes will not see either of them:

• ./secrets/, the folder holding your master key, and the only thing on disk whose loss cannot be undone. Lose it and every credential this instance has saved is unreadable, and only a portable backup can be restored.
• ./backups/, where Local backups are written (see Backups). It grows by one file per backup until the retention count you set in Settings → Backup is reached.

Trinium keeps three kinds of data, in three volumes:

scratch is the one that grows unexpectedly, and it is worth knowing why before it surprises you. Three things go there:

• Files staged from a remote source. When a pipeline reads from S3, Azure, Google Cloud Storage, SFTP or a network share, the file is downloaded here first. A 20 GB CSV needs 20 GB, and a compressed file needs its uncompressed size, so a 2 GB .gz can need 20 GB.
• Output files on their way to a remote store. A pipeline that writes to one of those writes its file here first and uploads it when the run has finished, so a run that reads a 10 GB file and writes a 10 GB file needs about 20 GB at its peak.
• Overflow from large sorts, joins and summarizes. When one of these needs more memory than Trinium is allowed, it writes the excess to disk here instead of failing. That is deliberate: it is what lets a job larger than your RAM finish at all.

All three are deleted when the run ends. It is the peak, mid-run, that needs room. A File Action needs none of it: it copies inside one store, or streams from one store to another, without writing to this disk.

Inside pgdata, run history is kept for good, but the results of the Test button are not: each Test run keeps a preview of up to 50 rows per node output so the builder can show them, and Trinium deletes finished Test runs after 30 days. A Test run also downloads only a sample of a cloud folder (the first file, then more until it has 50 files or 64 MB), so pressing Test on a folder of thousands of files no longer fills scratch.

To see how much space each is using:

docker system df -v

Giving scratch its own disk

By default scratch sits with everything else Docker stores, on the server's main disk. If a job needs more room than that disk has, or you simply want it on faster storage, point it somewhere else. Create the directory, then put this in a compose.override.yaml beside compose.yaml (or add the volumes: block to the one you already have). Do not edit compose.yaml itself: an upgrade replaces it (see Upgrading), and the override file is yours, so it survives.

volumes:
  scratch:
    driver: local
    driver_opts:
      type: none
      o: bind
      device: /mnt/fast-disk/trinium-scratch      # ← your path

Then recreate the volume, which holds nothing worth keeping while Trinium is stopped:

docker compose down
docker volume rm trinium_scratch
docker compose up -d

Nothing else changes: Trinium does not need to know where it went.

Running out of space shows up as failed runs, and often as database errors too, because the database shares that disk. If runs start failing after they had been working, check free space first.