Die App gibt 500 zurück. SSH funktioniert weiterhin. „df -h“ zeigt 100 % auf „/“. Der Reflex: rm -rf /var/log/*.log. Das macht 200 MB frei – dann ist die Festplatte in zwei Stunden voll, weil niemand gesehen hat, dass MySQL-Binlog- oder Docker-Protokolle 40 GB verschlungen haben.
Eine volle Festplatte ist ein Symptom, keine Diagnose.
Schnelles Lesen df/du
„df -hT“: Dateisystemtyp, Inodes („df -i“). du -xh / --max- Depth=1 am Einhängepunkt.
Vergleichen Sie df mit total – Lücke = gelöschte offene Dateien oder versteckter Mount.
Häufige Schuldige
| Quelle | Wo zu sehen |
|---|---|
| Journald | journalctl --disk-usage |
| Docker | Docker-System df -v |
| MySQL-Binlog | /var/lib/mysql |
| Applogs | /var/log, storage/logs |
| Kerne | /var/crash, Core-Dumps |
| Lokale Backups | /backup, /tmp |
Zeitleiste: „find /var -mtime -1 -size +100M“.
Gelöscht, aber geöffnet
lsof +L1 | grep delete – klassisch nach fehlgeschlagener Rotation oder großem Protokoll, das ohne HUP gelöscht wurde.
Fix: App neu laden, php-fpm/mysql neu starten, nicht nur rm.
Sofortmaßnahmen angeordnet
- Identifizieren Sie die drei wichtigsten Dateien.
- Journal löschen, wenn > 500 MB.
- Bekanntes Protokoll abschneiden (copytruncate) statt löschen.
- Docker Plum nach Volumes auflisten.
- Erweitern Sie das Wolkenvolumen nach Möglichkeit vor der Operation.
Nachhaltige Prävention
Überwachung von Inode + Speicherplatz. Logrotate getestet. SystemMaxUse= journald. Docker „--log-opt max-size=10m“. Warnungs-Runbook, das mit der richtigen Bereitstellung verknüpft ist.
Runbook 15 Minuten
Minute 0–3: „df -hT“ + „df -i“ + „du -xh / --max- Depth=1“.
Minute 3–6: „journalctl --disk-usage“, ggf. „docker system df“.
Minute 6–9: lsof +L1 | head wenn df/du-Lücke.
Minute 9–12: gezielte Aktion (Vakuumieren, Log Roté abschneiden, aufgelistete Docker-Volumes beschneiden).
Minute 12–15: „df“-Verifizierung + Überwachungsbestätigungswarnung + Root-Cause-Ticket.
Verboten: rm -rf ohne identifizierte Top-3-Verzeichnisse. Obligatorisch: Obduktion, wenn die Produktauswirkung mehr als 80 % beträgt.
Typische Obduktion
Zeitleiste: Warnung 80 % ignoriert → 95 % → 100 % → Ausfall. Grundursache: Anwendungs-Debug-Protokoll wurde am Freitag ohne Rotation aktiviert. Aktion: Protokollebene Produkt + Warnung 85 % + Runbook.
Kapazität: prognostizierte Wachstumsprotokolle MB/Tag × Aufbewahrung.
Cloud-Autoscale-Festplatte, falls verfügbar – Skript zum Vergrößern des Dateisystems nach der Größenänderung.
Automatische tägliche Cloud-Snapshots ohne Lebenszyklus: Akkumulation von Snapshots = übergeordnete Festplatte indirekt voll – Überprüfung der Richtlinien-Snapshots.
Mail-Postfix-/Exim-Warteschlange blockiert, Festplatte voll: riesiger Rückstand zur Wiederherstellung – überwachen Sie die Warteschlangenlängenmetrik.
Vorhersehbares Wachstum
Zugriffsprotokolle x10 während der Aktion: stündliche, temporäre Vorbereitstellungsrotation oder Festplatten-Upgrade vor der Kampagne.
MySQL-Binlog-Ablauf: „expire_logs_days“ oder max_binlog_size – Binlog vergessen = volle Festplatte garantiert unter schreiblastig.
ZFS/btrfs-Snapshots zählen den Speicherplatz – erstellen Sie keinen Snapshot einer bereits vollen Festplatte in einer Schleife.
Betriebszusammenfassung
Mit 80/90-Warnungen, getesteter Protokollrotation und Verbraucherwissen (Journal, Docker, Binlog, lokale Backups) ist die volle Festplatte in der Linux-Produktion fast immer vorhersehbar. Im Notfall: Diagnose mit df, du, lsof vor rm.
Cloud: Bei legitimem Wachstum ist die Erweiterung des Volumens sicherer als die blinde Bereinigung. Obligatorische Post-Mortem-Analyse bei Auswirkungen auf den Kunden – häufig vergessenes Debug-Protokoll aktiviert.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Obduktion
Debug-Protokoll Freitag ohne Rotation. Der kurzlebige Speicher von K8 tötet Pods, bevor der Knoten voll ist.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Führen Sie ein datiertes Runbook, Vorher-/Nachher-Kennzahlen und eine Überprüfung nach dem Vorfall – kumulative Disziplin vermeidet Panik am Freitagabend.
Entscheide dich und gehe ohne blinden Fleck voran
- Runbook 15 Minuten – „df -hT“, „df -i“, „du“ oberste Ebene, journalctl --disk-usage, Docker-System-DF.
- Suche nach geöffneten gelöschten Dateien – „lsof +L1“ bei Differenz df/du.
- Gezielte Aktion – Protokoll saugen, Protokolldaten abschneiden, aufgelistete Docker-Volumes bereinigen; niemals rm -rf ohne Top-3-Verzeichnisse.
- Warnung zum Derivat – GB/Tag-Wachstum, nicht nur 90 %-Schwelle.
- Postmortem bei Produktauswirkung – Grundursache in derselben Woche dokumentiert.
Überwachen Sie Festplatte und Inode auf VPS über den Komparator und das Verzeichnis.
Häufig gestellte Fragen
df sagt 100 %, kann aber nichts finden?
Gelöschte Dateien sind noch von einem Prozess geöffnet (gelöscht, aber geöffnet). lsof +L1 oder starten Sie den betreffenden Dienst neu.
Was ist im Notfall zuerst zu entleeren?
journalctl --vacuum, alte verrottete Protokolle, /tmp – niemals /var/lib ohne Identifizierung (DB, Docker).
Docker füllt oft wo?
/var/lib/docker/overlay2, JSON-Dateiprotokolle nicht begrenzt, verwaiste Volumes.
Wie kann man vorbeugen?
80/90 % Warnungen, Logrotate, Journald-Limit, Docker-Log wählt maximale Größe.
Nächste 100 %-Festplatte: Führen Sie „du“ und „lsof +L1“ vor jedem rm aus – Ihre Zukunft wird es Ihnen danken.