Brak miejsca na dysku serwera to jedna z najczęstszych i najbardziej stresujących sytuacji, z jaką mierzy się administrator. System przestaje zapisywać logi, usługi padają jedna po drugiej, a SSH potrafi się rozłączyć w kluczowym momencie. Brzmi znajomo?
W tym wpisie pokażę Ci, jak podejść do tego metodycznie — krok po kroku, z użyciem przydatnych narzędzi.
Krok 1: Sprawdź, jak bardzo jest źle
Pierwsze, co należy zrobić, to określić skalę problemu. Czy miejsca brakuje na całym systemie, czy tylko na jednej partycji? Odpowiedź daje dobrze znane polecenie:
df -hTo narzędzie pokazuje przestrzeń dyskową dla wszystkich zamontowanych systemów plików w przystępnej, „ludzkiej” postaci (dzięki -h, czyli „human-readable”).
Alternatywa: duf – nowoczesny i przejrzysty
Jeśli chcesz czegoś bardziej czytelnego wizualnie, spróbuj duf:
dufduf (disk usage/free) to estetyczna, kolorowa wersja df. Podaje te same informacje, ale w tabeli z nagłówkami, ułatwiając szybką analizę przestrzeni. Obsługuje nawet dyski sieciowe (NFS, SMB), dzięki czemu świetnie sprawdza się w złożonych środowiskach serwerowych.
Dzięki temu połączeniu użytkownik ma wybór: klasyczne, uniwersalne df, lub wygodne, czytelne duf — w zależności od preferencji i kontekstu pracy.
Krok 2: Znajdź winowajców – czyli co zjada miejsc
Sam df nie mówi nam gdzie dokładnie leży problem. Dlatego sięgamy po potężne narzędzie: ncdu.
ncdu – terminalowy eksplorator przestrzeni
ncdu -x /
ncdu to skrót od NCurses Disk Usage. To prosty, ale genialny program działający w trybie tekstowym. W kilka sekund przeskanuje katalog (np. /, /var, /home) i przedstawi zawartość w postaci interaktywnej listy posortowanej według rozmiaru.
Dzięki niemu błyskawicznie znajdziesz katalogi, które pochłaniają najwięcej miejsca, a potem możesz je przeglądać i zgłębiać – aż do poziomu pojedynczego pliku. Narzędzie to działa błyskawicznie i nie wymaga GUI, co czyni je idealnym do pracy zdalnej przez SSH.
Krok 3: Logi
Wiele dystrybucji Linuksa (szczególnie te oparte na systemd) gromadzi logi bez większych ograniczeń. Jeśli nie masz aktywnego systemu rotacji lub automatycznego czyszczenia – mogą zajmować kilka, a nawet kilkadziesiąt gigabajtów.
Do porządków służy:
journalctl --vacuum-size=100Mlub, jeśli wolisz czyścić wg daty:
journalctl --vacuum-time=7dKrok 4: Wymuś rotację logów
Jeśli korzystasz z logrotate, ale masz podejrzenia, że coś nie działa automatycznie, możesz rotację logów uruchomić ręcznie:
logrotate -vf /etc/logrotate.conf
To wymusi natychmiastową rotację zgodnie z Twoją konfiguracją – szczególnie przydatne, jeśli masz wielkie pliki .log, które nie zostały podzielone.
Krok 5: Szukanie największych plików
Nie zawsze to katalogi są problemem — czasem wystarczy jeden plik dumpa MySQL albo paczka .tar.gz, która została zapomniana. Szukamy ich tak:
du -x -h / | sort -hr | head -n 20Ten zestaw komend pokaże 20 największych elementów na dysku — przydaje się, gdy trzeba szybko „uderzyć” w problematyczny plik.
Alternatywa GUI: baobab
Dla administratorów pracujących lokalnie lub na desktopowym Linuksie istnieje świetna alternatywa wizualna – Baobab, czyli Disk Usage Analyzer.
Co oferuje baobab?
- Skany całego systemu plików w formie graficznego wykresu kołowego (lub drzewa),
- Możliwość szybkiego wejścia do konkretnego katalogu lub pliku,
- Kolorową wizualizację, która niemal natychmiast pokazuje, co zajmuje najwięcej miejsca.
Idealne narzędzie do pracy z laptopa, dla mniej terminalowo nastawionych użytkowników lub do szybkiego przeglądu systemu w środowiskach graficznych (np. Pop!_OS, Ubuntu Desktop).
Krok 7: Ukryci pożeracze miejsca – pliki deleted trzymane przez procesy
zasami zdarza się, że mimo usunięcia dużego pliku (np. logu, dumpa bazy), miejsce nadal nie wraca. Dlaczego? Bo plik został usunięty z systemu plików, ale jakiś proces nadal go trzyma otwartego. Taki plik nadal zajmuje miejsce, mimo że „niby” go nie ma.
Do ich wykrywania służy genialne narzędzie:
lsof | grep deletedlsof (List Open Files) pokazuje wszystkie otwarte pliki i zasoby przez procesy w systemie.
lsof(List Open Files) pokazuje wszystkie otwarte pliki i zasoby przez procesy w systemie.grep deletedfiltruje wyniki, by pokazać tylko pliki, które zostały usunięte, ale nadal są „żywe” w RAM/deskryptorach plików
Krok 6: Sprawdzenie baz danych (MySQL/MariaDB)
Jeśli na serwerze działają bazy danych, warto sprawdzić ich rozmiary — czasem to właśnie one są winowajcą.
SELECT table_schema "DB Name",
ROUND(SUM(data_length + index_length) / 1024 / 1024, 1) "DB Size in MB"
FROM information_schema.tables
GROUP BY table_schema;Dzięki temu łatwo zidentyfikujesz bazy, które zjadają gigabajty – i zdecydujesz, czy warto je zarchiwizować, oczyścić lub zoptymalizować.
