Raspberry Pi Speicher voll

Passende Hardware im Überblick

Mehr Platz auf der Karte – und ein Lesegerät zum Umziehen:
SanDisk Extreme A2 128GB – die Empfehlung, wenn es eine Karte bleiben soll (Link)*
SanDisk microSD 32GB – nur noch für Minimal-Installationen (Link)*
UGREEN USB-3-Kartenleser – zum Klonen auf die neue Karte (Link)*
Acer USB-3-Kartenleser – die günstige Alternative (Link)*

SSD statt Karte – der dauerhafte Ausweg:
Geekworm X1001 M.2-HAT für den Pi 5 (Link)*
Offizielles PCIe-M.2-HAT (Link)*
Intenso M.2 NVMe SSD 500GB – der Preis-Leistungs-Tipp (Link)*
Crucial P310 NVMe SSD 500GB – die schnellere Wahl (Link)*
SanDisk Extreme Portable SSD 1TB – per USB sofort einsatzbereit (Link)*
SanDisk Extreme Portable SSD 2TB – wenn Videos und Fotos dazukommen (Link)*
Intenso TX800 SSD – günstiger Zusatzspeicher am USB-Port (Link)*

Boards und Strom, wenn der Pi gleich mitwandert:
Raspberry Pi 5 mit 16GB RAM – wenn alles gleichzeitig laufen soll (Link)*
Raspberry Pi 5 mit 8GB RAM – die Empfehlung (Link)*
Raspberry Pi 5 mit 4GB RAM – reicht für einzelne Dienste (Link)*
Raspberry Pi 4 Starter-Set – wenn es günstig sein soll (Link)*
Offizielles 27-W-Netzteil – Pflicht im NVMe-Betrieb (Link)*

Kurz gesagt: Was tun, wenn der Speicher voll ist?

Wenn der Raspberry Pi Speicher voll meldet, hilft blindes Löschen selten. Die Reihenfolge lautet immer: erst messen, dann gezielt aufräumen, dann dafür sorgen, dass es nicht wiederkommt.

• Erst messen: df -h zeigt, welche Partition randvoll ist. sudo ncdu -x / zeigt danach interaktiv, welche Ordner den Platz tatsächlich belegen.
• Die üblichen Verdächtigen: journald-Logs, der apt-Paketcache unter /var/cache/apt/archives, alte Kernel-Pakete, Docker-Images und verwaiste Docker-Volumes.
• Die drei wirksamsten Befehle: sudo apt clean, sudo journalctl --vacuum-size=50M und docker system prune -a – zusammen holen sie oft mehrere Gigabyte zurück.
• Der Klassiker unter den Fehlern: Das Dateisystem wurde nie auf die volle Kartengröße gebracht. sudo raspi-config --expand-rootfs und ein Neustart holen den ungenutzten Rest.
• Wenn df wenig anzeigt und trotzdem nichts geht: gelöschte Dateien, die ein Prozess noch offen hält (sudo lsof +L1), oder erschöpfte Inodes (df -i).
• Dauerhafte Lösung: Log-Limits setzen und auf eine SSD umziehen – danach ist das Thema erledigt.

Raspberry Pi Speicher voll – die häufigsten Ursachen

Eine frische Installation ist schlank: Raspberry Pi OS Lite belegt rund zwei Gigabyte, die Desktop-Variante je nach Ausgabe etwa sechs bis neun. Das Problem ist nicht der Startzustand, sondern das, was danach ständig dazukommt und nie wieder verschwindet.

Der größte Einzelposten sind fast immer Protokolldateien. Systemd schreibt jede Meldung ins Journal, und wenn ein Dienst im Sekundentakt Fehler meldet, wächst es ungebremst. Unter Bookworm landet es unter /var/log/journal auf der Karte. In Raspberry Pi OS Trixie steht die Journal-Speicherung per Voreinstellung auf volatile: Das Journal liegt im Arbeitsspeicher und ist nach einem Neustart weg. Das schont die Karte, kostet aber Logs zur Fehlersuche – Systeme, die per Distributions-Upgrade kamen, behalten das alte Verhalten oft bei.

Der zweite Dauerbrenner ist der Paketcache. Jedes apt upgrade lädt .deb-Dateien nach /var/cache/apt/archives und lässt sie dort liegen. Dazu kommen alte Kernel-Pakete, die bei jedem Firmware-Update dazukommen und mehrere hundert Megabyte binden können. Beides wird nicht automatisch entsorgt.

Der dritte Kandidat betrifft alle, die Dienste in Containern laufen lassen: Docker legt für jedes Image Layer ab, behält alte Versionen nach einem Update und hinterlässt Volumes, deren Container längst gelöscht sind. So sammeln sich über Monate zweistellige Gigabyte-Beträge an, ohne dass je ein Hinweis erscheint.

Belegten Speicherplatz finden – Schritt für Schritt

Bevor irgendetwas gelöscht wird, muss klar sein, wo der Platz steckt. Diese Reihenfolge führt in wenigen Minuten zum Ergebnis:

1. Überblick verschaffen: df -h listet alle eingehängten Dateisysteme mit Belegung in Prozent. Interessant ist die Zeile mit dem Einhängepunkt / – steht dort 100 %, ist die Systempartition das Problem.
2. Boot-Partition separat prüfen: df -h /boot/firmware. Diese kleine FAT-Partition läuft gern durch alte Kernel-Dateien voll, während die Hauptpartition noch Platz hat. Ein voller Boot-Bereich führt dazu, dass der Pi nicht mehr startet.
3. Grob eingrenzen: sudo du -xh --max-depth=1 / | sort -h zeigt die obersten Ordner nach Größe sortiert. Das -x ist wichtig, sonst zählt der Befehl eingehängte Netzlaufwerke mit.
4. Interaktiv graben: sudo apt install ncdu und dann sudo ncdu -x /. Ncdu baut einen durchklickbaren Baum, in dem sich mit den Pfeiltasten bis zur einzelnen Datei navigieren lässt.
5. Journal messen: journalctl --disk-usage gibt in einer Zeile aus, wie viel Platz die Systemprotokolle belegen. Werte jenseits von einem Gigabyte sind ein klares Signal.
6. Container prüfen: docker system df trennt sauber nach Images, Containern, Volumes und Build-Cache. Erst danach weiß man, ob ein Aufräumen dort überhaupt lohnt.
7. Partitionsgröße kontrollieren: lsblk stellt die Größe der Karte der Größe der Partition gegenüber. Klaffen die beiden Zahlen auseinander, wurde das Dateisystem nie erweitert – siehe Abschnitt weiter unten.

Speicher freigeben – die wirksamsten Befehle im Vergleich

Diese Befehle decken die typischen Speicherfresser ab und lassen sich von oben nach unten abarbeiten; nach jedem Schritt zeigt ein erneutes df -h den Effekt. Weitere Kommandos für den Alltag stehen in der Übersicht der wichtigsten Raspberry-Pi-Befehle.

Logs begrenzen und Daten auslagern statt ständig aufräumen

Aufräumen ist Symptombehandlung. Damit die Karte nicht in drei Monaten wieder voll ist, braucht es zwei Eingriffe: eine harte Obergrenze für Protokolle und einen anderen Ort für alles, was von Natur aus wächst.

Das Journal deckeln. Statt die Standarddatei zu bearbeiten, legt man eine eigene Ergänzungsdatei an – die überlebt jedes Systemupdate. Anlegen mit sudo nano /etc/systemd/journald.conf.d/99-limit.conf und folgendem Inhalt:

[Journal]
  SystemMaxUse=50M
  SystemKeepFree=200M
  MaxRetentionSec=1week

Danach sudo systemctl restart systemd-journald – ab sofort wächst das Journal nicht mehr über 50 MB hinaus. Wer umgekehrt unter Trixie wieder dauerhafte Logs möchte, setzt in derselben Datei Storage=persistent, sollte dann aber die Größenbegrenzung erst recht nicht weglassen.

Klassische Logdateien rotieren lassen. Dienste wie Webserver, Pi-hole oder Datenbanken schreiben eigene Dateien nach /var/log, um die sich journald nicht kümmert. Dafür ist logrotate zuständig: In /etc/logrotate.d/ liegt für jeden Dienst eine Regel, und Einträge wie rotate 4 plus weekly und compress sorgen dafür, dass höchstens vier komprimierte Wochen aufgehoben werden.

Logs in den Arbeitsspeicher legen. Das Werkzeug log2ram hält /var/log im RAM und schreibt einmal täglich auf den dauerhaften Speicher zurück. Das spart nicht nur Platz, sondern reduziert vor allem die Schreibzugriffe – auf einer Speicherkarte ist das der wirksamste Beitrag zur Lebensdauer. Sinnvoll ist es nur bei ausreichend RAM, und man muss wissen: Bei einem harten Stromausfall gehen die Logs des laufenden Tages verloren. Eine USV entschärft das.

Nutzdaten auslagern. Alles, was von sich aus wächst – Medien, Aufnahmen der Kamera, Downloads, Datenbanken – gehört nicht auf die Systempartition. Eine USB-Festplatte wird über einen Eintrag in /etc/fstab fest eingehängt und liegt damit auch nach einem Neustart am selben Platz; ein vorhandenes NAS lässt sich per Samba einbinden. Wichtig: Der Dienst muss danach auf den neuen Pfad zeigen, sonst schreibt er weiter auf die Karte.

Dateisystem erweitern oder gleich auf SSD umziehen

Zwei Situationen lassen sich nicht wegräumen – da fehlt schlicht Platz. Der erste Fall ist besonders ärgerlich, weil der Platz vorhanden ist: Wurde ein fertiges Abbild auf eine große Karte geschrieben, bleibt die Partition manchmal auf der ursprünglichen Größe stehen – auf einer 128-GB-Karte stehen dann acht Gigabyte zur Verfügung. Der Raspberry Pi Imager erledigt die Anpassung beim ersten Start automatisch, geklonte oder zurückgespielte Karten aber nicht immer.

Die Reparatur ist harmlos: sudo raspi-config aufrufen, unter Advanced Options den Punkt Expand Filesystem auswählen und neu starten. Ohne Menü geht es mit sudo raspi-config --expand-rootfs und anschließendem sudo reboot. Nach dem Neustart zeigt df -h die volle Kapazität.

Der zweite Fall ist die Karte selbst. Unter 32 GB wird es bei jedem ernsthaften Projekt eng, und Karten altern durch Schreibzugriffe – ein Blick auf die Kartenempfehlungen lohnt, wenn es eine Karte bleiben soll. Besser fährt, wer den Systemstart auf eine SSD verlegt: beim Pi 5 über ein M.2-HAT und NVMe, bei älteren Modellen per USB-Boot. Der Gewinn ist doppelt: mehr Platz und ein Speicher, der Dauerschreiben aushält.

Raspberry Pi Speicher voll, obwohl df kaum etwas anzeigt

Manchmal meldet das System „No space left on device", während df -h gemütliche 60 % Belegung ausweist. Dafür gibt es drei bekannte Erklärungen – und für jede eine schnelle Prüfung.

• Gelöschte Dateien, die noch offen sind: Löscht man eine Logdatei, während ein Dienst hineinschreibt, verschwindet nur der Verzeichniseintrag – der Platz bleibt belegt, bis der Prozess die Datei schließt. sudo lsof +L1 listet genau diese Fälle auf, sudo systemctl restart name gibt den Platz frei. Deshalb gilt: Logdateien leeren mit sudo truncate -s 0 datei, nicht löschen.
• Inodes erschöpft: Jedes Dateisystem hat eine feste Zahl an Verwaltungseinträgen. Millionen winziger Dateien – etwa Cache-Schnipsel oder Mail-Warteschlangen – brauchen diese Zahl auf, obwohl in Gigabyte gerechnet noch Platz ist. df -i zeigt die Belegung; steht dort 100 %, hilft nur das Löschen vieler kleiner Dateien.
• Reservierte Blöcke für root: Ext4 hält standardmäßig fünf Prozent der Partition für den Systemverwalter zurück. Normale Benutzer sehen „voll", root kann noch schreiben. Auf einer reinen Datenpartition senkt sudo tune2fs -m 1 /dev/sda1 den Anteil – auf der Systempartition besser nicht.
• Volle Speicherbereiche im RAM: df -h listet auch /run und /dev/shm. Läuft einer davon voll, verhalten sich Programme wie bei einer vollen Platte, obwohl die Karte nichts damit zu tun hat.

Fehler und Stolpersteine beim Aufräumen

• Blind in /var/log löschen: Aktive Logdateien zu entfernen bringt keinen Platz, solange der Dienst sie offen hält, und kann ihn zum Absturz bringen. Immer truncate statt rm verwenden.
• docker volume prune ohne Nachdenken: Der Befehl löscht die Daten von Diensten, die gerade nicht laufen. Datenbanken sind darüber schon verschwunden – vorher docker volume ls ansehen.
• Bis auf den letzten Block leerräumen: Ein Dateisystem ohne Reserve wird langsam und fragmentiert. Zehn bis fünfzehn Prozent freier Platz sollten stehen bleiben, und der Swap-Bereich braucht ebenfalls seinen Platz.
• Nur die Hauptpartition betrachten: Eine volle Boot-Partition zeigt sich erst beim nächsten Kernel-Update – und dann startet der Pi eventuell nicht mehr. df -h /boot/firmware gehört zur Routine.
• Aufräumen bei bereits voller Karte: Ist absolut nichts mehr frei, scheitern sogar apt und manche Editoren. Dann zuerst sudo apt clean ausführen – dieser Befehl braucht selbst keinen Platz.
• Symptome mit Kartendefekt verwechseln: Schreibfehler und plötzlich schreibgeschützte Dateisysteme sind kein Platzproblem, sondern ein Zeichen für eine defekte Karte.
• Kein Backup vor der Aktion: Ein Klon der Karte dauert Minuten und macht jeden Fehlgriff folgenlos.

Häufige Fragen zu vollem Speicher auf dem Raspberry Pi

Wie sehe ich, was den Speicher belegt?
df -h zeigt die Belegung je Partition, sudo ncdu -x / danach die größten Ordner und Dateien in einer durchklickbaren Ansicht. Diese beiden Befehle beantworten die Frage in unter einer Minute.

Ist es gefährlich, die Logs zu löschen?
Nein. Protokolle sind Diagnosematerial, kein Systembestandteil. journalctl --vacuum-size=50M behält die jüngsten Einträge und entfernt nur den Rest – nach einem Fehlerfall sollte man sie allerdings vorher auswerten.

Warum ist meine 128-GB-Karte nur mit 8 GB nutzbar?
Weil die Partition nie auf die volle Kartengröße gebracht wurde – typisch nach dem Zurückspielen eines Abbilds. sudo raspi-config --expand-rootfs und ein Neustart beheben das ohne Datenverlust.

Startet der Raspberry Pi nicht mehr, wenn der Speicher voll ist?
Möglich ist es. Dienste, die beim Start schreiben müssen, scheitern, und eine volle Boot-Partition verhindert das Laden eines neuen Kernels. Meist bleibt das System erreichbar, verhält sich aber unberechenbar.

Wie viel Speicherplatz braucht Raspberry Pi OS wirklich?
Die Lite-Ausgabe kommt mit rund zwei Gigabyte aus, die Desktop-Version belegt deutlich mehr. 16 GB sind die absolute Untergrenze, empfehlenswert sind 64 GB aufwärts.

Was bringt log2ram konkret?
Es verlagert /var/log in den Arbeitsspeicher und schreibt gebündelt einmal am Tag zurück. Das hält die Systempartition frei und senkt die Schreiblast auf der Karte deutlich – der Preis sind ein paar Dutzend Megabyte RAM.

Wie werde ich rechtzeitig gewarnt?
Ein Cronjob kann täglich df auswerten und bei Überschreiten einer Schwelle eine Nachricht schicken. Komfortabler ist eine Überwachung mit Uptime Kuma oder Grafana, die den Verlauf sichtbar macht.

Fazit

Ist der Raspberry Pi Speicher voll, sind in neun von zehn Fällen dieselben drei Ordner schuld – Journal, Paketcache und Docker. Mit ncdu ist die Ursache in zwei Minuten gefunden, mit drei Befehlen sind meist mehrere Gigabyte zurück. Unsere klare Empfehlung geht aber über das Aufräumen hinaus: Setze einmal ein Journal-Limit von 50 MB und leg alles, was wächst, auf externen Speicher – dann tritt das Problem gar nicht erst wieder auf. Und wenn ohnehin Hardware ansteht, lohnt der Schritt zur NVMe-SSD mehr als die nächstgrößere Karte: Sie bringt nicht nur Platz, sondern beendet auch das Thema Schreibverschleiß dauerhaft.

* = Affiliate Link (raspi-config.de ist Teilnehmer des Partnerprogramms von Amazon EU, das zur Bereitstellung eines Mediums für Websites konzipiert wurde, mittels dessen durch die Platzierung von Werbeanzeigen und Links zu Amazon.de Werbekostenerstattung verdient werden kann.)