Speicherplatz freigeben auf dem vServer – praxisnaher Leitfaden mit Docker & zusätzlichem Volume

Auf vielen gemieteten vServern ist der Hauptspeicher knapp bemessen – typischerweise ein Root-Filesystem wie /dev/sdb1 mit 40–80 GB. Gleichzeitig lassen sich beim Provider oft zusätzliche Volumes buchen, die aber meist etwas langsamer sind. In dieser Kombination stellt sich die Frage:

Wie schafft man sicher Speicherplatz – und was kann man ohne Probleme auf ein langsameres Volume auslagern?

Dieser Artikel fasst ein praxisnahes Vorgehen zusammen, inklusive konkreter Shell-Befehle, Fokus auf Docker-Setups (z.B. mailcow) und dem Verschieben von Webseiten.

1. Situation analysieren: Wo ist der Speicher hin?

Zuerst sollte klar sein, welches Filesystem knapp ist und welche Volumes zur Verfügung stehen:

bashdf -h

Beispielausgabe:

textFilesystem      Size  Used Avail Use% Mounted on
/dev/sdb1        75G   68G  4.7G  94% /
/dev/sda        18G  7.9G   10G  45% /mnt/HC_Volume_101292787
...

/dev/sdb1 – Root-Filesystem, schnell, aber voll
/dev/sda – zusätzliches Volume, langsamer, aber erweiterbar

Ziel: Das Root-Filesystem entlasten und nicht-kritische Daten auf /dev/sda verschieben.

2. Sofortmaßnahmen: Schnellen, „toten“ Ballast loswerden

2.1 Docker Container Logs löschen

Docker-Container-Logs sind ein Klassiker, der gern mehrere GB frisst. Standardmäßig liegen sie unter:

text/var/lib/docker/containers/*/*-json.log

Sicher löschen (= leeren), ohne Container zu stoppen:

bashsudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

Die Dateien bleiben bestehen, werden nur auf 0 Byte gesetzt.
Container laufen weiter.
Keine funktionale Beeinträchtigung – nur Logs sind weg.

2.2 Docker-Cache & -Ressourcen aufräumen

Alles, was nicht mehr gebraucht wird, kann Docker selbst entfernen:

bash# Container, Netzwerke, Images (ohne Container), Build-Cache
docker system prune -a -f

Optionen bei Bedarf erweitern (Volumes, etc.), aber das obige räumt in vielen Fällen schon ordentlich auf.

2.3 Systemd Journal bereinigen

systemd-journald hält Logs oft länger als nötig. Das kann mehrere GB belegen:

Ältere Journal-Logs löschen:

bash# Alles, was älter als 7 Tage ist, löschen
sudo journalctl --vacuum-time=7d

Oder auf maximale Größe begrenzen, z.B. 100 MB:

bashsudo journalctl --vacuum-size=100M

Damit bleibt Platzbedarf dauerhaft begrenzt.

2.4 Alte rotierte Logs entfernen

In /var/log sammeln sich klassische Logrotate-Dateien:

/var/log/*.1
/var/log/*.gz
Unterordner wie /var/log/nginx/, /var/log/apache2/, etc.

Ansicht:

bashsudo du -sh /var/log/*

Löschen alter, komprimierter Logs (Vorsicht, aber in der Regel unkritisch):

bashsudo rm /var/log/*.gz /var/log/*.[1-9] 2>/dev/null || true

Ggf. analog in Unterordnern.

3. Nachhaltig: Log-Rotation für Docker konfigurieren

Damit Docker-Logs nicht wieder das System vollschreiben, sollte eine Log-Rotation konfiguriert werden.

Docker-Konfiguration in /etc/docker/daemon.json anpassen/erstellen:

json{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

Danach Docker neu starten:

bashsudo systemctl restart docker

Ergebnis:

Pro Container maximal ca. 30 MB Logs.
Der local-Treiber ist ressourcenschonend, komprimiert intern und verhindert ausufernde Log-Files.

4. Langsameres Volume erweitern (Beispiel: /dev/sda)

Hat der Provider das Volume vergrößert (z.B. von 10 auf 18 GB), muss das Dateisystem unter Linux angepasst werden.

4.1 Kernel das neue Disk-Size erkennen lassen

bashecho 1 | sudo tee /sys/block/sda/device/rescan

4.2 Dateisystem mit `resize2fs` vergrößern

Für ein reines Device (/dev/sda ohne Partitionsnummer) reicht:

bashsudo resize2fs /dev/sda

Das geht online, während das Volume gemountet ist (ext4 unterstützt Online-Resize).

4.3 Ergebnis prüfen

bashdf -h /mnt/HC_Volume_101292787

Die Größe sollte jetzt dem beim Provider eingestellten Wert entsprechen (z.B. ~18G).

5. Was auf das langsamere Volume auslagern – und was nicht?

Nicht alles eignet sich gleich gut für einen langsameren Speicher. Entscheidend sind I/O-Muster und Latenzanforderungen.

5.1 Unkritische Kandidaten (gut geeignet für langsames Volume)

Diese Verzeichnisse sind I/O-unkritisch oder werden selten gelesen/geschrieben:

Webseiten-Daten (statischer Content)
- Typischer Pfad: /var/www/, /srv/www/, /home/www-data/
- HTML, CSS, JS, Bilder: Laden einmal in RAM, werden gecached.
- Performance-Impact meist gering, besonders bei geringer Last.
Große Downloads / Medien
- Videos, große Dateien zum Download, Backups:
- I/O ist sequentiell, Latenz nicht superkritisch.
Backups
- mailcow-Backups, DB-Dumps, tar-Archive.
- Zugriff selten, Größe oft groß → perfekt für langsamen Speicher.
- Beispiel mailcow:
  - /var/lib/mailcow/backup oder eigenes Backup-Verzeichnis.
Caches
- /var/cache (APT-Cache, diverse Anwendungs-Caches)
- Können im Zweifel neu aufgebaut werden.

5.2 Mit Bedacht auslagern (abhängig vom Workload)

Dynamische Webanwendungen (PHP, Node, etc.)
- Der Quellcode (z.B. /var/www/myapp) kann durchaus auf das langsame Volume.
- Der dominante Anteil der Antwortzeit liegt meist in der Applikationslogik und DB-Zugriffen, nicht im Code-Read.
- Bei sehr vielen kleinen Dateien (WordPress mit vielen Plugins/Themes) kann ein langsameres Volume den First-Load etwas verzögern, aber im Alltag meist tolerierbar.
Container-Volumes für nicht-DB-Daten
- Upload-Verzeichnisse, generierte Assets, etc.
- Alles, was nicht hochfrequent zufällig gelesen/geschrieben wird.

5.3 Nicht auslagern (sollten auf schnellem Volume bleiben)

Datenbanken
- MySQL/MariaDB: typischer Pfad /var/lib/mysql
- PostgreSQL: /var/lib/postgresql
- Redis: /var/lib/redis
- Hier zählt IOPS und Latenz – langsamer Speicher wirkt sich direkt auf jede Query aus.
Mailcow aktive Maildaten
- z.B. Dovecot-Maildir unter /var/lib/mailcow/vmail o.ä.
- Viele kleine Dateien, hohe I/O-Rate → schnelleren Speicher nutzen.
- Backups davon können hingegen ausgelagert werden.
Docker-Engine-Daten (wenn möglich)
- /var/lib/docker (Engine-Storage, Layer, etc.)
- Je nach Setup und Last kritischer – idealerweise auf schnellem Storage belassen.
- Hier lieber Logs/Caches begrenzen als das komplette Docker-Storage verschieben.

6. Webseiten auf das Volume verschieben (mit Code-Beispielen)

Angenommen, der Webroot liegt in /var/www und das zusätzliche Volume ist unter /mnt/HC_Volume_101292787 eingehängt.

6.1 Variante A: Ganzes `/var/www` per Bind-Mount verschieben

Zielverzeichnis auf dem Volume anlegen:

bashsudo mkdir -p /mnt/HC_Volume_101292787/www

Bestehende Daten kopieren (Rechte, Symlinks, Ownership behalten):

bashsudo rsync -av /var/www/ /mnt/HC_Volume_101292787/www/

Altes Verzeichnis umbenennen (für Rollback):

bashsudo mv /var/www /var/www.bak

Neues Mountpoint-Verzeichnis erstellen:

bashsudo mkdir /var/www

Bind-Mount einrichten:

bashsudo mount --bind /mnt/HC_Volume_101292787/www /var/www

Persistent machen in /etc/fstab:

bashecho "/mnt/HC_Volume_101292787/www /var/www none bind 0 0" | sudo tee -a /etc/fstab

Test:

bashsudo mount -a
df -h /var/www

Falls etwas schiefgeht:

bashsudo umount /var/www
sudo rm -rf /var/www
sudo mv /var/www.bak /var/www

6.2 Variante B: Nur einzelne Projekte per Symlink auslagern

Wenn nur eine große Seite ausgelagert werden soll:

bash# 1. Projekt verschieben
sudo mv /var/www/grosses-projekt /mnt/HC_Volume_101292787/grosses-projekt

# 2. Symlink zurück nach /var/www
sudo ln -s /mnt/HC_Volume_101292787/grosses-projekt /var/www/grosses-projekt

Nginx/Apache können damit problemlos umgehen, solange Rechte/Owner stimmen (z.B. www-data).

7. Weitere Kandidaten: Caches & temporäre Verzeichnisse

7.1 `/var/cache` auslagern

Zielordner auf Volume:

bashsudo mkdir -p /mnt/HC_Volume_101292787/var-cache
sudo rsync -a /var/cache/ /mnt/HC_Volume_101292787/var-cache/

Original sichern und Bind-Mount setzen:

bashsudo mv /var/cache /var/cache.bak
sudo mkdir /var/cache
sudo mount --bind /mnt/HC_Volume_101292787/var-cache /var/cache
echo "/mnt/HC_Volume_101292787/var-cache /var/cache none bind 0 0" | sudo tee -a /etc/fstab

7.2 Temporäre Verzeichnisse (optional)

Je nach Nutzung können auch bestimmte temp-Folder ausgelagert werden. Mit Vorsicht – manche Dienste erwarten schnelle I/O in /tmp.

8. Checkliste: Maßnahmen im Überblick

Sofort freien Speicher schaffen:

bash# Docker-Logs leeren
sudo sh -c 'truncate -s 0 /var/lib/docker/containers/*/*-json.log'

# Docker aufräumen
docker system prune -a -f

# Systemd-Journal begrenzen
sudo journalctl --vacuum-time=7d
# oder
sudo journalctl --vacuum-size=100M

# Alte komprimierte Logs löschen
sudo rm /var/log/*.gz /var/log/*.[1-9] 2>/dev/null || true

Zukünftige Log-Explosion verhindern:

json// /etc/docker/daemon.json
{
  "log-driver": "local",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

bashsudo systemctl restart docker

Zusätzliches Volume vergrößern (ext4 auf /dev/sda):

bashecho 1 | sudo tee /sys/block/sda/device/rescan
sudo resize2fs /dev/sda
df -h /mnt/HC_Volume_101292787

Unkritische Daten auslagern (Beispiele):

bash# Webseiten
sudo rsync -av /var/www/ /mnt/HC_Volume_101292787/www/
sudo mv /var/www /var/www.bak
sudo mkdir /var/www
sudo mount --bind /mnt/HC_Volume_101292787/www /var/www
echo "/mnt/HC_Volume_101292787/www /var/www none bind 0 0" | sudo tee -a /etc/fstab

# mailcow-Backups (Beispielpfad anpassen)
sudo rsync -av /var/lib/mailcow/backup/ /mnt/HC_Volume_101292787/mailcow-backups/

Fazit

Mit ein paar gezielten Schritten lässt sich ein knapp bemessener vServer nachhaltig entlasten:

Kurzfristig: Docker-Logs, Docker-Cache, Systemd-Journal und alte Logs bereinigen.
Mittelfristig: Docker-Log-Rotation sauber konfigurieren.
Strategisch: Unkritische Daten (Webseiten, Backups, Medien, Caches) auf das langsamere Volume verschieben – Datenbanken und aktive Maildaten bleiben auf dem schnellen Storage.

So entsteht ein Setup, das sowohl stabil als auch zukunftssicher ist – ohne sofort auf einen größeren vServer wechseln zu müssen.

Speicherplatz freigeben auf dem vServer – praxisnaher Leitfaden mit Docker & zusätzlichem Volume

1. Situation analysieren: Wo ist der Speicher hin?

2. Sofortmaßnahmen: Schnellen, „toten“ Ballast loswerden

2.1 Docker Container Logs löschen

2.2 Docker-Cache & -Ressourcen aufräumen

2.3 Systemd Journal bereinigen

Ältere Journal-Logs löschen:

Oder auf maximale Größe begrenzen, z.B. 100 MB:

2.4 Alte rotierte Logs entfernen

3. Nachhaltig: Log-Rotation für Docker konfigurieren

4. Langsameres Volume erweitern (Beispiel: /dev/sda)

4.1 Kernel das neue Disk-Size erkennen lassen

4.2 Dateisystem mit `resize2fs` vergrößern

4.3 Ergebnis prüfen

5. Was auf das langsamere Volume auslagern – und was nicht?

5.1 Unkritische Kandidaten (gut geeignet für langsames Volume)

5.2 Mit Bedacht auslagern (abhängig vom Workload)

5.3 Nicht auslagern (sollten auf schnellem Volume bleiben)

6. Webseiten auf das Volume verschieben (mit Code-Beispielen)

6.1 Variante A: Ganzes `/var/www` per Bind-Mount verschieben

6.2 Variante B: Nur einzelne Projekte per Symlink auslagern

7. Weitere Kandidaten: Caches & temporäre Verzeichnisse

7.1 `/var/cache` auslagern

7.2 Temporäre Verzeichnisse (optional)

8. Checkliste: Maßnahmen im Überblick

Fazit

Schreibe einen Kommentar Antwort abbrechen

Vielleicht gefällt dir auch folgendes?

Microsoft Bing Rewards Farming leicht gemacht – mit der Chrome Extension Bing Rewards Auto Search

Mehr Power für deine Web-Suche: Erweiterte Suchoptionen von Microsoft Bing

Amazon-Gutschein gratis durch sammeln von Rewards Punkten

CrowdSec Tagesbericht per Email

OpenWRT Hostnames auf Dump-AP anzeigen (bei Mesh Netzwerk)

OpenWRT Watchdog Script gegen Verbindungsabbrüche – Internet connection losses

Speicherplatz freigeben auf dem vServer – praxisnaher Leitfaden mit Docker & zusätzlichem Volume

1. Situation analysieren: Wo ist der Speicher hin?

2. Sofortmaßnahmen: Schnellen, „toten“ Ballast loswerden

2.1 Docker Container Logs löschen

2.2 Docker-Cache & -Ressourcen aufräumen

2.3 Systemd Journal bereinigen

Ältere Journal-Logs löschen:

Oder auf maximale Größe begrenzen, z.B. 100 MB:

2.4 Alte rotierte Logs entfernen

3. Nachhaltig: Log-Rotation für Docker konfigurieren

4. Langsameres Volume erweitern (Beispiel: /dev/sda)

4.1 Kernel das neue Disk-Size erkennen lassen

4.2 Dateisystem mit resize2fs vergrößern

4.3 Ergebnis prüfen

5. Was auf das langsamere Volume auslagern – und was nicht?

5.1 Unkritische Kandidaten (gut geeignet für langsames Volume)

5.2 Mit Bedacht auslagern (abhängig vom Workload)

5.3 Nicht auslagern (sollten auf schnellem Volume bleiben)

6. Webseiten auf das Volume verschieben (mit Code-Beispielen)

6.1 Variante A: Ganzes /var/www per Bind-Mount verschieben

6.2 Variante B: Nur einzelne Projekte per Symlink auslagern

7. Weitere Kandidaten: Caches & temporäre Verzeichnisse

7.1 /var/cache auslagern

7.2 Temporäre Verzeichnisse (optional)

8. Checkliste: Maßnahmen im Überblick

Fazit

Schreibe einen Kommentar Antwort abbrechen

Vielleicht gefällt dir auch folgendes?

Microsoft Bing Rewards Farming leicht gemacht – mit der Chrome Extension Bing Rewards Auto Search

Mehr Power für deine Web-Suche: Erweiterte Suchoptionen von Microsoft Bing

Amazon-Gutschein gratis durch sammeln von Rewards Punkten

CrowdSec Tagesbericht per Email

OpenWRT Hostnames auf Dump-AP anzeigen (bei Mesh Netzwerk)

OpenWRT Watchdog Script gegen Verbindungsabbrüche – Internet connection losses

4.2 Dateisystem mit `resize2fs` vergrößern

6.1 Variante A: Ganzes `/var/www` per Bind-Mount verschieben

7.1 `/var/cache` auslagern