Czy 'docker system prune -a' jest bezpieczne?

Usuwa zatrzymane kontenery, nieużywane sieci, osierocony cache buildów i każdy obraz, którego nie używa działający kontener. Dane zostają, chyba że dodasz --volumes. Z --volumes kasuje też nieużywane wolumeny — a wolumen zatrzymanego kontenera z bazą danych liczy się jako nieużywany. Pomiń tę flagę, jeśli nie masz pewności.

Usunąłem wielki log, a df dalej pokazuje pełny dysk. Dlaczego?

Działający proces wciąż trzyma plik otwarty, więc jądro nie zwalnia miejsca. Znajdź go przez 'lsof +L1' i zrestartuj tę usługę. Następnym razem opróżnij aktywny log poleceniem 'truncate -s 0 plik' zamiast go kasować.

Ile wolnego miejsca warto zostawić?

Co najmniej 10–15%. Bazy danych, aktualizacje pakietów i pobieranie obrazów Dockera potrzebują miejsca tymczasowego, a dysk zapełniony w 100% może uszkodzić bazę w trakcie zapisu.

Czy mogę powiększyć dysk bez reinstalacji?

Tak. Przejście na większy plan powiększa dysk w miejscu i zachowuje dane — Nano ma 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Upgrade raz restartuje serwer.

Co zwykle zapycha mały VPS?

Z naszego doświadczenia: obrazy i cache buildów Dockera, journal systemd, logi aplikacji, których nikt nie rotuje, oraz zapomniane zrzuty baz i archiwa kopii w /root.

Jak zwolnić miejsce na dysku VPS i niczego nie zepsuć

Pełny dysk na VPS? Sprawdź du i ncdu, co zajmuje miejsce, a potem wyczyść cache apt, journal, resztki Dockera i logi bez utraty danych.

"No space left on device" nigdy nie pojawia się w dogodnym momencie. Baza danych przestaje przyjmować zapisy, apt nie może dokończyć aktualizacji, a Docker odmawia pobrania obrazu, którego potrzebujesz właśnie teraz. Dobra wiadomość: na małym VPS winowajcą prawie zawsze jest jedna z pięciu rzeczy i znajdziesz ją w dwie minuty.

1. Jak jest źle?

df -h /
df -i /

Pierwsza linia pokazuje zajęte miejsce. Druga — i-węzły (inodes): jeśli i-węzły dobiły do 100%, a miejsca niby jest dość, masz miliony malutkich plików (pliki sesji, kolejka poczty, katalog cache). Inny problem, ten sam objaw.

2. Znajdź, co jest duże

Przejdź drzewo od góry i posortuj według rozmiaru:

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x trzyma się jednego systemu plików, więc nie zabłądzi do /proc. Potem wejdź w to, co największe. Do interaktywnego przeglądania ncdu jest dużo wygodniejsze:

apt install -y ncdu
ncdu -x /

Strzałki do nawigacji, d do kasowania. Z tym ostatnim ostrożnie.

3. Szybkie wygrane

Są bezpieczne na każdym serwerze z Ubuntu lub Debianem:

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove usuwa też stare jądra. Journal systemd to ten, który zaskakuje wszystkich — zostawiony sam sobie potrafi urosnąć do kilku gigabajtów. Żeby ograniczyć go na stałe, ustaw SystemMaxUse=200M w /etc/systemd/journald.conf i uruchom systemctl restart systemd-journald.

4. Resztki po Dockerze

Jeśli używasz Dockera, zajrzyj tu najpierw. Stare obrazy i cache buildów rosną z każdym wdrożeniem:

docker system df
docker image prune -a
docker builder prune

docker image prune -a kasuje obrazy, których nie używa żaden działający kontener. Zwykle o to chodzi, ale następne wdrożenie pobierze je ponownie.

Niebezpieczne jest docker system prune -a --volumes. Wolumeny przechowują twoje dane, a wolumen podpięty do zatrzymanego kontenera liczy się jako nieużywany. Tak ludzie tracą bazy danych. Nie wklejaj tego z odpowiedzi na forum.

Drugi ukryty pożeracz to logi kontenerów. Ogranicz je w /etc/docker/daemon.json:

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

Potem zrestartuj Dockera. Limit obowiązuje tylko kontenery utworzone później, więc odtwórz te najgłośniejsze przez docker compose up -d --force-recreate.

5. Logi i zapomniane pliki

Znajdź duże pliki w dowolnym miejscu dysku:

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

Typowe znaleziska: backup.tar.gz sprzed pół roku w /root, zrzut bazy, który ktoś miał pobrać, log aplikacji, który nigdy nie jest rotowany.

Logu, do którego usługa wciąż pisze, nie kasuj przez rm — opróżnij go:

truncate -s 0 /var/log/myapp/app.log

Jeśli już jakiś skasowałeś, a miejsce nie wróciło, proces wciąż trzyma go otwarty:

lsof +L1

Zrestartuj wymienioną tam usługę i miejsce wróci.

Gdy sprzątanie nie wystarcza

Czasem dane są po prostu prawdziwe — rosnąca baza, pliki użytkowników, model. Wtedy uczciwe rozwiązanie to więcej dysku. Upgrade planu powiększa dysk w miejscu i zachowuje wszystko: Nano ma 15 GB, Micro 25 GB, Small 35 GB, Medium 45 GB. Serwer restartuje się raz. Szczegóły są w dokumentacji planów.

Jeszcze jedna rzecz, która cicho zjada miejsce: plik swap. Jeśli korzystałeś z naszego poradnika o swapie, te 1–2 GB są tam celowo. A jeśli głównym konsumentem jest Docker, poradnik instalacji Dockera i poradnik o stackach Compose pokazują, jak trzymać obrazy w ryzach.

Nawyk, który zapobiega temu wszystkiemu: ogranicz journal i logi Dockera pierwszego dnia. Dwie linijki konfiguracji i "pełny dysk" praktycznie przestaje się zdarzać.