109 lines
2.1 KiB
Markdown
109 lines
2.1 KiB
Markdown
# Rollback Guide — Homelab
|
|
|
|
Dieses Dokument beschreibt, wie Änderungen rückgängig gemacht werden können.
|
|
|
|
---
|
|
|
|
## Grundprinzip
|
|
|
|
Jede Änderung muss rückrollbar sein.
|
|
|
|
---
|
|
|
|
## Standard-Rollback (Git)
|
|
|
|
### Letzten Stand anzeigen
|
|
```bash
|
|
git log --oneline
|
|
```
|
|
|
|
### Auf vorherigen Stand zurücksetzen
|
|
```bash
|
|
git reset --hard <commit-id>
|
|
git push --force
|
|
```
|
|
|
|
---
|
|
|
|
## Rollback über Komodo (primär)
|
|
|
|
1. Stack in Komodo öffnen
|
|
2. „Redeploy" auswählen
|
|
3. vorherigen Commit im Gitea-Repo referenzieren
|
|
4. Deploy ausführen
|
|
|
|
---
|
|
|
|
## Rollback über Portainer (Legacy)
|
|
|
|
> ⚠️ Portainer CE ist in Ablösung durch Komodo (Sprint 5). Bis zur Abschaltung weiterhin nutzbar.
|
|
|
|
1. Stack öffnen
|
|
2. „Redeploy" auswählen
|
|
3. vorherigen Commit verwenden (bei Git-Stacks)
|
|
|
|
---
|
|
|
|
## Container-Rollback
|
|
|
|
Wenn ein neuer Stack Probleme macht:
|
|
|
|
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
|
|
|
|
---
|
|
|
|
## Datenbank-Rollback
|
|
|
|
### Backup vorhanden (empfohlen über backrest)
|
|
Restore durchführen
|
|
|
|
### 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
|
|
|
|
- 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.
|