Podstawy Linux #10: Higiena serwera

Masz serwer VPS, użytkownika z sudo, klucze SSH i zabezpieczenia. Gratulacje — ale to dopiero początek. Serwer to nie “ustaw i zapomnij”. To jak samochód — wymaga regularnych przeglądów, wymiany oleju i tankowania.

Jako administrator odpowiadasz za: – aktualizacje bezpieczeństwa – monitorowanie zasobów (dysk, RAM, CPU) – sprawdzanie czy usługi działają – backupy

Nikt tego za Ciebie nie zrobi. Jeśli zapomnisz o aktualizacjach — serwer stanie się podatny na ataki. Jeśli zapełni się dysk — aplikacje przestaną działać.

Aktualizacje systemu

To najważniejsza rzecz. Rób to minimum raz w tygodniu.

sudo apt update

Pobiera listę dostępnych aktualizacji (nie instaluje niczego — tylko sprawdza co jest nowe).

sudo apt upgrade -y

Instaluje wszystkie dostępne aktualizacje. Flaga -y = zgadzam się automatycznie (bez pytania “tak/nie” przy każdej paczce).

sudo apt autoremove -y

Usuwa pakiety, które były zależnościami ale już nie są potrzebne. Zwalnia miejsce na dysku.

sudo apt autoclean

Czyści cache pobranych pakietów (pliki .deb). Nie wpływa na zainstalowane programy.

💡 Jedna komenda do wszystkiego

Możesz połączyć to w jedną linię:

sudo apt update && sudo apt upgrade -y && sudo apt autoremove -y && sudo apt autoclean

&& oznacza “wykonaj następną komendę tylko jeśli poprzednia się udała”.

⚠️ Restart po aktualizacji jądra

Jeśli po apt upgrade zobaczysz komunikat o restarcie lub plik /var/run/reboot-required istnieje — zrestartuj serwer:

cat /var/run/reboot-required    # sprawdź czy restart potrzebny
sudo reboot

Po restarcie zaloguj się ponownie i sprawdź czy usługi działają.

Automatyczne aktualizacje bezpieczeństwa

Nie chcesz pamiętać o aktualizacjach? Skonfiguruj unattended-upgrades — system sam zainstaluje krytyczne łatki bezpieczeństwa:

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure -plow unattended-upgrades

Wybierz Yes. Od teraz serwer automatycznie instaluje poprawki bezpieczeństwa.

Sprawdź co zostało zainstalowane automatycznie:

cat /var/log/unattended-upgrades/unattended-upgrades.log

💡 Automatyczne != “nie musisz sprawdzać”

Unattended-upgrades instaluje tylko łatki bezpieczeństwa, nie robi pełnego apt upgrade. Nadal powinieneś raz w tygodniu zalogować się i zrobić pełną aktualizację ręcznie. Ale jeśli zapomnisz — przynajmniej krytyczne dziury zostaną załatane.

Sprawdzanie miejsca na dysku

Zapełniony dysk to jedna z najczęstszych przyczyn problemów na serwerze. Aplikacje nie mogą zapisywać logów, bazy danych się zawieszają, Docker nie tworzy kontenerów.

Ile miejsca zostało?

df -h

Szukaj kolumny Use% — jeśli przekracza 80%, czas na czyszczenie.

Co zajmuje najwięcej?

sudo du -sh /var/log/*
sudo du -sh /home/*
sudo du -sh /opt/*

Czyszczenie starych logów systemowych

sudo journalctl --vacuum-time=7d

Usuwa logi starsze niż 7 dni. Bezpieczne — nie wpływa na działanie systemu.

Czyszczenie Dockera

Jeśli używasz Dockera, regularnie czyść nieużywane zasoby:

docker system prune -f

Usuwa zatrzymane kontenery, nieużywane sieci i wiszące obrazy.

⚠️ Ostrożnie z docker system prune -a

Flaga -a usuwa wszystkie nieużywane obrazy (nie tylko wiszące). Jeśli masz obrazy które chcesz zachować ale aktualnie nie mają uruchomionych kontenerów — zostaną usunięte. Bez -a jest bezpieczniej.

📋 Scenariusz: dysk zapełniony w 95%

1. df -h — potwierdzasz problem
2. sudo du -sh /var/log/* — logi zajmują 8 GB
3. sudo journalctl --vacuum-time=3d — natychmiast zwalniasz miejsce
4. docker system prune -f — kolejne MB odzyskane
5. df -h — sprawdzasz efekt

Monitoring zasobów

Kto jest zalogowany?

who

Pokazuje aktualnie zalogowanych użytkowników. Jeśli widzisz kogoś kogo nie znasz — to poważny problem.

w

Jak who, ale pokazuje też co robią i jak długo są zalogowani.

Ile czasu działa serwer?

uptime

Pokaże czas działania i load average (obciążenie). Jeśli load average jest większy niż liczba rdzeni CPU — serwer jest przeciążony.

Pamięć RAM

free -h

Szukaj kolumny available — to ile pamięci jest faktycznie dostępne. Jeśli jest blisko 0 — aplikacje mogą zacząć padać.

Procesy — co zżera zasoby?

htop

Interaktywny podgląd procesów. Sortuj po CPU (klawisz P) lub pamięci (M). Wyjście: q.

💡 Jeśli htop nie jest zainstalowane

sudo apt install htop -y

Alternatywa wbudowana: top (mniej czytelne ale zawsze dostępne).

Sprawdzanie usług

Status usługi

sudo systemctl status docker
sudo systemctl status ssh
sudo systemctl status fail2ban

Szukaj Active: active (running) — to znaczy że działa. Jeśli widzisz failed lub inactive — coś jest nie tak.

Restart usługi

sudo systemctl restart docker

Logi usługi — co się stało?

# Ostatnie logi:
sudo journalctl -u docker --since "1 hour ago"

# Logi na żywo (jak tail -f):
sudo journalctl -u docker -f

📋 Scenariusz: aplikacja w Dockerze nie działa

1. sudo systemctl status docker → sprawdzasz czy Docker działa
2. docker ps -a → widzisz że kontener się restartuje lub jest zatrzymany
3. docker logs nazwa-kontenera → widzisz błąd
4. Naprawiasz config → docker compose up -d → działa

Kontrola bezpieczeństwa

Kto próbował się włamać?

sudo fail2ban-client status sshd

Pokaże ile IP jest zablokowanych i ile było prób.

Kto się logował?

# Udane logowania:
last | head -20

# Nieudane logowania:
sudo lastb | head -20

Jeśli widzisz udane logowanie z nieznanego IP — natychmiast zmień hasła i sprawdź co się wydarzyło.

Prosty backup

Backup to Twoje ubezpieczenie. Nie pytaj “czy” coś się zepsuje — pytaj “kiedy”.

Ręczny backup katalogów

Przykład — dostosuj ścieżki do swoich katalogów:

sudo tar -czf /root/backup-$(date +%Y%m%d).tar.gz /opt/moje-aplikacje /etc/nginx

• -czf — kompresuj (gzip) i zapisz do pliku
• $(date +%Y%m%d) — data w nazwie pliku (np. backup-20260212.tar.gz)

Automatyczny backup przez cron

sudo crontab -e

💡 Przy pierwszym uruchomieniu crontab -e może zapytać o wybór edytora. Wybierz nano** (najłatwiejszy) — zwykle opcja 1.**

Dodaj linię na końcu:

0 3 * * 0 tar -czf /root/backup-$(date +\%Y\%m\%d).tar.gz /opt/moje-aplikacje /etc/nginx

⚠️ Dlaczego \% zamiast %?

W crontab znak % ma specjalne znaczenie (oznacza nową linię). Dlatego trzeba go poprzedzić \ — inaczej komenda się nie wykona. W terminalu piszesz normalnie %Y%m%d, ale w crontab zawsze \%Y\%m\%d.

To uruchomi backup co niedzielę o 3:00 w nocy.

💡 Jak czytać cron?

minuta godzina dzień_miesiąca miesiąc dzień_tygodnia komenda
0      3      *              *       0               tar ...

* = każdy. 0 w dniu tygodnia = niedziela.

⚠️ Backup na tym samym serwerze to nie backup!

Jeśli padnie dysk serwera — stracisz i dane i backup. Kopiuj backupy na zewnątrz:

scp /root/backup-20260212.tar.gz roman@INNY_SERWER:/backupy/

Lub skonfiguruj automatyczne kopiowanie do chmury (np. rclone + Google Drive/S3).

Checklist higieny serwera

Co tydzień (minimum)

• sudo apt update && sudo apt upgrade -y — aktualizacje
• df -h — sprawdź miejsce na dysku
• sudo fail2ban-client status sshd — ile prób włamań

Co miesiąc

• sudo apt autoremove -y && sudo apt autoclean — czyszczenie
• sudo journalctl --vacuum-time=7d — czyszczenie logów
• docker system prune -f — czyszczenie Dockera (jeśli używasz)
• last | head -20 — przejrzyj kto się logował
• Sprawdź czy backup działa i plik istnieje
• cat /var/run/reboot-required — czy potrzebny restart

Gdy coś nie działa

1. sudo systemctl status USŁUGA — czy usługa żyje?
2. sudo journalctl -u USŁUGA --since "1 hour ago" — co mówią logi?
3. df -h — czy nie zapełnił się dysk?
4. free -h — czy jest pamięć?
5. htop — czy coś nie zjada CPU?

💡 Pierwszy krok po zalogowaniu na serwer

Warto wyrobić nawyk: zaraz po ssh moj-serwer odpal szybki “health check”:

uptime && free -h && df -h /

Trzy komendy w jednej linii — czas działania, pamięć, dysk. 2 sekundy i wiesz czy wszystko OK.