Files

T

Micha 513f41b852 docs: introduce DECISIONS.md decision register, slim architecture master

- new docs/DECISIONS.md (ADR-light): decisions migrated from master
  section 13, MASTER_TODO parked items, hardware inventory and audit
  restliste into one chronological register
- HOMELAB_ARCHITECTURE_MASTER_V2.md: section 13 replaced by pointer,
  section 9 condensed (502 -> 372 lines, target picture only)
- ROLLBACK.md: drop rollback recipes for already removed services
  (uptime-kuma, grafana/influx legacy, stirling/glance bootstrap notes)

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

2026-06-11 07:06:18 +02:00

3.3 KiB

Raw Blame History

Rollback Guide - Homelab

Typ: Runbook · Stand: 2026-06-11 · Status: aktiv

Dieses Dokument beschreibt den sicheren Rueckweg im aktuellen GitOps-Betrieb. Rollback-Anleitungen fuer bereits entfernte Dienste (Uptime-Kuma, Grafana-/ InfluxDB-Altstack, Stirling-PDF) liegen in der Git-Historie, nicht mehr hier.

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:

den letzten funktionierenden Commit identifizieren
lokal einen sauberen Ruecknahme-Commit erzeugen (git revert oder gezielte Rueckaenderung)
nach Gitea pushen
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:

Git-Stand in Gitea auf den gewuenschten Sollzustand bringen
betroffenen Stack in Komodo oeffnen
Redeploy auf Basis dieses Git-Stands ausloesen
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:

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

Monitoring-Stack Rollback

monitoring/ ist der einzige Observability-Stack. Bei Problemen:

monitoring in Komodo stoppen oder auf den letzten funktionierenden Commit zurueckgehen
named volumes prometheus_data, loki_data, promtail_positions, grafana_data sowie /mnt/user/appdata/influxdb3 nicht blind loeschen
Secrets (monitoring_grafana_admin_password.txt, monitoring_grafana_influxdb_token.txt, influxdb3_admin_token.json) nur nach bewusstem Entscheid entfernen
Grafana-Datasources Prometheus, Loki und InfluxDB 3 Core testen

Daten-Rollback

Bevorzugte Quellen:

Borg-Restore (zuerst in Testpfade unter /mnt/user/backups/restore-lab/)
erzeugte Dumps unter /mnt/user/backups/borg/dumps/latest
bekannte Appdata-Archivstaende unter /mnt/user/appdata/_archive/

Dienst-spezifische Restore-Quellen, Dumps und Smoke-Tests stehen in docs/RESTORE_MATRIX.md.

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

3.3 KiB Raw Blame History