Files
command-center/omp-docs/tools/gitea/data-persistence.md
T
Frank 62a70caebb docs(okf): 53 Obsidian wikilinks become OKF links
`[[page|Label]]` is Obsidian syntax, not OKF. `kb-lint` resolves it Obsidian-style — by
filename, anywhere in the bundle — so it has never tripped the link gate, while every other
consumer of the bundle (an OKF renderer, a Gitea wiki export, `grep` for reachability) sees
bracketed text where a link should be. That is how two generated pages ended up with no
inbound link at all and nobody noticed: the my-first link census of the bundle reported them
as orphans because their only inbound edges were wikilinks.

Mechanical conversion, 52 links across 17 pages, each resolved against the same page set
`kb-lint` uses: an explicit `|Label` is kept verbatim, an unlabelled link takes the target's
frontmatter `title`. Targets are emitted bundle-absolute (`/tools/niri/tips.md`), the form
the spec recommends and the form 99 existing links in this bundle already use.

Two links were `[[index]]`, which resolves by filename to 21 pages — the ambiguity that
filename-resolution invites. Both meant their own directory's index, so both are now written
out in full: `/tools/gitea/index.md`, `/tools/niri/index.md`.

The linter still tolerates wikilinks; whether it should reject them outright is an open
question on #64, because that would replace the two tests pinning today's tolerance.

Refs #64
2026-10-21 02:11:56 -07:00

2.6 KiB

type, title, description, tags, verified
type title description tags verified
reference Gitea Data Persistence Gitea data persistence, volume mounts, ownership, and backup strategy on dankclaw (Containers/gitea layout).
gitea
data
2026-10-18

Gitea Data Persistence

All data lives on host bind mounts under /home/dank/Containers/gitea/ (fleet storage standard since 2026-09-01; quadlet units re-pointed from the old /opt/gitea/data/ tree, which lingers on disk as a leftover — never write to it). Containers are ephemeral. Quadlet stops remove the container (podman run --rm --replace). The next start recreates it. Data survives.

Volume Layout

Host Path Container Mount Contents
/home/dank/Containers/gitea/data/ /data (gitea-server) Git repositories, avatars, attachments, LFS objects, app.ini
/home/dank/Containers/gitea/postgres/ /var/lib/postgresql/data (gitea-postgres) PostgreSQL WAL, tables, indexes

Ownership

The bind-mount directories are owned by host user dank (UID 1000). Files that the containers create are owned by host UID/GID 100999 — the rootless ID mapping of container uid/gid 1000 (dank subuid range 100000-165535). User dank cannot write those files directly from the host.

Edit container-owned files inside the container:

podman exec --user 1000 gitea-server sed -i 's/old/new/' /data/gitea/conf/app.ini

Backup Strategy

Tar the entire data directory. This captures Gitea repos and PostgreSQL data in one archive.

tar czf gitea-backup-$(date +%F).tar.gz -C /home/dank/Containers/gitea data/ postgres/

PostgreSQL-only backup

Use pg_dump for a portable SQL dump. Useful for restoring to a different PostgreSQL version.

podman exec -e PGPASSWORD="$GITEA_DB_PASSWORD" gitea-postgres pg_dump -U gitea gitea > gitea-db-$(date +%F).sql

Set PGPASSWORD from /home/dank/Containers/gitea/env (mode 0600, GITEA_DB_PASSWORD).

Restore procedure

  1. Stop the stack: systemctl --user stop gitea-server gitea-postgres
  2. Restore data: tar xzf backup.tar.gz -C /home/dank/Containers/gitea/
  3. Start the stack: systemctl --user start gitea-postgres gitea-server

Data Growth

  • Git repositories grow with each commit and push. Monitor with du -sh /home/dank/Containers/gitea/data/git/repositories/.
  • PostgreSQL WAL files accumulate. VACUUM via podman exec gitea-postgres psql -U gitea -c "VACUUM;".
  • Gitea's log files grow with usage.

See Also

  • ](index.md) — index with management commands
  • management — operations and boot persistence
  • architecture — network and ports