7.13 Datenträger oder Dateisystem ist voll

7.13.1 Ziel dieser Seite

Diese Seite beschreibt die systematische Diagnose, wenn ein System, Datenträger, Volume, Dateisystem, Speicherpool, Container oder eine Anwendung keinen weiteren Speicherplatz verwenden kann.

Ziele der Diagnose:

Ein gemeldetes „Dateisystem voll“ bedeutet nicht zwangsläufig, dass die physische Festplatte vollständig belegt ist.

7.13.2 Sicherheitskennzeichnungen

Kennzeichnung Bedeutung
LESEND erfasst ausschließlich Zustände und Messwerte
LASTERZEUGEND kann CPU, Arbeitsspeicher oder Datenträger-I/O deutlich belasten
ÄNDERND verändert Konfigurationen oder Systemzustände
LÖSCHEND entfernt Daten und kann Informationen unwiederbringlich zerstören
AUSFALLRISIKO kann Dienste, Dateisysteme oder ganze Systeme unterbrechen

Grundregeln:

7.13.3 Mögliche Fehlerklassen

Fehlerklasse Beschreibung Typischer Nachweis
Datenblöcke voll nutzbare Speicherkapazität ist erschöpft df, Get-Volume, diskutil info
Inodes erschöpft zu viele Dateien, obwohl noch Datenblöcke frei sind df -i
Benutzer- oder Gruppenquota erreicht einzelner Benutzer oder Dienst darf nichts mehr speichern quota, FSRM, Dateisystemquota
Projekt- oder Verzeichnisquota erreicht bestimmter Pfad besitzt ein eigenes Limit XFS-Projektquota, FSRM
Anwendungsquota erreicht Anwendung begrenzt Speicher unabhängig vom Dateisystem Anwendungskonfiguration und Protokolle
Snapshot-Speicher voll Snapshots oder Shadow Copies belegen den freien Bereich VSS-, APFS-, Btrfs- oder ZFS-Auswertung
Thin Pool voll zugrunde liegender Thin-Provisioning-Pool besitzt keinen freien Platz LVM-, SAN- oder Hypervisoranzeige
Thin-Pool-Metadaten voll Verwaltungsbereich des Thin Pools ist erschöpft lvs mit metadata_percent
Container-Layer voll beschreibbare Container-Schicht oder Containerhost ist voll Docker- oder Runtime-Auswertung
Kubernetes-Ephemeralspeicher voll Node oder Pod überschreitet Ephemeral-Storage-Grenzen DiskPressure, Eviction-Ereignisse
Dateisystem schreibgeschützt Dateisystem wurde wegen Fehlern nur lesbar eingebunden Mountoptionen, Kernel- und Systemprotokolle
Physischer Datenträgerfehler Schreibvorgänge scheitern durch Hardware- oder I/O-Fehler SMART, Ereignisse, Kernelmeldungen
Gelöschte Datei noch geöffnet Verzeichniseintrag ist gelöscht, Prozess hält Datei weiterhin geöffnet lsof +L1
Reservierter Speicher freier Bereich steht normalen Benutzern nicht zur Verfügung Dateisystem- und Reservierungsdaten
Versteckte Daten unter Mountpoint Dateien liegen unterhalb eines später darüber eingebundenen Dateisystems Mountstruktur und Wartungsprüfung
Kapazität des Backends voll lokaler Client zeigt nur einen vorgelagerten NAS-, SAN- oder Cloudspeicher Backend-, Pool- und Quotaauswertung

7.13.4 Typische Symptome und Fehlermeldungen

Mögliche Symptome:

Typische Meldungen:

No space left on device
ENOSPC
Disk full
There is not enough space on the disk
Not enough disk space
Quota exceeded
EDQUOT
Read-only file system
EROFS
I/O error
DiskPressure
Evicted
ephemeral-storage
Thin pool is full
Metadata space exhausted

No space left on device kann sowohl auf erschöpfte Datenblöcke als auch auf erschöpfte Inodes oder interne Dateisystemreserven hinweisen.

Quota exceeded betrifft dagegen gewöhnlich ein festgelegtes Speicherlimit und nicht zwingend das gesamte Dateisystem.

7.13.5 Sofortmaßnahmen ohne unkontrolliertes Löschen

  1. Exakte Fehlermeldung und Uhrzeit erfassen.
  2. Betroffenen Host, Dienst, Benutzer, Container und Pfad bestimmen.
  3. Kritikalität und Auswirkung bewerten.
  4. Aktuelle Kapazität, Inodes, Quotas und Speicherpools dokumentieren.
  5. Schreibintensive Prozesse und aktuelle Wachstumsrate identifizieren.
  6. Bei akutem Wachstum eine kontrollierte Drosselung oder Beendigung des verursachenden Dienstes prüfen.
  7. Keine unnötigen Neustarts durchführen.
  8. Keine Protokolle, Datenbanken oder Container-Volumes spontan löschen.
  9. Nur eindeutig entbehrliche und freigegebene Daten kontrolliert entfernen.
  10. Nach jeder Maßnahme denselben Speichertest wiederholen.

Ein Neustart kann die Situation verschärfen, wenn ein Dienst beim Start temporären Speicher benötigt oder eine Datenbank wegen fehlenden Speicherplatzes keine Wiederherstellung durchführen kann.

7.13.6 Speicherpfad vollständig abbilden

Der sichtbare Pfad kann mehrere Speicherebenen durchlaufen:

Anwendung
→ Anwendungspfad
→ Container oder virtuelle Maschine
→ Mountpoint oder Laufwerksbuchstabe
→ Dateisystem
→ Partition oder logisches Volume
→ Thin Pool, RAID oder Storage Pool
→ physischer Datenträger, NAS oder SAN

Jede Ebene kann ein eigenes Limit besitzen.

Beispiel:

Anwendung schreibt nach /var/lib/app
→ Docker-Bind-Mount
→ /srv/containers/app
→ ext4-Dateisystem
→ LVM Logical Volume
→ LVM Thin Pool
→ RAID-Verbund
→ physische SSDs

Freier Speicher auf einer Ebene beweist nicht, dass alle anderen Ebenen ebenfalls freien Speicher besitzen.

7.13.7 Grundfragen der Diagnose

Zu klären sind:

7.13.8 Windows – Volumeauslastung erfassen

LESEND

Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    HealthStatus,
    OperationalStatus,
    @{
      Name = "SizeGiB"
      Expression = {
        [math]::Round($_.Size / 1GB, 2)
      }
    },
    @{
      Name = "FreeGiB"
      Expression = {
        [math]::Round($_.SizeRemaining / 1GB, 2)
      }
    },
    @{
      Name = "FreePercent"
      Expression = {
        if ($_.Size -gt 0) {
          [math]::Round(
            100 * $_.SizeRemaining / $_.Size,
            1
          )
        }
      }
    }

Dateisystemlaufwerke der aktuellen PowerShell-Sitzung:

Get-PSDrive `
  -PSProvider FileSystem

Lokale logische Laufwerke:

Get-CimInstance `
  -ClassName Win32_LogicalDisk `
  -Filter "DriveType=3" |
  Select-Object `
    DeviceID,
    VolumeName,
    FileSystem,
    Size,
    FreeSpace

Get-PSDrive kann auch eingebundene Dateisystemlaufwerke anzeigen. Bei Netzwerkfreigaben können Quotas oder serverseitige Einschränkungen dazu führen, dass die gemeldete Verfügbarkeit nicht der gesamten Backendkapazität entspricht.

7.13.9 Windows – Datenträger, Partition und Volume zuordnen

LESEND

Get-Disk |
  Select-Object `
    Number,
    FriendlyName,
    PartitionStyle,
    OperationalStatus,
    HealthStatus,
    Size

Get-Partition |
  Select-Object `
    DiskNumber,
    PartitionNumber,
    DriveLetter,
    Type,
    Size

Get-Partition |
  Get-Volume |
  Select-Object `
    DriveLetter,
    FileSystemLabel,
    FileSystem,
    Size,
    SizeRemaining

Von Speicherverwaltungsanbietern gemeldete physische Datenträger:

Get-PhysicalDisk |
  Select-Object `
    FriendlyName,
    MediaType,
    OperationalStatus,
    HealthStatus,
    Size

Zu beachten:

7.13.10 Windows – große Verzeichnisse und Dateien eingrenzen

Eine rekursive Suche kann auf großen Dateisystemen erhebliche I/O-Last verursachen. Der Suchpfad muss deshalb möglichst eng begrenzt werden.

LESEND, LASTERZEUGEND

Größe der direkten Unterverzeichnisse eines bekannten Pfades:

$ScanRoot = "C:\Data"

Get-ChildItem `
  -LiteralPath $ScanRoot `
  -Directory `
  -Force `
  -ErrorAction SilentlyContinue |
ForEach-Object {
  $Measurement = Get-ChildItem `
    -LiteralPath $_.FullName `
    -File `
    -Force `
    -Recurse `
    -ErrorAction SilentlyContinue |
  Measure-Object `
    -Property Length `
    -Sum

  [pscustomobject]@{
    Path = $_.FullName
    SizeGiB = [math]::Round(
      $Measurement.Sum / 1GB,
      2
    )
  }
} |
Sort-Object `
  -Property SizeGiB `
  -Descending

Größte Dateien unter einem begrenzten Pfad:

Get-ChildItem `
  -LiteralPath "C:\Data" `
  -File `
  -Force `
  -Recurse `
  -ErrorAction SilentlyContinue |
Sort-Object `
  -Property Length `
  -Descending |
Select-Object `
  -First 20 `
  FullName,
  Length,
  LastWriteTime

Einschränkungen:

7.13.11 Windows – versteckte und reservierte Speicherverbraucher prüfen

VSS und Shadow Copies

LESEND

vssadmin list shadowstorage

vssadmin list shadows

Zu prüfen sind:

Shadow Copies dürfen nicht spontan gelöscht oder verkleinert werden. Sie können für Wiederherstellungen, offene Backups oder andere Dienste benötigt werden.

Windows-Komponentenspeicher analysieren

LESEND, LASTERZEUGEND

Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore

Die im Explorer angezeigte Größe von WinSxS darf nicht durch manuelles Löschen von Dateien korrigiert werden. Hardlinks können die scheinbare Verzeichnisgröße beeinflussen.

Systemdateien und weitere Bereiche

Zu prüfen sind:

Diese Dateien dürfen nicht allein aufgrund ihrer Größe entfernt werden.

7.13.12 Windows – Quotas prüfen

NTFS-Quota

LESEND, administrative Berechtigung erforderlich

fsutil quota query C:

File Server Resource Manager

Get-FsrmQuota |
  Select-Object `
    Path,
    Size,
    Usage,
    SoftLimit,
    Status,
    Template

Das FSRM-Modul ist nur vorhanden, wenn die entsprechende Windows-Server-Rolle beziehungsweise Verwaltungsfunktion installiert ist.

Zu unterscheiden sind:

Wenn nur ein Benutzer oder ein bestimmtes Verzeichnis betroffen ist, muss zuerst die wirksame Quota geprüft werden.

7.13.13 Windows – Storageereignisse auswerten

LESEND

Get-WinEvent `
  -FilterHashtable @{
    LogName = "System"
    StartTime = (Get-Date).AddHours(-6)
  } |
Where-Object {
  $_.ProviderName -in @(
    "disk",
    "Ntfs",
    "ReFS",
    "volsnap",
    "storport"
  )
} |
Select-Object `
  TimeCreated,
  ProviderName,
  Id,
  LevelDisplayName,
  Message

Zu korrelieren sind:

Ein Volume kann gleichzeitig nahezu voll und technisch fehlerhaft sein. Die Freigabe von Speicher behebt dann nicht zwangsläufig die eigentliche Ursache.

7.13.14 Linux – Dateisystembelegung erfassen

LESEND

df -hT

Wichtige Felder:

Feld Bedeutung
Filesystem zugrunde liegendes Gerät oder logischer Speicher
Type Dateisystemtyp
Size Gesamtkapazität
Used belegter Speicher
Avail verfügbarer Speicher
Use% prozentuale Auslastung
Mounted on Mountpoint

Bestimmten Pfad prüfen:

df -hT /var/lib/app

Exakte Blockwerte:

df -B1 /var/lib/app

df wertet das Dateisystem aus, in dem der angegebene Pfad liegt. Das ist zuverlässiger, als den Mountpoint nur anhand einer angenommenen Verzeichnisstruktur zu erraten.

7.13.15 Linux – Inodes prüfen

LESEND

df -i

Bestimmten Pfad prüfen:

df -i /var/lib/app

Eine mögliche Einordnung:

Blockbelegung Inodebelegung Einordnung
hoch normal große Dateien oder große Datenmengen
normal hoch sehr viele kleine Dateien
hoch hoch Kombination aus Datenmenge und Dateianzahl
normal normal Quota, Reservierung, anderer Mountpoint oder anderer Fehler

Bei erschöpften Inodes können keine neuen Dateien angelegt werden, obwohl noch Datenblöcke frei sind.

Typische Verursacher:

7.13.16 Linux – Mounts und Speichergeräte zuordnen

LESEND

findmnt

Gezielte Ausgabe:

findmnt \
  -o TARGET,SOURCE,FSTYPE,OPTIONS

Bestimmten Pfad zuordnen:

findmnt \
  --target /var/lib/app

Blockgeräte:

lsblk \
  -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS

Zu prüfen sind:

Wenn ein vorgesehenes Dateisystem nicht eingebunden ist, kann eine Anwendung unbemerkt in das darunterliegende Root-Dateisystem schreiben.

7.13.17 Linux – große Verzeichnisse und Dateien finden

Die Suche sollte auf das betroffene Dateisystem begrenzt werden.

LESEND, LASTERZEUGEND

Direkte Unterverzeichnisse:

du \
  -x \
  -h \
  --max-depth=1 \
  /var |
sort -h

Zusammenfassung eines bestimmten Pfades:

du \
  -x \
  -s \
  -h \
  /var/lib/app

Größte Dateien mit GNU find:

find \
  /var/lib/app \
  -xdev \
  -type f \
  -printf '%s\t%p\n' |
sort -nr |
head -n 20

Wichtige Optionen:

Option Bedeutung
-x bei du bleibt im selben Dateisystem
-xdev bei find überschreitet keine Dateisystemgrenze
--max-depth=1 wertet nur die direkte Verzeichnisebene aus
-type f beschränkt die Suche auf reguläre Dateien

Die Option -printf ist eine GNU-find-Funktion und steht nicht auf jedem Unix-System zur Verfügung.

7.13.18 Unterschied zwischen df und du untersuchen

df und du messen unterschiedliche Dinge:

Wenn df eine hohe Belegung zeigt, du aber deutlich weniger Daten findet, sind insbesondere zu prüfen:

Sparse Files vergleichen:

du -h /pfad/datei

du \
  -h \
  --apparent-size \
  /pfad/datei

Die scheinbare Dateigröße kann größer als der tatsächlich belegte Speicher sein.

7.13.19 Gelöschte, aber weiterhin geöffnete Dateien prüfen

Unter Unix-ähnlichen Systemen wird der belegte Speicher einer gelöschten Datei erst freigegeben, wenn kein Prozess mehr einen offenen Dateideskriptor auf sie hält.

LESEND

sudo lsof +L1

Zu prüfen sind:

Ein Neustart des gesamten Systems ist nicht die erste Maßnahme. Wenn die Ursache bestätigt ist, sollte der betroffene Dienst kontrolliert neu geladen oder neu gestartet werden. Dabei sind Auswirkung und Wiederanlaufbedingungen zu prüfen.

7.13.20 Linux – Journald und Protokollwachstum prüfen

Aktuelle Journalbelegung:

LESEND

journalctl --disk-usage

Journaldateien und Protokollverzeichnisse:

du \
  -x \
  -h \
  --max-depth=1 \
  /var/log |
sort -h

Logrotate-Konfiguration im Debugmodus prüfen:

sudo logrotate \
  -d \
  /etc/logrotate.conf

logrotate -d führt keine Rotation aus, zeigt aber die geplante Verarbeitung.

Zu prüfen sind:

Das Löschen eines Protokolls behebt nicht den Prozess, der es unkontrolliert erzeugt.

7.13.21 Linux – Benutzer-, Gruppen- und Projektquotas prüfen

Quota des aktuellen Benutzers:

LESEND

quota -s

Quotaübersicht vorhandener quota-fähiger Dateisysteme:

sudo repquota -a

XFS-Quotaauswertung:

sudo xfs_quota \
  -x \
  -c 'report -h' \
  /mountpoint

Zu unterscheiden sind:

Eine noch laufende Grace Period kann erklären, warum Schreiben zunächst möglich war und später ohne sichtbare Änderung der Gesamtkapazität fehlschlägt.

7.13.22 LVM und Thin Provisioning prüfen

LESEND

sudo pvs

sudo vgs

sudo lvs \
  -a \
  -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent

Besonders kritisch sind:

Ein Thin Pool kann voll sein, obwohl ein Gastbetriebssystem oder Logical Volume scheinbar noch freien logischen Speicher anzeigt.

Das Erweitern eines Speichers muss in der richtigen Reihenfolge erfolgen:

Backend oder physischer Datenträger
→ Partition oder PV
→ Volume Group oder Pool
→ Logical Volume
→ Dateisystem
→ Anwendung

Nicht jede Ebene ist in jeder Architektur vorhanden.

7.13.23 Btrfs und ZFS prüfen

Btrfs

LESEND

sudo btrfs filesystem usage -T /mountpoint

sudo btrfs subvolume list /mountpoint

Zu prüfen sind:

Bei Btrfs können Daten- und Metadatenbereiche unterschiedlich ausgelastet sein. Eine einfache df-Ausgabe reicht deshalb nicht immer für die vollständige Einordnung.

ZFS

zpool list

zfs list -o space

Snapshots:

zfs list \
  -t snapshot \
  -o name,used,refer,creation

Zu prüfen sind:

Snapshots und Copy-on-Write-Daten können Speicher belegen, obwohl aktuelle Dateien bereits gelöscht wurden.

7.13.24 macOS – Speicherzustand prüfen

LESEND

df -h

Bestimmten Pfad prüfen:

df -h /System/Volumes/Data

Datenträger und Partitionen:

diskutil list

Informationen zum Startvolume:

diskutil info /

APFS-Struktur:

diskutil apfs list

APFS-Snapshots:

diskutil apfs listSnapshots /

Lokale Time-Machine-Snapshots:

tmutil listlocalsnapshots /

Große Verzeichnisse unterhalb des Datenvolumes:

LESEND, LASTERZEUGEND

sudo du \
  -x \
  -h \
  -d 1 \
  /System/Volumes/Data \
  2>/dev/null |
sort -h

Gelöschte, noch geöffnete Dateien:

sudo lsof +L1

Bei APFS teilen sich mehrere Volumes den freien Speicher eines gemeinsamen Containers. Daher müssen Volume, Container, Quotas, Reservierungen und Snapshots gemeinsam betrachtet werden.

Die macOS-Anzeige „verfügbar“ kann zusätzlich löschbaren Speicher enthalten. Dieser ist nicht mit unmittelbar freiem Speicher in jeder konkreten Betriebssituation gleichzusetzen.

7.13.25 Docker – Speicherverbrauch prüfen

Docker-Root-Verzeichnis:

LESEND

docker info \
  --format '{{.DockerRootDir}}'

Docker-Speicherübersicht:

docker system df

Detaillierte Übersicht:

docker system df -v

Containergrößen:

docker ps \
  -a \
  --size

Volumes:

docker volume ls

Logpfade der Container:

docker ps -aq |
xargs -r docker inspect \
  --format '{{.Name}} {{.LogPath}}'

Mounts eines bestimmten Containers:

docker inspect \
  --format '{{json .Mounts}}' \
  <Containername>

Zu prüfen sind:

Nicht zulässig als spontane Diagnosemaßnahme:

docker system prune -a --volumes

Dieser Befehl kann gestoppte Container, ungenutzte Images, Netzwerke, Build-Cache und anonyme Volumes entfernen. Vor einer Bereinigung müssen alle betroffenen Objekte einzeln geprüft werden.

Das manuelle Löschen innerhalb von /var/lib/docker kann die Docker-Metadaten und Containerdaten beschädigen.

7.13.26 Kubernetes – Ephemeral Storage und DiskPressure prüfen

Nodezustand:

LESEND

kubectl get nodes

Bestimmten Node untersuchen:

kubectl describe node <Node>

Zu prüfen sind insbesondere:

DiskPressure
NodeHasDiskPressure
ephemeral-storage
imagefs.available
imagefs.inodesFree
nodefs.available
nodefs.inodesFree

Ereignisse:

kubectl get events \
  --all-namespaces \
  --sort-by=.metadata.creationTimestamp

Betroffenen Pod untersuchen:

kubectl describe pod \
  <Pod> \
  -n <Namespace>

Persistente Volumes:

kubectl get pvc \
  --all-namespaces

Die angezeigte PVC-Kapazität ist nicht automatisch der aktuell freie Speicher innerhalb des eingebundenen Dateisystems.

Lokaler Ephemeral Storage kann unter anderem umfassen:

Bei Node-Druck kann der Kubelet Pods beenden, um Ressourcen zurückzugewinnen. Das Löschen einzelner Pods behebt die Ursache nicht, wenn Logs, Images oder Anwendungen sofort erneut denselben Speicherverbrauch erzeugen.

7.13.27 Anwendungen und Dienste als Verursacher prüfen

Häufige Speicherverbraucher:

Bereich Mögliche Ursache
Protokolle fehlende Rotation, Debugmodus, Fehlerschleife
Datenbank Transaktionslog, WAL, Temp-Bereich, Replikationsverzug
Backup fehlende Retention, doppelte Sicherungen, abgebrochene Jobs
Container unbeschränkte Logs, alte Images, beschreibbare Layer
Monitoring hochauflösende Metriken, zu lange Aufbewahrung
Mail Queue, Anhänge, Quarantäne
Druck blockierte Spooldateien
Anwendung Cache, Sitzungen, Uploads, Exporte
Betriebssystem Updates, Dumps, temporäre Dateien
Entwicklung Build-Artefakte, Paketcache, Testdaten
Virtualisierung Snapshots, virtuelle Festplatten, Replikation
Dateidienst Benutzerdateien, Papierkorb, Versionierung
Security EDR-Quarantäne, Scanprotokolle, Forensikdaten

Zu prüfen sind:

7.13.28 Netzwerkfreigaben, NAS und SAN prüfen

Bei SMB, NFS, iSCSI, Fibre Channel oder Cloudspeicher müssen Client und Backend getrennt geprüft werden.

Zu erfassen sind:

Mögliche Sonderfälle:

Herstellerspezifische Lösch-, Snapshot- und Poolbefehle dürfen erst nach Prüfung der jeweiligen Dokumentation verwendet werden.

7.13.29 Schreibgeschütztes Dateisystem und Hardwarefehler abgrenzen

Linux-Mountstatus:

LESEND

findmnt \
  -o TARGET,SOURCE,FSTYPE,OPTIONS

Aktuelle Kernelmeldungen:

sudo dmesg \
  --ctime |
grep -Ei \
  'error|i/o|filesystem|read-only|corrupt|nvme|ata|scsi|ext4|xfs|btrfs'

Systemprotokolle:

journalctl \
  -k \
  --since "-2 hours"

Falls smartctl installiert und für das Gerät geeignet ist:

sudo smartctl \
  -a \
  /dev/<Gerät>

macOS-Verifikation:

diskutil verifyVolume /

Ein Dateisystem kann wegen erkannter Fehler auf read-only wechseln. In diesem Fall ist das Löschen von Dateien weder möglich noch die richtige Erstmaßnahme.

Offline-Dateisystemprüfungen wie fsck dürfen nicht ungeprüft auf einem produktiv eingebundenen Dateisystem ausgeführt werden.

Wenn ein Datenträger einen bevorstehenden Ausfall meldet, haben Datensicherung, kontrollierte Außerbetriebnahme und Austausch Vorrang vor einer reinen Speicherbereinigung.

7.13.30 Hypothese und Gegenbeweis formulieren

Beispiel:

Hypothese:
Das Root-Dateisystem ist voll, weil ein Dienst ein
Protokoll ohne funktionierende Rotation erzeugt.

Erwarteter Befund:
df zeigt eine hohe Blockbelegung.
Das Protokollverzeichnis enthält eine stark gewachsene Datei.
Die Änderungszeit und die Dienstmeldungen passen zum Fehlerzeitpunkt.

Gegenbeweis:
Das Protokoll ist klein oder wächst nicht.
Die Belegung bleibt auch nach kontrolliertem Stoppen
des Dienstes unverändert.

Testmethode:
Dateisystembelegung, Verzeichnisgröße, Änderungszeit,
offene Dateien und Dienstprotokolle vergleichen.

Erfolgskriterium:
Der verursachende Schreibpfad ist eindeutig nachgewiesen.

Eine belastbare Hypothese enthält:

7.13.31 Kontrollierte Maßnahmen

Maßnahme Voraussetzung Risiko
unnötige temporäre Daten entfernen Eigentümer und Entbehrlichkeit bestätigt benötigte Sitzungs- oder Arbeitsdaten können verloren gehen
Protokollrotation korrigieren Logwachstum nachgewiesen laufender Dienst kann Logdatei weiter offen halten
Journald begrenzen Journal als Ursache bestätigt ältere Diagnoseinformationen gehen verloren
Anwendungscache bereinigen Cache ist dokumentiert wiederherstellbar Lastspitze beim Neuaufbau
Backupretention korrigieren abgelaufene Sicherungen eindeutig bestimmt Wiederherstellungspunkte gehen verloren
Containerobjekte bereinigen jedes Objekt auf Nutzung geprüft Daten oder Rollbackimages können fehlen
Quota anpassen Quota als Ursache und Kapazität vorhanden unkontrolliertes weiteres Wachstum
Volume erweitern Backendkapazität und korrekte Ebenen bestätigt Partitions- oder Dateisystemschaden bei Fehlern
Thin Pool erweitern Poolgrenze nachgewiesen falsche Erweiterungsebene bleibt wirkungslos
Snapshot entfernen Abhängigkeiten und Retention geprüft Wiederherstellungspunkt geht verloren
Dienst kontrolliert neu starten gelöschte offene Datei nachgewiesen Dienstunterbrechung
fehlerhaften Schreibprozess stoppen akutes Wachstum bestätigt Anwendungs- oder Datenverlust
Storage austauschen Hardwarefehler bestätigt Betriebsunterbrechung und Migrationsrisiko

Vor der Maßnahme sind zu dokumentieren:

7.13.32 Beispiele für verändernde Bereinigungen

Die folgenden Befehle sind keine Erstdiagnose und dürfen nur nach Prüfung und Freigabe verwendet werden.

Systemd-Journal kontrolliert begrenzen

LÖSCHEND

sudo journalctl \
  --rotate \
  --vacuum-size=<Zielgröße>

Dabei werden archivierte Journaldateien bis zur angegebenen Zielgröße bereinigt. Relevante Protokolle müssen vorher ausgewertet oder gesichert werden.

Windows-Komponentenspeicher bereinigen

ÄNDERND

Dism.exe /Online /Cleanup-Image /StartComponentCleanup

Dieser Befehl darf nur nach der vorherigen Analyse mit /AnalyzeComponentStore und unter Berücksichtigung laufender Wartungs- oder Updatevorgänge verwendet werden.

Docker-Bereinigung

Vor jedem Prune-Befehl müssen mindestens folgende Ausgaben geprüft werden:

docker system df -v

docker ps -a

docker image ls

docker volume ls

Prune-Befehle sind löschend. Insbesondere --volumes darf nicht verwendet werden, ohne jedes betroffene Volume und dessen Datenverantwortung geprüft zu haben.

7.13.33 Maßnahmen, die nicht spontan ausgeführt werden dürfen

rm -rf auf unbekannten Verzeichnissen
Löschen unter /var/lib/docker
docker system prune -a --volumes
Löschen aktiver Datenbankdateien
Löschen von WAL- oder Transaktionslogs
Löschen aller Snapshots
vssadmin delete shadows
unkontrolliertes Verkleinern des VSS-Speichers
manuelles Löschen aus WinSxS
Leeren produktiver Protokolle ohne Sicherung
fsck auf einem schreibend eingebundenen Dateisystem
Ändern reservierter ext4-Blöcke ohne Kapazitätsplanung
Vergrößern einer Partition ohne Backup und Ebenenprüfung
Entfernen von Kubernetes-PVCs
Löschen unbekannter Container-Volumes
Deaktivieren von Quotas ohne Ursachenanalyse
Neustart des gesamten Hosts als erste Maßnahme

Eine Datei mit der Endung .log, .tmp, .bak oder .old ist nicht automatisch entbehrlich.

7.13.34 Vollständiger Diagnoseablauf

  1. Fehlermeldung vollständig aufnehmen
    Wortlaut, Anwendung, Benutzer und Zeitpunkt dokumentieren.

  2. Betroffenen Pfad bestimmen
    Exakten Datei-, Volume-, Mount- oder Containerpfad erfassen.

  3. Auswirkung bestimmen
    Einzelne Anwendung, Benutzer, Host oder Standort unterscheiden.

  4. Schreibtest nicht unkontrolliert wiederholen
    Zusätzliche Schreibvorgänge können die Lage verschärfen.

  5. Speicherebene bestimmen
    Anwendung, Container, Dateisystem, Volume, Pool und Backend zuordnen.

  6. Gesamtkapazität und freien Speicher erfassen
    Werte in Prozent und absoluten Größen dokumentieren.

  7. Inodes prüfen
    Besonders bei vielen kleinen Dateien.

  8. Quotas prüfen
    Benutzer-, Gruppen-, Projekt-, Verzeichnis- und Anwendungsquotas unterscheiden.

  9. Schreibschutz prüfen
    Read-only-Mount oder Dateisystemfehler ausschließen.

  10. Speicherpool prüfen
    RAID, LVM, Thin Pool, Storage Spaces, NAS oder SAN berücksichtigen.

  11. Snapshots prüfen
    VSS, APFS, Btrfs, ZFS, Hypervisor und Storage-Snapshots erfassen.

  12. Wachstumsrate bestimmen
    Aktuelle Werte mit Monitoring oder früheren Messungen vergleichen.

  13. Große Verzeichnisse eingrenzen
    Suche auf das betroffene Dateisystem beschränken.

  14. Große Dateien bestimmen
    Besitzer, Zweck und Änderungszeit dokumentieren.

  15. Viele kleine Dateien berücksichtigen
    Inodeverbrauch und Dateianzahl untersuchen.

  16. Gelöschte offene Dateien prüfen
    Besonders nach manueller Loglöschung.

  17. Protokolle und Rotation prüfen
    Fehlerschleifen, Debugmodus und Retention untersuchen.

  18. Datenbanken prüfen
    Daten-, Transaktions-, WAL- und Temp-Bereiche unterscheiden.

  19. Backupdaten prüfen
    Retention, abgebrochene Jobs und doppelte Sicherungen untersuchen.

  20. Containerdaten prüfen
    Images, Layer, Volumes, Bind-Mounts und Logs unterscheiden.

  21. Kubernetes-Ephemeralspeicher prüfen
    Nodefs, Imagefs, Inodes, Limits und Evictions auswerten.

  22. Betriebssystembereiche prüfen
    Updates, Dumps, Cache, temporäre Dateien und Papierkorb untersuchen.

  23. Hardware- und I/O-Fehler prüfen
    Ereignisse, Kernelmeldungen und Storagezustand korrelieren.

  24. Hypothese und Gegenbeweis formulieren
    Ursache vor jeder Änderung messbar beschreiben.

  25. Akutes Wachstum kontrollieren
    Verursachenden Schreibprozess nur mit Freigabe drosseln oder stoppen.

  26. Minimale sichere Entlastung planen
    Nur bestätigte, entbehrliche Daten auswählen.

  27. Eine Maßnahme durchführen
    Nicht mehrere Variablen gleichzeitig verändern.

  28. Freien Speicher erneut messen
    Absoluten Wert und Prozentwert dokumentieren.

  29. Ursprünglichen Schreibvorgang testen
    Anwendung und nicht nur Diagnosewerkzeug prüfen.

  30. Weitere Ebenen verifizieren
    Pool, Volume, Dateisystem und Anwendung erneut kontrollieren.

  31. Wachstum weiter beobachten
    Prüfen, ob der Speicher sofort wieder abnimmt.

  32. Dauerhafte Ursache beheben
    Rotation, Retention, Quota, Kapazität oder Anwendung korrigieren.

  33. Monitoring verbessern
    Prozentwert, freien Absolutwert, Inodes und Wachstumsrate überwachen.

  34. Vorgang dokumentieren
    Ursache, Maßnahme, Risiko, Ergebnis und Prävention festhalten.

7.13.35 Befundmatrix

Befund Mögliche Einordnung Nächster Nachweis
df zeigt 100 %, du ebenfalls sehr hoch sichtbare Dateien belegen das Dateisystem größte Verzeichnisse bestimmen
df zeigt 100 %, du deutlich weniger offene gelöschte Dateien, Snapshots oder Metadaten lsof +L1 und Snapshotprüfung
Blöcke frei, Inodes 100 % zu viele Dateien Verzeichnisse mit vielen kleinen Dateien bestimmen
nur ein Benutzer betroffen Benutzerquota Quota des Benutzers prüfen
nur ein Verzeichnis betroffen FSRM-, Projekt- oder Anwendungsquota wirksames Verzeichnislimit prüfen
Dateisystem ist read-only Dateisystem- oder Storagefehler Kernel- und Ereignisprotokolle
Root-Dateisystem voll Logs, Cache, Container oder fehlender Mount /var, /tmp, Docker und Mounts prüfen
nach Loglöschung keine Freigabe Datei wird noch geöffnet gehalten lsof +L1
Dockerhost voll Images, Layer, Volumes oder Logs docker system df -v
Container meldet voll, Host nicht Container-Layer, Volume oder Quota Mounts und beschreibbaren Layer prüfen
Kubernetes-Node zeigt DiskPressure Nodefs, Imagefs oder Inodes knapp Nodebeschreibung und Ereignisse
PVC vorhanden, Anwendung meldet voll Dateisystem innerhalb des PVC oder Storagequota Volume im Pod und Backend prüfen
Logical Volume hat Platz, Thin Pool ist voll Thin Provisioning erschöpft lvs mit Daten- und Metadatenprozent
Dateien wurden gelöscht, Snapshotgröße steigt Copy-on-Write hält alte Blöcke Snapshotbelegung prüfen
Windows-Volume voll, Verzeichnissumme kleiner VSS, Systemdateien oder unzugängliche Bereiche VSS und Systembereiche prüfen
macOS zeigt widersprüchliche Werte APFS-Container, Snapshots oder löschbarer Speicher APFS-Container und Snapshots prüfen
NAS-Freigabe voll, NAS-Pool hat Platz Share-, Benutzer- oder Volumequota Backendquota prüfen
Speicher wächst sehr schnell Fehlerschleife oder unkontrollierter Job Änderungszeit und aktive Prozesse
nach Bereinigung sofort wieder voll Ursache weiterhin aktiv Wachstumsquelle erneut messen
I/O-Fehler zusätzlich zu wenig Speicher Hardware- oder Pfadfehler Storagezustand und Ereignisse

7.13.36 Typische Diagnosefehler

7.13.37 Verifikation

Nach der Maßnahme müssen mindestens folgende Punkte geprüft werden:

Ein einzelner erfolgreicher Schreibtest reicht nicht aus, wenn der Speicher weiterhin unkontrolliert wächst.

7.13.38 Prävention und Monitoring

Zu überwachen sind:

Ein sinnvoller Alarm berücksichtigt nicht nur einen festen Prozentwert.

Beispiel:

Warnung:
Auslastung über organisationsspezifischem Grenzwert
UND weniger als definierter absoluter Freispeicher

Kritisch:
Kapazität reicht bei aktueller Wachstumsrate
nicht bis zum nächsten geplanten Eingriff

Zusätzliche Präventionsmaßnahmen:

7.13.39 Dokumentationsvorlage

Störung:
<exakte Fehlermeldung>

Zeitpunkt:
<Datum und Uhrzeit>

Betroffenes System:
<Hostname, VM, Container oder Node>

Betroffene Anwendung:
<Dienst oder Anwendung>

Betroffener Pfad:
<Laufwerksbuchstabe, Mountpoint oder Dateipfad>

Speicherebenen:
<Anwendung, Dateisystem, Volume, Pool und Backend>

Dateisystem:
<Typ und Mountoptionen>

Gesamtkapazität:
<Wert>

Freier Speicher vor der Maßnahme:
<Wert und Prozent>

Inodebelegung:
<Wert und Prozent>

Wirksame Quota:
<Typ, Limit und Nutzung>

Snapshotbelegung:
<Wert und Bestand>

Thin-Pool-Auslastung:
<Daten- und Metadatenprozent>

Wachstumsrate:
<Wert pro Stunde oder Tag>

Größte Verbraucher:
<Pfade, Größen und Besitzer>

Gelöschte offene Dateien:
<Befund>

Storage- und Hardwarezustand:
<Befund>

Nachgewiesene Ursache:
<technischer Nachweis>

Gegenbeweis ausgeschlossen durch:
<Test und Ergebnis>

Durchgeführte Maßnahme:
<genau beschriebene Änderung>

Risiko und Rückweg:
<Beschreibung>

Freier Speicher nach der Maßnahme:
<Wert und Prozent>

Verifikation:
<Schreibtest, Anwendungstest und Monitoring>

Prävention:
<Rotation, Retention, Quota, Kapazität oder Monitoring>

7.13.40 Checkliste

7.13.41 Schnellreferenz

Aufgabe Befehl
Windows-Volumes Get-Volume
PowerShell-Dateisystemlaufwerke Get-PSDrive -PSProvider FileSystem
Windows-Datenträger Get-Disk
Windows-Partitionen Get-Partition
physische Windows-Speicherobjekte Get-PhysicalDisk
NTFS-Quota fsutil quota query C:
FSRM-Quotas Get-FsrmQuota
VSS-Speicher vssadmin list shadowstorage
Shadow Copies vssadmin list shadows
Windows-Komponentenspeicher Dism.exe /Online /Cleanup-Image /AnalyzeComponentStore
Linux-Dateisystembelegung df -hT
Linux-Pfad prüfen df -hT <Pfad>
Linux-Inodes df -i
Mounts findmnt
Mount eines Pfades findmnt --target <Pfad>
Blockgeräte lsblk -o NAME,TYPE,FSTYPE,SIZE,FSAVAIL,FSUSE%,MOUNTPOINTS
Verzeichnisgrößen du -x -h --max-depth=1 <Pfad>
gelöschte offene Dateien lsof +L1
Journalbelegung journalctl --disk-usage
Benutzerquota quota -s
Quotaübersicht repquota -a
XFS-Quota xfs_quota -x -c 'report -h' <Mountpoint>
LVM Physical Volumes pvs
LVM Volume Groups vgs
LVM und Thin Pools lvs -a -o lv_name,vg_name,lv_size,pool_lv,origin,data_percent,metadata_percent
Btrfs-Auslastung btrfs filesystem usage -T <Mountpoint>
ZFS-Poolauslastung zpool list
ZFS-Datasetbelegung zfs list -o space
macOS-Dateisystembelegung df -h
macOS-Datenträger diskutil list
APFS-Struktur diskutil apfs list
APFS-Snapshots diskutil apfs listSnapshots /
lokale Time-Machine-Snapshots tmutil listlocalsnapshots /
Docker-Speicherübersicht docker system df -v
Docker-Containergrößen docker ps -a --size
Kubernetes-Nodes kubectl get nodes
Kubernetes-Nodezustand kubectl describe node <Node>
Kubernetes-PVCs kubectl get pvc --all-namespaces

7.13.42 Quellen

Offizielle Microsoft-Dokumentation

Offizielle Linux- und Projektdokumentation

Offizielle Docker-Dokumentation

Offizielle Kubernetes-Dokumentation

Offizielle Apple-Dokumentation

Für diese Seite wurden keine Community-Berichte, Hersteller-Social-Media-Aussagen oder eigenen Laborergebnisse als Nachweis verwendet.

Revision #1
Created 2 August 2026 15:32:50 by Admin
Updated 2 August 2026 15:33:05 by Admin