feat: periodic Forgejo backup to protect issue tracker data #9

New issue

Open

opened 2026-03-28 10:37:28 +00:00 by dev-bot · 0 comments

dev-bot commented

2026-03-28 10:37:28 +00:00

Collaborator

Problem

The Forgejo instance runs inside a Docker volume (disinto_forgejo-data). If the containers or volumes are destroyed, all issues, PRs, review comments, and project history are lost. Git repo data survives on mirrors (Codeberg, GitHub), but the issue tracker does not.

Design

Add a periodic forgejo dump to export the Forgejo database (issues, users, PRs, comments, labels) to a compressed archive. Store the backup in the ops repo or a dedicated backup location.

Considerations

forgejo dump produces a zip with the database, repos, and config
Only the database portion is critical (repos are mirrored elsewhere)
Could run as a cron job inside the agents container, or as a supervisor health check
Backup destination options: ops repo, host filesystem, or object storage
Retention policy: keep N most recent dumps

Why not mirror issues to external forges?

The factory uses a single internal Forgejo API regardless of where mirrors go (Codeberg, GitHub, or both). Keeping one API surface is simpler than adapting to multiple external forge APIs.

## Problem The Forgejo instance runs inside a Docker volume (`disinto_forgejo-data`). If the containers or volumes are destroyed, all issues, PRs, review comments, and project history are lost. Git repo data survives on mirrors (Codeberg, GitHub), but the issue tracker does not. ## Design Add a periodic `forgejo dump` to export the Forgejo database (issues, users, PRs, comments, labels) to a compressed archive. Store the backup in the ops repo or a dedicated backup location. ### Considerations - `forgejo dump` produces a zip with the database, repos, and config - Only the database portion is critical (repos are mirrored elsewhere) - Could run as a cron job inside the agents container, or as a supervisor health check - Backup destination options: ops repo, host filesystem, or object storage - Retention policy: keep N most recent dumps ## Why not mirror issues to external forges? The factory uses a single internal Forgejo API regardless of where mirrors go (Codeberg, GitHub, or both). Keeping one API surface is simpler than adapting to multiple external forge APIs.