Jak bezpiecznie wyczyścić serwer Linux bez zakłócania działania usług

Poziom: średniozaawansowany (systemy produkcyjne)
Szacowany czas: ~30 minut
Cel: Zwolnienie miejsca na dysku serwera z systemem Linux poprzez usunięcie nieużywanych pakietów, starych jąder, nieaktualnych logów i plików z pamięci podręcznej — bez wyłączania działających usług.

W niniejszym przewodniku założono, że masz dostęp przez SSH do serwera VPS w środowisku produkcyjnym lub zbliżonym do produkcyjnego. Nie wykonuj tych czynności na ślepo na systemach krytycznych bez utworzonych kopii zapasowych.

Wprowadzenie

Z biegiem czasu nawet rzadko używany serwer VPS gromadzi zbędne dane: osierocone pakiety, przestarzałe jądra, gigabajty nieprzetworzonych logów oraz resztki pamięci podręcznej pakietów. Jeśli nie zadbasz o to, zapełniony dysk spowoduje awarię serwera WWW, uniemożliwi zapisywanie danych w bazie danych i zapełni kolejkę poczty. Ten przewodnik po czyszczeniu systemu Linux pokazuje, jak bezpiecznie oczyścić serwer Linux – najpierw sprawdzając wykorzystanie dysku, usuwając to, co można bezpiecznie usunąć, a następnie weryfikując, czy usługi przetrwały ten proces. Każde z przedstawionych tutaj poleceń można bezpiecznie wykonać na serwerze produkcyjnym bez przestoju.

Co należy wyczyścić

Kategoria	Przykłady	Typowe oszczędności
Nieużywane pakiety i zależności	Osierocone biblioteki, zastąpione sterowniki	100 MB – 2 GB
Stare jądra	Poprzednie wersje jądra	200 MB na jądro
Pamięć podręczna pakietów	Pobrane pliki .deb / .rpm	500 MB – 5 GB
Dzienniki	Archiwa logów systemd	100 MB – 10 GB
Pliki dziennika podlegające rotacji	/var/log/*.gz, *.1	Różne

Wymagania wstępne

Przed rozpoczęciem upewnij się, że spełnione są następujące warunki:

• System operacyjny: Ubuntu 24.04/26.04 LTS, Debian 13 lub AlmaLinux 10
• Dostęp: uprawnienia sudo lub root do serwera przez SSH
• Wymagana wiedza: biegła obsługa terminala systemu Linux i podstawowa znajomość nawigacji w wierszu poleceń
• Kopia zapasowa: Zawsze twórz migawkę lub kopię zapasową przed zbiorczym usuwaniem pakietów na serwerze produkcyjnym. W serwisie INTROSERV możesz zamówić pełną kopię zapasową bezpośrednio z Panelu klienta.

Nie kontynuuj, jeśli spełniony jest którykolwiek z poniższych warunków:

• Partcja/ jest zapełniona w ponad 95% — system może już nie akceptować operacji zapisu. Najpierw należy usunąć bezpośrednią przyczynę (ręcznie znaleźć i usunąć pojedynczy duży plik).
• Usługi są już wyłączone lub działają w nieoczekiwany sposób. Przed czyszczeniem należy zbadać przyczynę źródłową, aby uniknąć zakłócenia działania usług, od których zależą systemy Linux.
• Nie masz kopii zapasowej ani migawki. Najpierw je utwórz — w serwisie INTROSERV zajmuje to mniej niż 2 minuty z poziomu Strefy Klienta.

Krok 1: Sprawdź wykorzystanie dysku przed rozpoczęciem

Poziom ryzyka: NISKI – wyłącznie polecenia tylko do odczytu. Nic nie zostanie zmodyfikowane.

Nigdy nie czyść na ślepo. Najpierw sprawdź, co faktycznie zajmuje miejsce.

1.1 Sprawdź ogólne wykorzystanie dysku

Uruchom polecenie `df`, aby sprawdzić wykorzystanie dysku na poziomie systemu plików:

df -h

Przewidywany wynik:

Filesystem      Size  Used Avail Use% Mounted on
/dev/vda1        40G   34G  3.8G  90% /
tmpfs           1.0G     0  1.0G   0% /dev/shm

Wykorzystanie partycji / powyżej 80% stanowi sygnał ostrzegawczy. Powyżej 95% usługi zaczną zawodzić.

1.2 Znajdź największych konsumentów miejsca

Użyj polecenia `du`, aby przeanalizować zawartość katalogów. Zacznij od katalogu głównego i przechodź w dół:

sudo du -h --max-depth=1 / 2>/dev/null | sort -rh | head -20

Poniżej przedstawiono 20 największych katalogów w katalogu głównym /. Najczęstszymi winowajcami są katalogi /var/log, /var/cache, /usr i /home.

Zawęź listę jeszcze bardziej:

sudo du -h --max-depth=1 /var/log | sort -rh | head -10

1.3 Sprawdź wykorzystanie i-węzłów

Miejsce na dysku nie jest jedynym ograniczeniem. I-węzły śledzą liczbę plików. Partycja może mieć wolne miejsce, ale może zabraknąć i-węzłów, co również spowoduje niepowodzenie operacji zapisu.

df -i

Oczekiwany wynik:

Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda1      2621440 210543 2410897    9% /

Jeśli wartość IUse% przekracza 80%, prawdopodobnie masz katalog zawierający dziesiątki tysięcy małych plików — często jest to kolejka poczty, katalog sesji lub pamięć podręczna PHP. Użyj polecenia du --inodes, aby go znaleźć:

sudo du --inodes -h --max-depth=2 /var | sort -rh | head -10

Krok 2: Usuń nieużywane pakiety i zależności

Poziom ryzyka: ŚREDNI — usunięcie pakietów można cofnąć za pomocą historii menedżera pakietów, ale przed potwierdzeniem należy przejrzeć listę.

Najbezpieczniej jest usunąć nieużywane pakiety. Zajmują one miejsce na dysku, nie obsługują żadnych uruchomionych procesów, a w niektórych przypadkach zawierają niezałatane luki CVE.

2.1 Ubuntu / Debian — apt autoremove

apt autoremove usuwa pakiety, które zostały zainstalowane jako zależności, ale nie są już potrzebne do działania żadnego programu:

sudo apt autoremove --purge -y

Opcja --purge usuwa również pozostałe pliki konfiguracyjne. Bez niej plik binarny pakietu zostanie usunięty, ale pliki konfiguracyjne pozostaną na swoim miejscu.

Oczekiwany wynik:

The following packages will be REMOVED:
  libfoo1 libbar2 old-driver-utils ...
0 upgraded, 0 newly installed, 8 to remove and 0 not upgraded.

2.2 AlmaLinux / RHEL — dnf autoremove

sudo dnf autoremove -y

Na starszych systemach RHEL 7 / CentOS 7 należy użyć polecenia yum autoremove:

sudo yum autoremove -y

2.3 Wyczyść pamięć podręczną pakietów

Po aktualizacjach i instalacjach menedżery pakietów przechowują pobrane pliki archiwów lokalnie. Po zakończeniu instalacji można je bezpiecznie usunąć.

Ubuntu / Debian:

sudo apt clean

Spowoduje to usunięcie wszystkich plików .deb z pamięci podręcznej z katalogu /var/cache/apt/archives/. Aby usunąć tylko pakiety, które nie są już dostępne w repozytorium (wersje zastąpione):

sudo apt autoclean

AlmaLinux / RHEL:

sudo dnf clean all

Oczekiwany wynik:

16 files removed

Krok 3: Usuń stare jądra

Poziom ryzyka: WYSOKI — usunięcie niewłaściwego jądra spowoduje, że serwer nie będzie się uruchamiał po następnym restarcie. Przed kontynuowaniem zawsze sprawdź wynik polecenia uname -r.

Każda aktualizacja jądra pozostawia poprzednią wersję jako zabezpieczenie. Po upewnieniu się, że serwer działa stabilnie na nowym jądrze, można bezpiecznie usunąć stare jądra — każde z nich zwykle zwalnia 200–400 MB.

3.1 Sprawdź, które jądro jest uruchomione

Nigdy nie usuwaj jądra, z którego aktualnie uruchomiono system:

uname -r

Oczekiwany wynik:

5.15.0-105-generic

3.2 Wyświetl listę wszystkich zainstalowanych jąder

Ubuntu / Debian:

dpkg -l | grep linux-image | awk '{print $2}'

Oczekiwany wynik:

linux-image-5.15.0-100-generic
linux-image-5.15.0-105-generic
linux-image-generic

Nie wolno usuwać metapakietu — śledzi on aktualnie zalecane jądro:

• Ubuntu: linux-image-generic
• Debian: linux-image-amd64
• AlmaLinux: Nie jest używany żaden metapakiet, opiera się on na opcji installonly_limit w dnf.

Należy usunąć wyłącznie konkretne pakiety z określoną wersją, które nie odpowiadają aktualnemu jądru.

AlmaLinux / RHEL:

rpm -q kernel

Oczekiwany wynik:

kernel-5.14.0-284.11.1.el9_2.x86_64
kernel-5.14.0-362.8.1.el9_3.x86_64

3.3 Usuń stare jądra

Ubuntu / Debian — metoda automatyczna:

Polecenie apt autoremove z kroku 2 już zajmuje się starymi jądrem w systemie Ubuntu, jeśli zainstalowany jest pakiet linux-image-generic. Można również wskazać je wyraźnie. Należy zastąpić wersję tą, którą chcesz usunąć (nie tą aktualnie uruchomioną):

sudo apt remove --purge linux-image-5.15.0-100-generic -y

AlmaLinux / RHEL:

Menedżer pakietów dnf zachowuje konfigurowalną liczbę starych jąder. Ustaw limit w pliku /etc/dnf/dnf.conf:

sudo nano /etc/dnf/dnf.conf

Dodaj lub zaktualizuj wiersz:

installonly_limit=2

Następnie uruchom:

sudo dnf remove $(dnf repoquery --installonly --latest-limit=-1 -q)

Spowoduje to usunięcie wszystkich jąder z wyjątkiem dwóch najnowszych.

Krok 4: Wyczyść dzienniki

Poziom ryzyka: NISKI — usuwa wyłącznie zarchiwizowane wpisy dziennika. Nie ma to wpływu na uruchomione usługi.

systemd-journald gromadzi logi ze wszystkich usług w systemie. Domyślnie jego rozmiar może rosnąć bez ograniczeń, aż osiągnie limit miejsca na dysku – lub gdy limit ten osiągnie zero.

4.1 Sprawdź aktualny rozmiar dziennika

journalctl --disk-usage

Oczekiwany wynik:

Archived and active journals take up 2.3G in the filesystem.

4.2 Oczyść dziennik

Aby zachować tylko logi z ostatnich 7 dni:

sudo journalctl --vacuum-time=7d

Aby zachować tylko ostatnie 500 MB:

sudo journalctl --vacuum-size=500M

Oczekiwany wynik:

Deleted archived journal /var/log/journal/.../[email protected] (64.0M).
Vacuuming done, freed 1.8G of archived journals from /var/log/journal/.

4.3 Zapobieganie przyszłemu powiększaniu się dziennika

Utwórz plik konfiguracyjny typu „drop-in”, aby trwale ograniczyć rozmiar dziennika (w systemie AlmaLinux 10 główny plik konfiguracyjny i tak domyślnie nie znajduje się w katalogu /etc/, co sprawia, że jest to standardowe podejście):

sudo mkdir -p /etc/systemd/journald.conf.d
sudo tee /etc/systemd/journald.conf.d/99-size.conf <<EOF
[Journal]
SystemMaxUse=500M
MaxRetentionSec=30day
EOF

Zastosuj zmianę:

sudo systemctl restart systemd-journald

Krok 5: Usuń rotowane i stare pliki dziennika

Poziom ryzyka: ŚREDNI — usuwane są wyłącznie skompresowane archiwa. Nie należy dotykać plików bez rozszerzenia .gz ani numerycznego sufiksu.

Logi aplikacji w katalogu /var/log/ są zarządzane przez logrotate. Zazwyczaj logrotate zachowuje określoną liczbę rotowanych kopii i automatycznie je kompresuje. Jeśli logrotate został nieprawidłowo skonfigurowany lub nie działał, można napotkać duże nagromadzenia plików z rozszerzeniami .gz, .1, .2.

5.1 Wyszukiwanie dużych plików dziennika

find /var/log -type f -name "*.gz" -o -name "*.log" | xargs du -sh 2>/dev/null | sort -rh | head -20

Lub po prostu:

sudo du -h /var/log | sort -rh | head -20

5.2 Usuń stare skompresowane archiwa logów

Skompresowane, rotowane pliki dziennika (.gz) można bezpiecznie usunąć. Są to archiwa już zamkniętych plików dziennika.

Najpierw sprawdź, co zostanie usunięte — uruchom program bez opcji -delete, aby wyświetlić listę:

sudo find /var/log -name "*.gz" -mtime +30

Jeśli wynik wygląda poprawnie, uruchom faktyczne usuwanie:

sudo find /var/log -name "*.gz" -mtime +30 -delete

Spowoduje to usunięcie archiwów logów .gz starszych niż 30 dni.

5.3 Sprawdź, czy logrotate jest poprawnie skonfigurowany

Sprawdź, które usługi mają konfiguracje logrotate:

ls /etc/logrotate.d/

Uruchom logrotate ręcznie w trybie debugowania, aby upewnić się, że działa bez błędów:

sudo logrotate -d /etc/logrotate.conf

Flaga -d oznacza symulację — nic nie zostanie zmienione, ale zobaczysz dokładnie, co by się stało. Jeśli w katalogu /etc/logrotate.d/ brakuje jakiejś usługi, utwórz dla niej konfigurację. Pełne instrukcje dotyczące konfiguracji logrotate znajdziesz w przewodniku po rotacji logów.

Krok 6: Usuń pliki tymczasowe

Poziom ryzyka: ŚREDNI — sesje PHP i pamięci podręczne aplikacji mają wpływ na aktywnych użytkowników. Przed usunięciem wyświetl podgląd.

6.1 Oczyszczenie katalogu /tmp

W większości dystrybucji katalog /tmp jest czyszczony przy ponownym uruchomieniu systemu. Jeśli serwer działa od miesięcy, mogły w nim zgromadzić się duże pliki tymczasowe:

du -sh /tmp

Aby usunąć pliki starsze niż 7 dni, najpierw sprawdź ich zawartość:

sudo find /tmp -type f -mtime +7

Jeśli lista wygląda na bezpieczną, uruchom usuwanie:

sudo find /tmp -type f -mtime +7 -delete

6.2 Oczyszczanie pamięci podręcznych aplikacji

Wiele aplikacji tworzy własne pamięci podręczne. Sprawdź te typowe lokalizacje (uwaga: upewnij się, że katalogi te istnieją w Twoim systemie; w czystym systemie mogą one nie występować i pojawi się błąd „Nie ma takiego pliku lub katalogu”):

# PHP session files (often forgotten, if installed)
sudo du -sh /var/lib/php/sessions/

# Pip / Python package caches (if running as root and installed)
sudo du -sh /root/.cache/pip/

# npm cache (if node is installed system-wide)
sudo du -sh /root/.npm/

Katalogi te można bezpiecznie wyczyścić, jeśli aplikacja nie korzysta z nich aktywnie.

Krok 7: Sprawdź, czy usługi nadal działają

Poziom ryzyka: NISKI – weryfikacja w trybie tylko do odczytu. Wykonaj to po każdym kroku, a nie tylko na końcu.

Po każdym cyklu czyszczenia upewnij się, że usługi nadal działają. Zrób to przed zamknięciem sesji SSH.

7.1 Sprawdź status usług krytycznych

Sprawdź tylko te usługi, które są faktycznie zainstalowane na serwerze (w czystym systemie sprawdzenie nginx lub mysql zwróci komunikat „Unit not found”).

Ubuntu / Debian:

systemctl status nginx
systemctl status mysql
systemctl status ssh

AlmaLinux / RHEL:

systemctl status nginx
systemctl status mysqld
systemctl status sshd

Każda z nich powinna wyświetlać status „Active: active (running)”. Jeśli któraś z nich wyświetla status „failed” lub „inactive”, sprawdź jej logi:

journalctl -u nginx --since "10 minutes ago"

7.2 Sprawdź, czy zużycie miejsca na dysku uległo poprawie

df -h

Porównaj kolumnę „Use%” z danymi z kroku 1. Zmiana powinna odzwierciedlać zwolnione miejsce.

7.3 Przetestuj swoją aplikację

Jeśli korzystasz z serwera WWW, wyślij żądanie testowe:

curl -I http://localhost

Oczekiwany wynik:

HTTP/1.1 200 OK
Server: nginx/1.24.0

Kod 200 OK potwierdza, że serwer nginx obsługuje ruch sieciowy prawidłowo.

Rozwiązywanie problemów

Po usunięciu pakietów polecenie `df` nie wykazuje żadnej poprawy

Usunięcie pakietów natychmiast zwalnia miejsce. Jeśli wartość ` df` nie uległa zmianie, oznacza to, że pliki są nadal otwarte. Znajdź pliki otwarte, ale usunięte:

sudo lsof | grep deleted

Uruchom ponownie usługę, która utrzymuje plik w stanie otwartym, a miejsce zostanie odzyskane.

`apt autoremove` próbuje usunąć coś, co wygląda na ważne

Przeczytaj listę uważnie. Jeśli zauważysz nazwę pakietu, który rozpoznajesz jako zależność uruchomionej usługi, naciśnij klawisz N i sprawdź to. Uruchom polecenie ` apt-cache rdepends <pakiet> `, aby sprawdzić, co od niego zależy.

`journalctl --vacuum-time` nie powoduje żadnych zmian

Dziennik może być już mniejszy niż docelowa wielkość. Sprawdź to za pomocą polecenia `journalctl --disk-usage`. Upewnij się również, że dziennik jest trwały: sprawdź, czy istnieje katalog `/var/log/journal/`. Jeśli istnieje tylko katalog `/run/log/journal/`, dziennik jest przechowywany w pamięci RAM i jest automatycznie czyszczony po ponownym uruchomieniu systemu.

Usługa nie działa po wykonaniu polecenia `apt autoremove`

Uruchom polecenie `systemctl status <usługa> ` i sprawdź błąd. Jeśli usunięto bibliotekę współdzieloną, zainstaluj ponownie pakiet, który ją udostępnia:

sudo apt install --fix-broken

Brak wolnych i-węzłów pomimo wolnego miejsca na dysku

Znajdź katalog zawierający najwięcej plików:

find / -xdev -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head -10

Najczęstsze przyczyny: kolejki poczty w katalogu /var/spool/mail, sesje PHP w katalogu /var/lib/php/sessions lub niekontrolowane zadanie cron tworzące pliki tymczasowe.

Cofnięcie zmian

Większość operacji porządkujących jest nieodwracalna — usunięte pliki są bezpowrotnie utracone. Dlatego etap tworzenia kopii zapasowej opisany w sekcji „Wymagania wstępne” jest obowiązkowy.

W przypadku usunięcia pakietów można ponownie zainstalować to, co zostało usunięte:

Ubuntu / Debian:

sudo apt install <package-name>

AlmaLinux / RHEL:

sudo dnf install <package-name>

Aby wyświetlić historię elementów usuniętych w bieżącej sesji:

Ubuntu / Debian:

cat /var/log/dpkg.log | grep "^$(date +%Y-%m-%d)" | grep " remove "

AlmaLinux / RHEL:

sudo dnf history list
sudo dnf history undo last

Polecenie `dnf history undo last` przywraca pakiety usunięte podczas ostatniej transakcji — jest to przydatne narzędzie do przywracania, jeśli funkcja ` autoremove ` posunęła się dalej niż zamierzano.

Wniosek

Czyszczenie serwera z systemem Linux bez przestojów sprowadza się do trzech rzeczy: najpierw zmierz, usuwaj tylko to, co system potwierdzi jako nieużywane, i sprawdzaj działanie usług po każdym kroku. Przed podjęciem jakichkolwiek działań uruchom polec enia `df -h ` i `du`. Użyj poleceń `apt autoremove ` / `yum autoremove ` dla nieużywanych pakietów, ` journalctl --vacuum-time ` do czyszczenia dzienników oraz `find /var/log -name "*.gz" ` do wyszukiwania starych, wyrotowanych archiwów. Usuń stare jądra dopiero po upewnieniu się, że wynik polecenia ` uname -r ` zgadza się z tym, które chcesz zachować. Zawsze sprawdzaj status za pomocą `systemctl status ` przed zamknięciem terminala.

W przypadku serwera VPS INTROSERV praktycznym celem jest utrzymanie wykorzystania katalogu / poniżej 80% — pozostawia to miejsce na nagłe wzrosty objętości logów i aktualizacje pakietów bez konieczności interwencji awaryjnej. Jeśli miejsce na dysku stanowi powracający problem, rozważ zmianę rozmiaru przestrzeni dyskowej serwera VPS bezpośrednio z Panelu Klienta INTROSERV.

Wersja dokumentu: 1.0
Ostatnia aktualizacja: maj 2026
Właściciel: Zespół ds. dokumentacji technicznej