Prod-Platte lief bei 100 % voll und legte die Seite lahm — Aufräumen automatisieren #85

New issue

Closed

opened 2026-09-06 23:08:37 +00:00 by Phil · 0 comments

Phil commented

2026-09-06 23:08:37 +00:00

Owner

Beim Deploy in der Nacht auf den 07.09.2026 passiert, mit vollem Ausfall der Live-Seite.

Was passiert ist

Drei Image-Rebuilds hintereinander (Blitz-Install, dann zwei Fixes) haben die Platte von 85 % auf 100 % gefüllt — null Bytes frei.

Folge: Redis konnte seinen RDB-Snapshot nicht mehr schreiben und schaltete daraufhin alle Schreibbefehle ab (stop-writes-on-bgsave-error, Standardverhalten):

MISCONF Redis is configured to save RDB snapshots, but it's currently
unable to persist to disk. Commands that may modify the data set are disabled.

Craft nutzt Redis als Cache-Backend. Jeder Request scheiterte damit schon beim Laden der Site-Konfiguration — HTTP 500 auf allen Seiten, auch die Craft-CLI war tot. Der Fehler sah im Log wie ein Datenbankproblem aus (Sites->_loadAllSites()), war aber Redis.

Behoben

docker builder prune -f gab 4,58 GB frei, danach schrieb Redis wieder, Caches neu aufgebaut, Seite wieder online. Stand jetzt: 67 GB von 75 GB belegt, 5,3 GB frei (93 %).

Das ist immer noch eng. docker system df meldet 41,77 GB Images, davon 29,47 GB nicht verwendet. docker image prune -f griff nicht, weil die alten Images getaggt sind — es bräuchte -a, und das muss geprüft werden, weil auf dem Host 26 Container aus mehreren Projekten laufen (Philflow, Matomo, weitere).

Warum es wieder passieren wird

Jeder Deploy baut ein neues Image. Ohne Aufräumen wächst der Bestand mit jedem Durchgang, und 5,3 GB reichen für etwa zwei weitere Deploys.

Was zu tun ist

Klären, welche der 29 GB ungenutzten Images gefahrlos weg können (mehrere Projekte auf dem Host)
Aufräumen in den Deploy-Ablauf aufnehmen: docker builder prune -f und ein abgesichertes Image-Prune nach jedem erfolgreichen Deploy
Plattenplatz vor dem Deploy prüfen und abbrechen, wenn unter einem Schwellwert — der Ablauf in docs/DEPLOYMENT.md beginnt heute mit einem DB-Backup, das bei voller Platte selbst fehlschlägt
Überwachung: Alarm ab 85 % belegt, damit das nicht erst beim Ausfall auffällt
Prüfen, ob Redis auf dieser Instanz überhaupt persistieren muss — es ist ein reiner Cache. Mit abgeschalteter RDB-Persistenz hätte eine volle Platte die Seite nicht lahmgelegt. Das ist die eigentliche Härtung.

Der letzte Punkt ist der wichtigste: dass ein volllaufender Datenträger einen Cache dazu bringt, die gesamte Anwendung stillzulegen, ist die eigentliche Schwachstelle. Ein Cache darf ausfallen, ohne die Seite mitzunehmen.

Beim Deploy in der Nacht auf den 07.09.2026 passiert, mit vollem Ausfall der Live-Seite. ## Was passiert ist Drei Image-Rebuilds hintereinander (Blitz-Install, dann zwei Fixes) haben die Platte von 85 % auf **100 %** gefüllt — null Bytes frei. Folge: Redis konnte seinen RDB-Snapshot nicht mehr schreiben und schaltete daraufhin **alle Schreibbefehle ab** (`stop-writes-on-bgsave-error`, Standardverhalten): ``` MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist to disk. Commands that may modify the data set are disabled. ``` Craft nutzt Redis als Cache-Backend. Jeder Request scheiterte damit schon beim Laden der Site-Konfiguration — **HTTP 500 auf allen Seiten**, auch die Craft-CLI war tot. Der Fehler sah im Log wie ein Datenbankproblem aus (`Sites->_loadAllSites()`), war aber Redis. ## Behoben `docker builder prune -f` gab 4,58 GB frei, danach schrieb Redis wieder, Caches neu aufgebaut, Seite wieder online. Stand jetzt: 67 GB von 75 GB belegt, **5,3 GB frei (93 %)**. Das ist immer noch eng. `docker system df` meldet 41,77 GB Images, davon **29,47 GB nicht verwendet**. `docker image prune -f` griff nicht, weil die alten Images getaggt sind — es bräuchte `-a`, und das muss geprüft werden, weil auf dem Host 26 Container aus mehreren Projekten laufen (Philflow, Matomo, weitere). ## Warum es wieder passieren wird Jeder Deploy baut ein neues Image. Ohne Aufräumen wächst der Bestand mit jedem Durchgang, und 5,3 GB reichen für etwa zwei weitere Deploys. ## Was zu tun ist - [ ] Klären, welche der 29 GB ungenutzten Images gefahrlos weg können (mehrere Projekte auf dem Host) - [ ] Aufräumen in den Deploy-Ablauf aufnehmen: `docker builder prune -f` und ein abgesichertes Image-Prune nach jedem erfolgreichen Deploy - [ ] Plattenplatz **vor** dem Deploy prüfen und abbrechen, wenn unter einem Schwellwert — der Ablauf in `docs/DEPLOYMENT.md` beginnt heute mit einem DB-Backup, das bei voller Platte selbst fehlschlägt - [ ] Überwachung: Alarm ab 85 % belegt, damit das nicht erst beim Ausfall auffällt - [ ] Prüfen, ob Redis auf dieser Instanz überhaupt persistieren muss — es ist ein reiner Cache. Mit abgeschalteter RDB-Persistenz hätte eine volle Platte die Seite nicht lahmgelegt. Das ist die eigentliche Härtung. Der letzte Punkt ist der wichtigste: dass ein volllaufender Datenträger einen **Cache** dazu bringt, die gesamte Anwendung stillzulegen, ist die eigentliche Schwachstelle. Ein Cache darf ausfallen, ohne die Seite mitzunehmen.

Phil referenced this issue

2026-09-07 05:58:44 +00:00

Google indexiert nur 4 von 22 Seiten — kein einziger Blogartikel #82

Phil referenced this issue from a commit

2026-09-07 08:34:05 +00:00

fix(redis): Persistenz abschalten, damit eine volle Platte die Seite nicht killt

Phil referenced this issue from a commit

2026-09-07 08:34:05 +00:00

feat(deploy): ausfuehrbares Prod-Deploy mit Platten-Sperre und Voll-Sync

Phil referenced this issue from a commit

2026-09-07 08:34:05 +00:00

docs(deploy): neun konkurrierende Deployment-Anleitungen auf eine reduzieren