homelab-infra/docs/ROLLBACK.md

Rollback Guide - Homelab

Dieses Dokument beschreibt den sicheren Rueckweg im aktuellen GitOps-Betrieb.

---

Grundprinzip

Rollback bedeutet in diesem Setup:

• auf einen bekannten funktionierenden Git-Stand zurueckgehen
• den Zustand sauber nach Gitea bringen
• Komodo gezielt auf diesen Stand deployen lassen

master wird dabei nicht per push --force umgeschrieben, solange es keinen ausdruecklich abgestimmten Ausnahmefall gibt.

---

Standard-Rollback ueber Git

Bevorzugter Weg:

1. den letzten funktionierenden Commit identifizieren
2. lokal einen sauberen Ruecknahme-Commit erzeugen (git revert oder gezielte Rueckaenderung)
3. nach Gitea pushen
4. Komodo-Deploy und Funktion pruefen

Warum so:

• die Historie bleibt nachvollziehbar
• Webhooks und Team-Workflow bleiben stabil
• es gibt keinen verdeckten History-Rewrite auf master

---

Rollback ueber Komodo

Komodo ist der operative Deploy-Consumer, nicht die Quelle der Wahrheit.

Vorgehen:

1. Git-Stand in Gitea auf den gewuenschten Sollzustand bringen
2. betroffenen Stack in Komodo oeffnen
3. Redeploy auf Basis dieses Git-Stands ausloesen
4. Logs, Health und Erreichbarkeit pruefen

Wichtig:

• kein manuelles Ueberschreiben im Komodo-Web-Editor
• wenn Komodo und Git abweichen, gewinnt Git

---

Ausnahmefall: harter Git-Rollback

Ein git reset --hard mit anschliessendem erzwungenem Push auf master ist kein Standardverfahren.

Das kommt nur in Frage, wenn:

• der Fall bewusst abgestimmt ist
• klar ist, welche Webhook-/Deploy-Seiteneffekte ausgeloest werden
• keine sauberere Ruecknahme ueber git revert mehr sinnvoll ist

---

Borg / Backup-bezogener Rollback

Bei Problemen mit Borg UI oder Dump-Automatisierung:

1. auf den letzten funktionierenden Git-Stand zurueckgehen
2. borg-ui ueber Komodo redeployen
3. Persistenz unter /mnt/user/appdata/borg-ui/ und /mnt/user/backups/borg/dumps/ nicht blind loeschen
4. Restore zuerst in einen Testpfad schreiben, nicht direkt in Produktivpfade

---

Daten-Rollback

Bevorzugte Quellen:

• Borg-Restore
• erzeugte PostgreSQL-/MariaDB-Dumps
• bekannte Appdata-Snapshots

Beispiele:

cp -r /mnt/user/appdata/<service> /mnt/user/backup/

pg_dumpall > /mnt/user/backup/pg_dump_$(date +%Y%m%d).sql

---

Betriebsregeln

• immer nur eine aenderungsrelevante Massnahme gleichzeitig
• vor jedem Rollback pruefen, ob ein aktuelles Backup existiert
• nach jedem Rollback Funktion, Logs und Erreichbarkeit pruefen
• wenn etwas unklar ist: stoppen, Zustand analysieren, dann gezielt eingreifen