Lista kontrolna utrzymania serwera Linux

Na czym w rzeczywistości polega utrzymanie serwera Linux

Utrzymanie serwera Linux to krótka lista kontrolna wykonywana według stałego harmonogramu, a nie projekt z określonym terminem zakończenia. Raz w tygodniu należy potwierdzić instalację aktualizacji, dostępność miejsca na dysku, brak awarii usług oraz poprawne zakończenie zadań kopii zapasowych. Raz w miesiącu należy przetestować przywracanie danych, sprawdzić daty ważności certyfikatów, przeprowadzić audyt kont i kluczy oraz usunąć stare jądra i logi. Raz na cykl wydawniczy dystrybucji należy zaplanować aktualizację wersji systemu i wykonać restart, który jest stale odkładany.

Budowa serwera to odrębne zadanie, a pierwsze dziesięć minut na nowym VPS obejmuje ten etap. Niniejsza strona dotyczy okresu eksploatacji po tym czasie. Każdy punkt poniżej wskazuje awarię, której zapobiega, ponieważ lista kontrolna bez określonych konsekwencji jest ignorowana przez administratorów.

Zamieszczone tutaj polecenia mają charakter poglądowy i należy się z nimi zapoznać przed uruchomieniem. Wyniki należy porównać ze stanem własnego serwera, ponieważ wartości dotyczące wolnego miejsca czy liczby procesów zależą od roli maszyny. W miejscach, gdzie procedura różni się w zależności od dystrybucji, zamieszczono stosowne uwagi. Przykłady wykorzystują Debian oraz Ubuntu wraz z apt. W rodzinie RHEL używane jest narzędzie dnf, a wiele ścieżek jest odmiennych.

Jak wybrać harmonogram konserwacji serwera Linux, którego będziesz przestrzegać

Cotygodniowe kontrole obejmują elementy, które zmieniają się bez Twojego udziału: pakiety, wykorzystanie dysku, stan usług oraz zaplanowane zadania. Zmieniają się one samoczynnie, więc tydzień to maksymalny czas, po którym należy sprawdzić ich stan.

Miesięczne kontrole obejmują powolną degradację: certyfikaty zbliżające się do daty wygaśnięcia, nieusunięte konta, jądra gromadzące się w /boot oraz pliki dziennika przekraczające regułę rotacji, która przestała pasować. Żaden z tych elementów nie spowoduje awarii jutro. Wszystkie jednak doprowadzą do niej w końcu.

Kontrole wydań są podyktowane kalendarzem. Wydanie dystrybucji to jedyny element konserwacji z zewnętrznym terminem, ponieważ wsparcie dla bieżącej wersji kończy się niezależnie od Twojej gotowości.

Wyznacz stały czas na wykonanie zadań: poniedziałkowy poranek na przegląd cotygodniowy oraz pierwszy dzień miesiąca na przegląd miesięczny. Lista kontrolna wykonywana „gdy znajdę czas” nie jest listą kontrolną. W przypadku większej liczby maszyn wykonuj te czynności z jednego miejsca zamiast ręcznie, co jest tematem zarządzania wieloma serwerami Linux z jednego miejsca.

Cotygodniowe sprawdzenie: czy aktualizacje faktycznie zostały zainstalowane?

Włączenie unattended-upgrades nie jest równoznaczne z pewnością, że proces został wykonany. Usługa może być zamaskowana (masked), konfiguracja może ograniczać się do źródła, którego nie używasz, a jeden wstrzymany pakiet (held package) może przerwać każde kolejne uruchomienie. Instalacja została opisana w automatyczne aktualizacje bezpieczeństwa w Ubuntu. Cotygodniowe zadanie ma na celu potwierdzenie, że zainstalowane narzędzia wykonały swoją pracę.

systemctl status unattended-upgrades
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
sudo tail -n 50 /var/log/unattended-upgrades/unattended-upgrades.log
apt list --upgradable
apt-mark showhold

apt list --upgradable stanowi wiarygodny wskaźnik, ponieważ raportuje bieżący stan, a nie tylko zamiar. Aktualizacje bezpieczeństwa pozostające na tej liście oznaczają, że automatyzacja nie działa poprawnie, dlatego przed założeniem, że system jest załatany, należy sprawdzić logi. Pakiet przypięty za pomocą apt-mark hold jest pomijany na stałe i nie generuje żadnych powiadomień, dlatego apt-mark showhold powinno być sprawdzane w tym samym cyklu.

Awaria, której zapobiega to działanie: wielomiesięczne korzystanie z pakietu o znanej podatności przy błędnym przekonaniu, że aktualizacje są automatyczne.

Cotygodniowe zadania: zapas miejsca na dysku i liczba i-węzłów

Pełny system plików root powoduje awarie usług, które pozornie nie są związane z zajętością dysku. Baza danych odmawia zapisu, logowanie zostaje przerwane, aktualizacja pakietów kończy się w połowie, a w niektórych konfiguracjach niemożliwe jest otwarcie nowej sesji, ponieważ system nie może zapisać własnych plików tymczasowych.

df -h
df -i
sudo du -xh --max-depth=1 / | sort -h | tail -20

df -i to aspekt, który większość administratorów pomija. I-węzły (inodes) to struktury o stałej liczbie, które przechowują metadane plików. System plików może wyczerpać ich pulę, podczas gdy df -h nadal wykazuje wolne gigabajty. Operacje zapisu kończą się wtedy błędem No space left on device, mimo że polecenie wyświetlające wolne miejsce wskazuje na jego dostępność, co przy pierwszym wystąpieniu tego problemu prowadzi do długotrwałej diagnostyki. Najczęstszą przyczyną są miliony małych plików, na przykład w zablokowanej kolejce pocztowej lub w katalogu sesji, który nie jest regularnie czyszczony.

du -xh działa w obrębie jednego systemu plików, co jest pożądane na serwerach z zamontowanymi zasobami typu bind mounts lub zewnętrznymi nośnikami. Na hoście Docker problem zazwyczaj wynika z warstw obrazów i nieużywanych wolumenów, które należy usunąć zgodnie z opisem w czyszczenie zasobów dyskowych Dockera na VPS.

Wolne miejsce informuje o pojemności. Nośnik danych ulega awarii według własnego harmonogramu, co stanowi osobny obszar kontroli opisany w monitorowanie kondycji dysku na VPS.

Cotygodniowy przegląd: co przestało działać bez powiadomienia?

systemctl list-units --state=failed
systemctl list-timers --all
journalctl -p err --since "8 days ago" --no-pager

Jednostka, która uległa awarii i osiągnęła limit restartów, pozostaje w stanie failed i nie wysyła żadnych powiadomień. list-timers stanowi bardziej użyteczne narzędzie: pokazuje, kiedy dany timer został uruchomiony ostatnio i kiedy nastąpi jego kolejne wyzwolenie. Wartość LAST starsza niż interwał timera oznacza, że zadanie w ogóle nie zostało wykonane.

Przed restartem jednostki należy odczytać jej dziennik za pomocą journalctl -u <unit> -n 100 --no-pager. Restart usuwa objawy awarii, co sprawia, że problem pozostaje niezbadany do momentu, aż sytuacja powtórzy się w mniej dogodnym czasie.

Działanie to zapobiega awariom takim jak: agent monitorujący, proces przetwarzający kolejkę lub usługa kopii zapasowej, które przestały działać w wyniku skoku zużycia pamięci trzy tygodnie temu.

Cotygodniowe sprawdzenie: czy zadanie kopii zapasowej faktycznie się zakończyło?

Zaplanowana kopia zapasowa i ukończona kopia zapasowa to dwie różne kwestie, a tylko jedna z nich pozwala na odtworzenie danych. Należy zweryfikować stan zakończenia zadania.

systemctl list-timers --all | grep -i backup
journalctl -u <your-backup-unit> --since "8 days ago" --no-pager
ls -lh /path/to/backup/target | tail

Należy potwierdzić dwie rzeczy. Ostatnie uruchomienie zakończyło się kodem wyjścia zero, a najnowsze archiwum jest aktualne i ma oczekiwaną wielkość. Plik kopii zapasowej, którego rozmiar nagle spadł do jednej dziesiątej wartości, oznacza nieudany zrzut, który mimo to zapisał plik. Jest to najgroźniejsza postać awarii kopii zapasowej, ponieważ wszystkie kolejne etapy procesu wyglądają na poprawne.

Jeśli skrypt przesyła zrzut do kompresora za pomocą potoku, należy dodać set -o pipefail na początku pliku. Bez tego parametru kod wyjścia potoku jest kodem wyjścia kompresora, a kompresor zakończył działanie poprawnie: skompresował komunikat o błędzie. W rezultacie zadanie każdej nocy zgłasza sukces, zapisując jednocześnie małe archiwum zawierające pustą treść.

Raz w miesiącu: przywracanie kopii zapasowej w innej lokalizacji

Jest to punkt, który większość osób pomija, a decyduje on o tym, czy reszta listy miała jakiekolwiek znaczenie.

Przywróć dane na inną maszynę lub do świeżego kontenera; nigdy nie nadpisuj działających danych. Następnie otwórz przywrócone zasoby i potwierdź ich autentyczność. Policz wiersze w tabeli. Otwórz dokument. Zaloguj się do przywróconej aplikacji. Zakończona ekstrakcja dowodzi jedynie, że archiwum jest możliwe do odczytania, nic więcej.

Narzędzia repozytoriów posiadają własne mechanizmy weryfikacji: restic check --read-data-subset=5% oraz borg check --verify-data odczytują zapisane dane, a nie tylko indeks. Uruchamiaj je, traktując jako test wstępny, a nie zamiennik pełnego przywracania. Weryfikacja sprawdza, czy bajty przetrwały. Przywracanie sprawdza, czy są to bajty, których wymaga aplikacja.

Dwa szczegóły, których ludzie uczą się na własnych błędach. Przetestuj hasło deszyfrujące na maszynie, która nie posiada klucza w agencie, ponieważ kopia zapasowa, której nie można odszyfrować, nie jest kopią zapasową. Zmierz również czas przywracania, ponieważ ten czas to rzeczywisty czas odzyskiwania danych, a najgorszym momentem na jego odkrycie jest trwająca awaria.

Miesięcznie: które certyfikaty wkrótce wygasną?

Automatyzacja odnawiania certyfikatów może zawieść w sposób niezauważalny. Timer certbot może odnowić plik na dysku, podczas gdy serwer WWW nadal serwuje stary certyfikat z pamięci, ponieważ skrypt typu deploy hook odpowiedzialny za przeładowanie usługi nie został uruchomiony. Należy zatem sprawdzić, co serwer faktycznie udostępnia, wykonując zapytanie z zewnątrz.

sudo certbot certificates
systemctl list-timers --all | grep -i certbot
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -dates

Flaga -servername ustawia SNI (Server Name Indication), co jest wymagane na każdym adresie obsługującym więcej niż jedną witrynę. W przeciwnym razie serwer zwróci domyślny certyfikat zamiast właściwego. Jeśli certbot został zainstalowany za pomocą snap, nazwa timera będzie inna, dlatego należy wyszukiwać po słowie kluczowym, a nie po nazwie jednostki, którą założono wcześniej.

Należy pamiętać o certyfikatach, które nie podlegają żadnej automatyzacji: serwer pocztowy, VPN, wewnętrzny urząd certyfikacji. To właśnie one wygasają w weekendy, a przeglądarki oraz klienci odrzucają je całkowicie, zamiast wyświetlać ostrzeżenie.

Miesięczny przegląd: użytkownicy, dostęp sudo i klucze SSH

awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo find /home /root -name authorized_keys -exec ls -l {} +
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|port'
last -n 25

sshd -T wyświetla efektywną konfigurację po scaleniu wszystkich Include, co odzwierciedla faktyczne ustawienia używane przez demona. Nowsze obrazy Ubuntu zawierają pliki uzupełniające w /etc/ssh/sshd_config.d/, które mogą nadpisywać główny plik, dlatego analiza samego sshd_config może prowadzić do błędnych wniosków. W systemach z rodziny RHEL grupą administracyjną jest wheel, a nie sudo, należy więc odpowiednio dostosować linię getent.

Następnie należy przejrzeć same pliki authorized_keys. Dostęp jest przyznawany na podstawie klucza, a nie konta, więc klucz pozostawiony przez wykonawcę, który zakończył współpracę pół roku temu, stanowi aktywne poświadczenie, którego nie wykaże żadna lista użytkowników. Klucze posiadają pole komentarza. Należy z niego korzystać i usuwać wszystkie wpisy, których nie można przypisać do konkretnej osoby.

W przypadku historii logowania, journalctl -t sshd --since "30 days ago" | grep -i accepted dopasowuje wpisy na podstawie identyfikatora syslog, a nie nazwy jednostki. Jest to istotne, ponieważ Ubuntu 24.04 aktywuje SSH poprzez gniazdo (socket), przez co każde połączenie jest rejestrowane w ramach wygenerowanej jednostki dla pojedynczego połączenia, a zwykłe journalctl -u ssh może je pominąć.

Miesięcznie: stare jądra i pełna partycja /boot

/boot to często oddzielna partycja o rozmiarze kilkuset megabajtów w standardowym obrazie VPS. Każda aktualizacja jądra dodaje do niej obraz oraz initramfs. Gdy partycja zapełni się, kolejna aktualizacja kończy się niepowodzeniem w trakcie pracy, pozostawiając pakiety w nieskonfigurowanym stanie, co jest niepożądane w piątkowe popołudnie.

uname -r
df -h /boot
dpkg -l 'linux-image-*' | grep '^ii'
sudo apt autoremove --purge

uname -r najpierw, zawsze: polecenie to wskazuje jądro, które jest aktualnie uruchomione, a ono musi przetrwać wszelkie operacje usuwania. apt autoremove obsługuje typowe przypadki w systemach Debian i Ubuntu, ponieważ jądra są oznaczane jako zainstalowane automatycznie, a bieżące jądro jest chronione. Przypadki szczególne, takie jak ręcznie zainstalowane jądro lub /boot, która jest już na tyle pełna, że blokuje działanie samego apt, zostały opisane w usuwanie starych jąder w systemie Ubuntu.

Miesięczny przegląd: przyrost logów i dziennik systemd

journalctl --disk-usage
sudo du -xh --max-depth=1 /var/log | sort -h | tail
sudo logrotate --debug /etc/logrotate.conf

logrotate --debug to tryb testowy, który nie wprowadza żadnych zmian, więc jest bezpieczny dla działającego serwera. Warto go uruchomić, ponieważ reguły rotacji są dopasowywane do ścieżek: aplikacja, która zmieniła lokalizację logów podczas aktualizacji, nie jest już objęta własną regułą, a plik ten rośnie bez ograniczeń, aż do zapełnienia dysku.

Dziennik jest ograniczony przez systemd, ale limitem jest ułamek rozmiaru systemu plików, a nie konkretna wartość wybrana przez administratora. Należy ustawić SystemMaxUse= w pliku /etc/systemd/journald.conf i zrestartować systemd-journald, aby narzucić konkretny limit. Polecenie sudo journalctl --vacuum-time=14d natychmiast odzyskuje miejsce; jest to działanie jednorazowe, a nie stała polityka, dlatego należy je stosować łącznie ze zmianą konfiguracji.

W sprawie wydań: restart, który ciągle odkładasz

Zaktualizowany pakiet jądra na dysku nie jest uruchomionym jądrem. Do momentu restartu maszyna nadal korzysta ze starej wersji, a live patching, tam gdzie jest dostępny, obejmuje tylko podzbiór poprawek.

uname -r
ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs
sudo needrestart

Ten plik flagi to konwencja systemów Debian i Ubuntu, tworzona przez skrypty pakietów. Rodzina systemów RHEL nie tworzy tego pliku, a odpowiedź na to samo pytanie uzyskuje się tam za pomocą needs-restarting -r, pochodzącego z dnf-utils. Narzędzie needrestart, instalowane domyślnie w nowszych obrazach Ubuntu Server, odpowiada za poziom poniżej jądra: wyświetla procesy, które nadal korzystają z biblioteki zastąpionej na dysku. Dlatego poprawiona wersja OpenSSL zaczyna działać dopiero po restarcie usług, które z niej korzystają.

Zaplanuj restart zamiast go unikać. W /etc/apt/apt.conf.d/50unattended-upgrades, Unattended-Upgrade::Automatic-Reboot "true"; oraz Unattended-Upgrade::Automatic-Reboot-Time "03:00"; przekaż decyzję na wybrany przez siebie czas. Zaplanowany restart jest również jedynym testem sprawdzającym, czy serwer powróci do pracy, ponieważ błędny wpis w fstab lub usługa, której nigdy nie włączono, ujawniają się tylko podczas rozruchu.

Wydanie po wydaniu: planowanie aktualizacji dystrybucji

Wydania Ubuntu LTS oferują pięć lat standardowego wsparcia, natomiast wydania pośrednie dziewięć miesięcy, więc wybór ten determinuje nakład pracy związany z aktualizacjami na lata. Ten kompromis opisano w LTS kontra wydania pośrednie na serwerze.

lsb_release -a
cat /etc/update-manager/release-upgrades

do-release-upgrade odczytuje ten plik, a Prompt=lts ogranicza go do przejść między wydaniami LTS. Ścieżka LTS-to-LTS otwiera się zazwyczaj wraz z pierwszym wydaniem punktowym nowej wersji, a nie w dniu premiery, dlatego należy sprawdzić, co jest oferowane dla danej maszyny, zamiast planować działania w oparciu o założoną datę. Mechanikę tego procesu opisano w aktualizacja Ubuntu 24.04 do 26.04.

Należy zaplanować trzy miesiące marginesu. Należy wykonać snapshot, którego przywracanie zostało przetestowane, sporządzić listę zewnętrznych repozytoriów apt (aktualizacja je wyłącza, a każde z nich wymaga nowego celu dla nowej wersji) oraz ustalić procedurę wycofywania zmian przed rozpoczęciem prac. Według stanu na sierpień 2026, Ubuntu 24.04 LTS posiada standardowe wsparcie do kwietnia 2029, więc jest to kwestia harmonogramu, a nie sytuacja awaryjna.

Co automatyzować, a co pozostawić ręczne

Automatyzuj decyzje, które już zostały podjęte: aktualizacje bezpieczeństwa, rotację logów, odnawianie certyfikatów oraz zadania kopii zapasowych. Automatyzuj również powiadomienia, ponieważ kontrola wymagająca pamiętania o niej to kontrola, która nie zostanie wykonana o 2 w nocy. Zewnętrzny monitor, taki jak self-hosted status monitoring with Uptime Kuma, wykrywa jedyną rzecz, której nie zgłosi żaden skrypt na serwerze: brak łączności z samą maszyną.

Pozostaw dwie rzeczy ręczne: test przywracania danych oraz audyt kont. Obie wymagają decyzji człowieka, czy wynik jest prawidłowy. Jeśli wolisz odczytywać stan maszyny w przeglądarce niż w terminalu, Cockpit versus Webmin for server management porównuje dwie popularne konsole webowe.

Automatyzacja wymaga własnej kontroli, dlatego pierwszym cotygodniowym punktem na tej liście jest weryfikacja mechanizmu aktualizacji. Automatyzacja, która zawodzi w sposób cichy, jest gorsza niż jej brak, ponieważ jednocześnie usuwa awarię oraz nawyk jej sprawdzania.

Kompletna lista kontrolna w jednym miejscu

# weekly
systemctl list-units --state=failed
systemctl list-timers --all
journalctl -u unattended-upgrades --since "8 days ago" --no-pager
apt list --upgradable
apt-mark showhold
df -h
df -i

# monthly
sudo certbot certificates
awk -F: '$3>=1000 && $3<65534 {print $1}' /etc/passwd
getent group sudo
sudo sshd -T | grep -E 'permitrootlogin|passwordauthentication'
uname -r
dpkg -l 'linux-image-*' | grep '^ii'
journalctl --disk-usage

FAQ

Jak często należy przeprowadzać konserwację serwera Linux?

Raz w tygodniu dla elementów, które zmieniają się samodzielnie: status aktualizacji, wolne miejsce na dysku i inody, nieudane jednostki oraz wynik zadania kopii zapasowej. Raz w miesiącu dla procesów powolnej degradacji: test przywracania, wygasanie certyfikatów, audyt kont i kluczy SSH, stare jądra, przyrost logów. Raz na wydanie dystrybucji dla aktualizacji wersji i restartu do bieżącego jądra. Cotygodniowy przegląd zajmuje kilka minut na sprawnym serwerze; to główny powód, dla którego wykonuje się go regularnie, a nie dopiero w momencie wystąpienia awarii.

Dlaczego należy testować przywracanie, jeśli zadanie kopii zapasowej zgłasza sukces?

Ponieważ zadanie zgłasza jedynie własny kod wyjścia, a ten może być poprawny, podczas gdy archiwum jest bezużyteczne. Zrzut przesyłany potokiem do kompresora bez set -o pipefail zwraca status kompresora, więc nieudany zrzut, który wygenerował jedynie komunikat o błędzie, nadal kończy się statusem zero i zapisuje niewielki plik. Przywróć dane na inną maszynę, otwórz je i zweryfikuj zawartość. Test przywracania mierzy również czas trwania operacji, co stanowi rzeczywisty wskaźnik czasu odzyskiwania danych.

Czy po każdej aktualizacji jądra konieczny jest restart?

Restart jest konieczny, aby uruchomić nowe jądro. W systemach Debian i Ubuntu obecność pliku /var/run/reboot-required oznacza, że pakiet wymaga restartu, a /var/run/reboot-required.pkgs wskazuje, który. W rodzinie RHEL ten plik nie istnieje, a needs-restarting -r z pakietu dnf-utils odpowiada na to samo pytanie. Ustaw okno automatycznego restartu w /etc/apt/apt.conf.d/50unattended-upgrades zamiast odkładać je w nieskończoność, ponieważ maszyna, która nie była restartowana od roku, posiada nieprzetestowaną ścieżkę rozruchu oraz przestarzałe jądro.

Które z tych kontroli można bezpiecznie zautomatyzować?

Automatyzuj działania, których decyzja jest już podjęta: aktualizacje bezpieczeństwa, rotację logów, odnawianie certyfikatów, zaplanowane kopie zapasowe. Automatyzuj również powiadomienia, aby informacja o nieudanej jednostce lub zapełniającym się dysku dotarła do administratora bez konieczności ręcznego uruchamiania poleceń. Test przywracania i audyt kluczy pozostaw ręczne, ponieważ wymagają one oceny człowieka, czy wynik jest prawidłowy. Następnie dodaj jedną kontrolę samej automatyzacji, ponieważ cicha awaria aktualizatora wygląda dokładnie tak samo, jak poprawne działanie systemu.