VPS-Festplatte voll: vier Wege zu mehr Speicherplatz

Wenn die VPS-Festplatte voll ist: vier Wege zu mehr Speicherplatz

Eine volle VPS-Festplatte hat genau vier Auswege: Platz zurückholen, das Root-Volume vergrößern, ein separates Block-Storage-Volume einhängen, oder die kalten Daten auf einen Storage-VPS auslagern. Welcher davon der richtige ist, entscheidet nicht der Monatspreis, sondern das Wachstum der Daten in den nächsten zwölf Monaten. Die Reihenfolge unten ist die, in der man die vier Wege abarbeitet, wenn der Dienst gerade steht.

Das Symptom ist überall dieselbe Zeile: No space left on device. Danach scheitert fast jede Aktion. MySQL beendet sich, nginx schreibt keine Logzeile mehr, apt bricht mitten im Upgrade ab, und manchmal scheitert sogar die Anmeldung per SSH, weil kein Platz für die Sitzungsdateien bleibt. Ein voller Server nimmt Ihnen die Werkzeuge weg, mit denen Sie ihn reparieren wollen. Deshalb steht das Messen vor dem Löschen.

Zuerst messen: was belegt den Platz wirklich?

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

Der Schalter -x hält du auf einem einzigen Dateisystem. Ohne ihn zählt der Befehl eingehängte Volumes und virtuelle Dateisysteme wie /proc mit, und das Ergebnis ist wertlos. sort -h sortiert die lesbaren Größen richtig, also GB vor MB.

df -i ist der zweite Blick, den viele auslassen. Ein Dateisystem kann voll sein, obwohl df -h freien Platz meldet. Dann sind die Inodes aufgebraucht, also die Verwaltungseinträge, von denen jede Datei genau einen belegt. Ein ext4-Dateisystem bekommt seine Inode-Zahl bei der Formatierung fest zugewiesen und kann sie später nicht erhöhen. Millionen winziger Session-, Cache- oder Mail-Dateien fressen die Inodes auf, lange bevor sie die Gigabyte aufbrauchen. Die Fehlermeldung dabei ist dieselbe: No space left on device. In der Spalte IUse% steht dann 100 Prozent, in Use% vielleicht 40.

Für die Suche nach den großen Verzeichnissen ist ncdu bequemer als jede du-Pipeline.

sudo apt install -y ncdu
sudo ncdu -x /

Wenn df und du sich widersprechen, liegt das fast immer an gelöschten Dateien, die ein Prozess noch offen hält. Der Verzeichniseintrag ist weg, der Speicher nicht, weil der Kernel die Blöcke erst freigibt, wenn das letzte offene Dateihandle verschwindet. sudo lsof +L1 listet diese Dateien, in der Spalte NLINK steht 0. Der Platz kommt beim Neustart des betroffenen Dienstes zurück. Die weiteren Ursachen und die passenden Kommandos stehen in df und du melden unterschiedliche Werte. Und wenn der Tarif 500 GB verspricht, df aber nur 465 zeigt, fehlt nichts: das ist der Unterschied zwischen GB und GiB.

Ein letzter Punkt vor dem Aufräumen: ext4 legt bei der Formatierung fünf Prozent des Dateisystems für root beiseite. Auf einem 200-GB-Volume sind das 10 GB, die normale Dienste nie zu sehen bekommen. Auf der Systemplatte ist diese Reserve sinnvoll, weil sie verhindert, dass ein voller Server sich gar nicht mehr bedienen lässt. Auf einem reinen Datenvolume ist sie verschenkt, und sudo tune2fs -m 1 /dev/sdb gibt vier davon frei.

Weg 1: Aufräumen, und was es realistisch bringt

[
  {
    "label": "Docker: ungenutzte Images und Build-Cache",
    "gb_frei": 14
  },
  {
    "label": "journald ohne Gr\u00f6\u00dfenlimit",
    "gb_frei": 3.5
  },
  {
    "label": "Alte Kernel-Pakete und Module",
    "gb_frei": 1.8
  },
  {
    "label": "APT-Paketcache",
    "gb_frei": 1.2
  },
  {
    "label": "Rotierte Logs in /var/log",
    "gb_frei": 0.9
  },
  {
    "label": "Vergessene Dumps und Archive in /root und /home",
    "gb_frei": 6
  }
]

Das sind Beobachtungswerte von Servern, die etwa ein Jahr im Betrieb waren, keine Garantie. Die Reihenfolge stimmt trotzdem fast immer: auf einem Server, auf dem gebaut und deployt wird, stehen die 14 GB aus ungenutzten Docker-Images und Build-Caches ganz oben. Der zweite große Posten ist unspektakulär, nämlich die 6 GB aus alten Datenbank-Dumps und Archiven, die jemand vor Monaten ins Home-Verzeichnis gelegt hat.

docker system df
sudo docker system prune -a

docker system df zeigt in der Spalte RECLAIMABLE, wie viel wirklich zu holen ist. prune -a entfernt alle Images, die kein laufender Container benutzt, also auch die, die Sie beim nächsten Deploy wieder ziehen müssen. Der Schalter --volumes löscht zusätzlich unbenutzte Volumes, und darin liegen im Zweifel Ihre Datenbanken. Benutzen Sie ihn nur mit einer Liste in der Hand. Welcher Befehl was genau anfasst, steht in Docker aufräumen ohne die falschen Daten zu löschen.

journalctl --disk-usage
sudo journalctl --vacuum-size=200M

Der erste Befehl antwortet mit einer Zeile wie Archived and active journals take up 3.9G in the file system. Ohne Limit wächst das Journal bis zu zehn Prozent der Partition. Damit es nicht zurückkommt, tragen Sie das Limit dauerhaft in /etc/systemd/journald.conf ein.

[Journal]
SystemMaxUse=200M

Danach sudo systemctl restart systemd-journald. Alte Kernel sind der dritte Klassiker, und sie sind besonders unangenehm, weil /boot auf vielen Images eine eigene kleine Partition ist. Sie läuft unabhängig vom Rest voll. Das Symptom: apt upgrade bricht beim Erzeugen der initramfs mit No space left on device ab, obwohl df -h / reichlich Platz zeigt.

dpkg -l 'linux-image-*' | grep ^ii
sudo apt autoremove --purge
sudo apt clean

apt clean leert /var/cache/apt/archives, also die heruntergeladenen .deb-Pakete, die nach der Installation niemand mehr braucht. Wenn autoremove den aktuellen Kernel nicht anfassen soll, prüfen Sie vorher mit uname -r, welcher gerade läuft. Der ausführliche Ablauf steht in alte Kernel sauber entfernen, ohne den bootenden zu erwischen.

Aufräumen ist nur dann eine Lösung, wenn die Ursache verschwindet. Sonst ist der Platz in zwei Wochen wieder weg, und zwar nachts. Setzen Sie deshalb im selben Arbeitsgang ein Journal-Limit, eine logrotate-Regel für die Anwendungslogs und einen systemd-Timer für docker system prune -f --filter until=168h. Und richten Sie eine Warnung bei 80 Prozent Belegung ein, damit die nächste Runde nicht wieder im Notfall stattfindet: Plattenplatz und SMART-Werte auf einem VPS überwachen.

Weg 2: Das Root-Volume vergrößern, eine Einbahnstraße

Bei deutschen Anbietern gibt es dafür zwei Modelle. Manche vergrößern die virtuelle Platte direkt, und Sie erweitern Partition und Dateisystem danach selbst. Andere koppeln den Plattenplatz fest an den Tarif: mehr Speicher gibt es nur mit dem nächstgrößeren Paket, und dann bezahlen Sie CPU-Kerne und RAM mit, die Sie vielleicht gar nicht brauchen. Beide Modelle haben dieselbe Eigenschaft: nach oben geht es, zurück nicht.

Der Grund liegt im Dateisystem. XFS lässt sich überhaupt nicht verkleinern, das ist eine Eigenschaft des Formats. ext4 lässt sich verkleinern, aber nur im ausgehängten Zustand, also nicht auf einer laufenden Systemplatte. Kein Anbieter übernimmt diese Operation auf Produktivdaten. Planen Sie den Sprung deshalb so, dass er zwölf Monate trägt, statt ihn zweimal im Jahr zu machen.

Machen Sie vorher einen Snapshot. growpart schreibt die Partitionstabelle neu, und das ist der eine Schritt, bei dem ein Tippfehler die Platte unbrauchbar macht. Der Snapshot liegt allerdings beim selben Anbieter auf derselben Infrastruktur, ersetzt also kein Backup an einem anderen Ort: worin sich Snapshots und Backups unterscheiden.

lsblk
sudo apt install -y cloud-guest-utils
sudo growpart /dev/vda 1
sudo resize2fs /dev/vda1
df -h /

Gerät und Partitionsnummer sind bei growpart zwei getrennte Argumente. growpart /dev/vda1 ohne Leerzeichen ist der häufigste Fehler an dieser Stelle. Auf einem XFS-Dateisystem heißt der letzte Schritt sudo xfs_growfs / und läuft im eingehängten Zustand. Auf Ubuntu-Server-Images mit LVM liegt die Wurzel meist in einer Volume Group, und dann kommen zwei Schritte dazu.

sudo growpart /dev/vda 3
sudo pvresize /dev/vda3
sudo vgs
sudo lvextend -r -l +100%FREE /dev/ubuntu-vg/ubuntu-lv

vgs zeigt den echten Namen der Volume Group, der auf Debian-Images anders lautet als auf Ubuntu-Images. Der Schalter -r bei lvextend erweitert das Dateisystem gleich mit, sodass resize2fs entfällt.

Zwei Meldungen sehen Sie hier oft. NOCHANGE: partition 1 is size 41940992. it cannot be grown heißt, dass die virtuelle Platte noch nicht größer ist. Entweder hat der Anbieter die Änderung noch nicht ausgeführt, oder der Kernel hat die neue Größe noch nicht gelesen. sudo partprobe /dev/vda oder ein Neustart lösen den zweiten Fall. The filesystem is already 12060672 (4k) blocks long. Nothing to do! heißt, dass das Dateisystem bereits zur Partition passt. Dann liegt das Problem eine Ebene tiefer, nämlich bei der Partition, nicht beim Dateisystem.

Weg 3: Ein Block-Storage-Volume einhängen

Dieser Weg passt, wenn genau ein Verzeichnis wächst und der Rest des Systems ruhig bleibt, also etwa Uploads, ein Medienordner oder ein Docker-Verzeichnis. Ein Volume hängt nicht am Tarif, lässt sich meist in kleinen Schritten vergrößern, und es überlebt das Neuaufsetzen des VPS. Der Preis pro GB liegt allerdings in der Nähe des VPS-Speichers, weil dieselbe SSD-Klasse dahinter steht. Der wichtige Unterschied ist die Latenz, denn ein Volume hängt am Netz und nicht am PCIe-Bus: was lokale NVMe und Netzwerkspeicher bei IOPS und Latenz trennt.

lsblk -f
sudo mkfs.ext4 -L daten /dev/sdb
sudo mkdir -p /srv/daten
sudo blkid /dev/sdb

lsblk -f zeigt vorher, ob auf dem Gerät schon ein Dateisystem liegt. Wenn dort ein Typ und eine UUID stehen, formatieren Sie gerade fremde Daten. blkid liefert die UUID für die /etc/fstab, und die UUID ist Pflicht: Gerätenamen wie /dev/sdb können sich nach einem Neustart vertauschen, die UUID nicht.

UUID=6a2f0b3c-9d1e-4a77-8b21-5f0c7d2ae913  /srv/daten  ext4  defaults,nofail,x-systemd.device-timeout=10s  0  2

nofail ist keine Feinheit, sondern der Unterschied zwischen einem bootenden und einem nicht bootenden Server. Fehlt die Option und das Volume ist beim Start nicht da, bleibt systemd stehen und meldet auf der Konsole You are in emergency mode. Über SSH kommen Sie dann nicht mehr hinein, nur noch über die Notfallkonsole des Anbieters. Testen Sie den Eintrag deshalb vor dem Neustart.

sudo systemctl daemon-reload
sudo mount -a
findmnt --verify --verbose
df -h /srv/daten

findmnt --verify prüft die fstab auf genau die Fehler, die sonst erst beim Booten auffallen. df -h /srv/daten muss danach die Größe des Volumes zeigen und nicht die der Systemplatte.

Jetzt das Verschieben, am Beispiel von Docker. Der Dienst muss dafür stehen, weil ein Kopieren im laufenden Betrieb inkonsistente Layer erzeugt.

sudo systemctl stop docker docker.socket containerd
sudo rsync -aHAX --info=progress2 /var/lib/docker/ /srv/daten/docker/
sudo mv /var/lib/docker /var/lib/docker.alt
sudo mkdir /var/lib/docker

Die Schalter bei rsync sind hier alle nötig. -a behält Rechte, Besitzer und Zeitstempel, -H erhält harte Links, die Docker-Layer massenhaft benutzen, und -X erhält erweiterte Attribute wie Capabilities. Der Schrägstrich am Ende von /var/lib/docker/ kopiert den Inhalt des Verzeichnisses. Ohne ihn kopiert rsync das Verzeichnis selbst und Sie landen bei /srv/daten/docker/docker.

/srv/daten/docker  /var/lib/docker  none  bind,nofail  0  0

Nach sudo mount -a und sudo systemctl start docker prüfen Sie mit docker info | grep "Docker Root Dir" und mit df -h /var/lib/docker, ob wirklich das Volume darunterliegt. Erst danach löschen Sie /var/lib/docker.alt. Wer lieber ohne Bind-Mount arbeitet, setzt stattdessen data-root in /etc/docker/daemon.json auf den neuen Pfad.

Der typische Fehler bei diesem Weg ist unsichtbar: ein Dienst schreibt in ein Verzeichnis, das ein Mountpoint sein sollte, aber gerade nicht eingehängt ist. Die Daten landen dann auf der Systemplatte und verschwinden aus dem Blick, sobald das Volume wieder da ist. Das Symptom ist ein wachsendes /, während du unter /srv nichts findet. mountpoint /srv/daten beantwortet die Frage, und sudo mount --bind / /mnt/root macht die verdeckten Daten unter /mnt/root/srv/daten sichtbar. Die vollständige Einrichtung inklusive Partitionierung und Vergrößerung steht in ein Block-Storage-Volume am VPS einrichten.

Weg 4: Kalte Daten auf einen Storage-VPS auslagern

Backups, Medien, Archive, alte Logs und Registry-Blobs haben eine Gemeinsamkeit: sie werden geschrieben und selten gelesen. Für solche Daten zahlen Sie auf einer NVMe-Platte IOPS, die niemand abruft. Genau hier lohnt der Wechsel der Speicherklasse. Ein Storage-VPS ist ein eigener Server mit großen Platten und root-Zugang, auf dem auch Dienste laufen dürfen. Eine Storage Box ist verwaltet und spricht nur Protokolle wie SFTP oder SMB, dafür kostet sie weniger. Die Unterschiede im Detail stehen in worin sich ein Storage-VPS von einem normalen VPS unterscheidet und im Preisvergleich Storage-VPS, Block-Storage und Objektspeicher pro Terabyte.

sudo rsync -aH --delete --info=progress2 /srv/archiv/ backup@storage.example.net:/daten/archiv/

Für Backups ist ein Werkzeug mit Deduplizierung und Verschlüsselung besser als ein reiner Kopierbefehl, weil der Anbieter dann nur Chiffrat sieht.

sudo apt install -y restic
restic -r sftp:backup@storage.example.net:/daten/restic init
restic -r sftp:backup@storage.example.net:/daten/restic backup /srv/daten

Ein Netzmount über SSHFS oder NFS ist für kalte Dateien in Ordnung, für Datenbanken, Docker-Overlays und alles mit Dateisperren nicht. Wenn die Verbindung kurz aussetzt, hängen die zugreifenden Prozesse im Zustand D, also im unterbrechungsfreien Warten, und lassen sich nicht einmal mit kill -9 beenden. Legen Sie deshalb nur ganze Dateien dorthin, keine laufende Datenbank. Wie Sie beide Server verbinden und die Übertragung im privaten Netz halten, steht in Storage-VPS und Haupt-VPS koppeln, und der gleiche Aufbau funktioniert von zu Hause aus: ein NAS auf einen Storage-VPS sichern.

Für deutsche Betreiber kommt ein Punkt dazu, der technisch aussieht, aber juristisch ist. Sobald personenbezogene Daten auf den Speicher wandern, brauchen Sie einen Auftragsverarbeitungsvertrag nach Art. 28 DSGVO und die Information, in welchem Land die Platten tatsächlich stehen. Die Checkliste dazu steht in was beim Storage-VPS aus DSGVO-Sicht zu prüfen ist.

Was Speicher kostet, in Euro pro Terabyte

[
  {
    "label": "Gr\u00f6\u00dferer VPS-Tarif mit mehr NVMe",
    "eur_pro_tb_monat": 60
  },
  {
    "label": "Block-Storage-Volume am VPS",
    "eur_pro_tb_monat": 45
  },
  {
    "label": "Objektspeicher, S3-kompatibel",
    "eur_pro_tb_monat": 6
  },
  {
    "label": "Storage-VPS mit Festplatten",
    "eur_pro_tb_monat": 5
  },
  {
    "label": "Verwaltete Storage Box",
    "eur_pro_tb_monat": 4
  }
]

Das sind Größenordnungen aus öffentlichen Preislisten europäischer Anbieter, Stand September 2026, keine Angebote. Rechnen Sie mit Ihrer eigenen Preisliste nach. Wichtig ist nicht die einzelne Zahl, sondern der Abstand: 60 Euro für schnellen Speicher im Tarif gegen 4 Euro für verwalteten Massenspeicher sind mehr als Faktor zehn. Ein Terabyte Backups auf der Systemplatte ist deshalb keine Bequemlichkeit, sondern eine laufende Rechnung.

Die Zahlen erklären auch, warum Weg 3 und Weg 4 unterschiedliche Aufgaben lösen. Ein Block-Storage-Volume kostet fast so viel wie der VPS-Speicher, ist aber schnell genug für Datenbanken und Container. Ein Storage-VPS kostet einen Bruchteil, liegt dafür am Ende einer Netzverbindung. Wer beides vertauscht, zahlt entweder zu viel oder wartet zu lange.

Die Regel: nach dem Wachstum entscheiden, nicht nach dem Monatspreis

Messen Sie zuerst, wie schnell die Daten wachsen. Eine Zeile pro Tag reicht, per Cron eingetragen.

printf '%s %s\n' "$(date -I)" "$(df --output=used -BG / | tail -1)" | sudo tee -a /var/log/plattenwachstum.log

Nach zwei Wochen kennen Sie die Steigung in GB pro Monat. Multiplizieren Sie sie mit zwölf und vergleichen Sie das Ergebnis mit dem freien Platz. Ist das Wachstum größer als das, was Weg 1 zurückholt, ist Weg 1 keine Lösung, sondern eine Verzögerung um ein paar Wochen. Danach ordnet sich der Rest von selbst.

• Nichts wächst weiter, es war ein einmaliger Ausreißer: Weg 1, zusammen mit einem Limit, damit derselbe Ausreißer nicht wiederkommt.
• Alles wächst gleichmäßig mit dem Dienst, und die Daten müssen schnell sein: Weg 2, ein Sprung, der zwölf Monate trägt.
• Genau ein Verzeichnis wächst, der Rest steht still: Weg 3, dieses Verzeichnis auf ein eigenes Volume.
• Die Menge wächst linear und wird selten gelesen: Weg 4, und die schnelle Platte bleibt frei für das, was sie braucht.

Zielen Sie dabei auf 80 Prozent Belegung, nicht auf 95. Der Rest ist kein verschenkter Platz: ext4 fragmentiert bei sehr hoher Belegung stärker, ein Kernel-Upgrade braucht Platz für die neue initramfs, und Datenbanken legen für große Sortierungen temporäre Dateien an. Ein Server, der bei 97 Prozent läuft, fällt beim nächsten Upgrade aus, nicht heute.

Wenn gar nichts mehr geht: die schnellsten sicheren Gigabyte

Manchmal brauchen Sie erst einmal genug Platz, um überhaupt arbeiten zu können. Diese drei Kommandos sind risikoarm und wirken sofort.

sudo apt clean
sudo journalctl --vacuum-size=100M
sudo truncate -s 0 /var/log/syslog

truncate -s 0 setzt eine Logdatei auf null, ohne sie zu löschen. Das ist wichtig, weil ein rm auf eine offene Logdatei keinen Platz freigibt, solange rsyslog sie noch geöffnet hat. Sie sehen die Datei dann nur noch in lsof +L1, nicht mehr im Verzeichnis, und der Platz bleibt bis zum Neustart des Dienstes belegt. Ist das erledigt, gehen Sie zurück an den Anfang und messen richtig, statt weiter zu löschen.

FAQ

Warum meldet df 100 Prozent, obwohl du viel weniger findet?

Meistens hält ein Prozess eine bereits gelöschte Datei offen. Der Verzeichniseintrag ist weg, deshalb zählt du sie nicht mehr, aber der Kernel gibt die Blöcke erst frei, wenn das letzte Dateihandle geschlossen ist. sudo lsof +L1 zeigt diese Dateien mit 0 in der Spalte NLINK, und ein Neustart des betroffenen Dienstes gibt den Platz zurück. Die zweite Ursache sind Daten, die unter einem Mountpoint liegen: sie belegen die Systemplatte, sind aber verdeckt, solange das Volume eingehängt ist. Mit sudo mount --bind / /mnt/root werden sie sichtbar.

Kann ich das Root-Volume später wieder verkleinern?

In der Praxis nein. XFS lässt sich grundsätzlich nicht verkleinern, ext4 nur im ausgehängten Zustand, was auf einer laufenden Systemplatte nicht geht. Deshalb bieten Anbieter das Verkleinern nicht an, und eine Tarifänderung nach unten scheitert an derselben Stelle. Planen Sie die Vergrößerung so, dass sie zwölf Monate reicht, und legen Sie Daten, die wieder verschwinden könnten, lieber auf ein separates Volume, das Sie einfach abbestellen können.

Was gehört auf ein Block-Storage-Volume und was auf einen Storage-VPS?

Auf das Volume gehört alles, worauf ein Dienst laufend zugreift, also Datenbanken, Docker-Verzeichnisse und Uploads, die Nutzer sofort wieder abrufen. Auf den Storage-VPS gehören Daten, die geschrieben und selten gelesen werden, also Backups, Archive, Medienbestände und alte Logs. Der Preisunterschied pro Terabyte liegt bei mehr als Faktor zehn, der Latenzunterschied ebenfalls. Entscheidend ist die Zugriffshäufigkeit, nicht die Datenmenge.

Wie verschiebe ich /var/lib/docker, ohne Container zu verlieren?

Zuerst sudo systemctl stop docker docker.socket containerd, denn ein Kopieren im laufenden Betrieb erzeugt inkonsistente Layer. Dann sudo rsync -aHAX /var/lib/docker/ /srv/daten/docker/, wobei -H die harten Links erhält, die Docker in großer Zahl benutzt. Danach das alte Verzeichnis umbenennen, ein leeres anlegen und den neuen Pfad per Bind-Mount in der /etc/fstab eintragen. Nach dem Start prüfen Sie mit df -h /var/lib/docker, dass wirklich das Volume darunterliegt, und löschen erst dann die Kopie.