Files
gitea/docs/backup-restore.md
T

1.9 KiB

Backup, restore, aggiornamenti

Cosa salvare

Tutto lo stato è in ./gitea-data (repo, SQLite, app.ini con SECRET_KEY, chiavi host SSH) e ./caddy/data (certificati TLS, riemettibili). Nessuno dei due è versionato.

Metodo semplice (consigliato per SQLite)

docker compose stop gitea
tar czf gitea-backup-$(date +%F).tgz gitea-data
docker compose start gitea

Conservare il backup fuori dall'host e insieme a app.ini (senza SECRET_KEY i dati cifrati/2FA sono persi).

gitea dump

Richiede Gitea fermo per consistenza. In Docker (RUN_USER=git in app.ini):

docker exec -u git -w /tmp gitea /usr/local/bin/gitea dump -c /data/gitea/conf/app.ini
docker cp gitea:/tmp/gitea-dump-*.zip .

Lo zip contiene app.ini, custom/, data/, repos/, gitea-db.sql, log/ (non necessario). Opzioni: --file, --tempdir, --type, --database, --skip-repository, --skip-log, ecc. Per MySQL/Postgres preferire mysqldump/pg_dump.

Restore (manuale, non esiste comando)

  1. Estrarre lo zip.
  2. data/* → /data/gitea, repos/* → /data/git/repositories, app.ini → /data/gitea/conf/.
  3. Importare gitea-db.sql (con SQLite basta ripristinare gitea.db).
  4. chown -R git:git /data (nel container).
  5. gitea admin regenerate hooks; se problemi gitea doctor check --all --fix.

Aggiornamento

# 1) backup  2) poi:
docker compose pull
docker compose up -d

L'immagine è gitea/gitea:latest: per aggiornamenti controllati fissare un tag (es. gitea/gitea:1.x) e leggere le note di rilascio. Le migrazioni DB partono in automatico (AUTO_MIGRATION) e non sono reversibili: il backup pre-update è l'unico rollback.

Cambio tipo di database

gitea dump --database postgres genera SQL nel formato di destinazione; poco testato, scegliere il DB giusto dall'inizio. Prima: gitea doctor check --all --fix e doctor recreate-table.