homelab-infra/ops/restore-tests/gitea-plan.md

Gitea Restore Test Plan

Ziel

Nachweisen, dass ein Gitea-Backup in einer isolierten Testumgebung wieder startbar ist und sowohl Web-UI als auch SSH-Port wieder verfuegbar sind.

Quelle

• Backup-Quelle: Borg / Share-Backup
• fachlich relevanter Datenpfad: /mnt/user/services/gitea/data
• keine separaten Secret-Dateien dokumentiert

Test-Ziel

• Restore-Lab: /mnt/user/backups/restore-lab/gitea
• Testdatenpfad: /mnt/user/backups/restore-lab/gitea/data
• Testcontainer: restoretest-gitea
• Testports:
  • Web: 127.0.0.1:13000:3000
  • SSH: 127.0.0.1:12222:22
• Report-Ziel: /mnt/user/backups/restore-reports/gitea-YYYY-MM-DD.md

Schutzregeln

• produktiven Pfad /mnt/user/services/gitea/data nie beschreiben
• produktive Domain git.kaleschke.info nicht fuer die Testinstanz uebernehmen
• produktiven SSH-Port 222 nicht fuer die Testinstanz uebernehmen
• keine Traefik-Labels fuer die Testinstanz
• Testcontainer nur gegen Restore-Lab-Daten starten

Geplanter Ablauf

1. Restore-Ziel unter /mnt/user/backups/restore-lab/gitea vorbereiten
2. Gitea-Daten aus Backup in restore-lab/gitea/data wiederherstellen
3. Testinstanz mit ops/restore-tests/gitea-compose.test.yml starten
4. lokalen Smoke-Test gegen http://127.0.0.1:13000 und 127.0.0.1:12222 ausfuehren
5. Report unter /mnt/user/backups/restore-reports/ schreiben
6. Testcontainer stoppen und Testumgebung bereinigen oder bewusst stehen lassen

Smoke-Test

Minimal erfolgreich:

• Container startet
• Web-UI antwortet
• mindestens ein bestehendes Repository-Verzeichnis ist im Restore-Lab sichtbar
• SSH-Port reagiert auf Verbindungsaufbau

Optional spaeter:

• Login-Seite gezielt pruefen
• SQLite-Datei gitea.db oder Nachfolger explizit bestaetigen
• gitea doctor oder interner Healthcheck als Zusatz

Noch offen vor dem ersten echten Lauf

• exakter Borg-Restore-Befehl bzw. Restore-Quelle auf dem Host
• Bereinigungsstrategie fuer alte Restore-Lab-Daten
• ob Reports spaeter zusaetzlich per ntfy referenziert werden