updates
Repo sauber machen
This commit is contained in:
+61
-67
@@ -1,108 +1,102 @@
|
||||
# Rollback Guide — Homelab
|
||||
# Rollback Guide - Homelab
|
||||
|
||||
Dieses Dokument beschreibt, wie Änderungen rückgängig gemacht werden können.
|
||||
Dieses Dokument beschreibt den sicheren Rueckweg im aktuellen GitOps-Betrieb.
|
||||
|
||||
---
|
||||
|
||||
## Grundprinzip
|
||||
|
||||
Jede Änderung muss rückrollbar sein.
|
||||
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 (Git)
|
||||
## Standard-Rollback ueber Git
|
||||
|
||||
### Letzten Stand anzeigen
|
||||
```bash
|
||||
git log --oneline
|
||||
```
|
||||
Bevorzugter Weg:
|
||||
|
||||
### Auf vorherigen Stand zurücksetzen
|
||||
```bash
|
||||
git reset --hard <commit-id>
|
||||
git push --force
|
||||
```
|
||||
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 über Komodo (primär)
|
||||
## Rollback ueber Komodo
|
||||
|
||||
1. Stack in Komodo öffnen
|
||||
2. „Redeploy" auswählen
|
||||
3. vorherigen Commit im Gitea-Repo referenzieren
|
||||
4. Deploy ausführen
|
||||
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
|
||||
|
||||
---
|
||||
|
||||
## Rollback über Portainer (Legacy)
|
||||
## Ausnahmefall: harter Git-Rollback
|
||||
|
||||
> ⚠️ Portainer CE ist in Ablösung durch Komodo (Sprint 5). Bis zur Abschaltung weiterhin nutzbar.
|
||||
Ein `git reset --hard` mit anschliessendem erzwungenem Push auf `master` ist **kein Standardverfahren**.
|
||||
|
||||
1. Stack öffnen
|
||||
2. „Redeploy" auswählen
|
||||
3. vorherigen Commit verwenden (bei Git-Stacks)
|
||||
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
|
||||
|
||||
---
|
||||
|
||||
## Container-Rollback
|
||||
## Borg / Backup-bezogener Rollback
|
||||
|
||||
Wenn ein neuer Stack Probleme macht:
|
||||
Bei Problemen mit Borg UI oder Dump-Automatisierung:
|
||||
|
||||
1. neuen Container stoppen
|
||||
2. alten Container wieder starten
|
||||
3. Logs prüfen
|
||||
|
||||
### Borg UI / BorgBase
|
||||
|
||||
Bei Problemen mit `ops/borg-ui/docker-compose.yml`:
|
||||
|
||||
1. in Gitea auf den letzten funktionierenden Commit zurückgehen
|
||||
2. Stack in Komodo auf diesen Commit redeployen
|
||||
3. Persistenz unter `/mnt/user/appdata/borg-ui/` unverändert lassen
|
||||
4. BorgBase-Repository nicht löschen; Remote-Archive bleiben davon unberührt
|
||||
5. falls nötig, Restore zunächst aus `/mnt/user/appdata/borg-ui/restore/` testen statt direkt in Produktivpfade zurückzuschreiben
|
||||
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
|
||||
|
||||
---
|
||||
|
||||
## Datenbank-Rollback
|
||||
## Daten-Rollback
|
||||
|
||||
### Backup vorhanden (empfohlen über backrest)
|
||||
Restore durchführen
|
||||
Bevorzugte Quellen:
|
||||
|
||||
- Borg-Restore
|
||||
- erzeugte PostgreSQL-/MariaDB-Dumps
|
||||
- bekannte Appdata-Snapshots
|
||||
|
||||
Beispiele:
|
||||
|
||||
### Manuelle Sicherung
|
||||
```bash
|
||||
cp -r /mnt/user/appdata/<service> /mnt/user/backup/
|
||||
```
|
||||
|
||||
### PostgreSQL-Dump
|
||||
```bash
|
||||
pg_dumpall > /mnt/user/backup/pg_dump_$(date +%Y%m%d).sql
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Best Practices
|
||||
## Betriebsregeln
|
||||
|
||||
- Immer nur **eine Änderung gleichzeitig**
|
||||
- Vor jeder Änderung prüfen:
|
||||
- läuft Backup?
|
||||
- ist der aktuelle Zustand stabil?
|
||||
- Nach jeder Änderung:
|
||||
- Funktion testen
|
||||
- Logs prüfen
|
||||
- Migration im `MIGRATION_LOG.md` dokumentieren
|
||||
|
||||
---
|
||||
|
||||
## Notfallregel
|
||||
|
||||
Wenn etwas unklar ist:
|
||||
- NICHT weiter ändern
|
||||
- aktuellen Zustand analysieren
|
||||
- gezielt und kontrolliert eingreifen
|
||||
|
||||
---
|
||||
|
||||
## Ziel
|
||||
|
||||
Rollback muss jederzeit möglich sein, ohne Datenverlust und ohne unnötige Downtime.
|
||||
- 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
|
||||
|
||||
Reference in New Issue
Block a user