Debian 11 i CentOS 7 bez wsparcia: aktualizacja albo migracja serwera

Wsparcie Debiana 11 zakończyło się 31.08.2026, a CentOS 7 już 30.06.2024 (stan: 2026-10). Zaktualizujemy Państwa serwer albo zaplanujemy i wykonamy przejście na Debiana. Pracujemy również z Proxmox VE 8 i z serwerami fizycznymi, które przenosimy na Proxmox.

  • Od 2012 r. full stack i DevOps
  • Wirtualizacja na KVM i Proxmox
  • Odpowiedź w ciągu jednego dnia roboczego
Dwie szafy serwerowe z poziomymi slotami obok siebie, lewa narysowana przerywaną linią, prawa z pomarańczowym obrysem; strzałka w prawo i przerywana strzałka z powrotem w lewo; obie stoją na jednej linii z małym kółkiem

Czy na Państwa serwerze działa jeszcze Debian 11 lub CentOS 7?

To pytanie zwykle przychodzi z zewnątrz: w kwestionariuszu bezpieczeństwa od klienta, przy audycie albo w wiadomości od dostawcy hostingu. Wersję systemu pokazuje plik /etc/os-release.

Po końcu wsparcia serwer działa dalej. Na luki bezpieczeństwa wykryte później twórcy dystrybucji nie wydają jednak już poprawek. Pozostają otwarte, dopóki system nie zostanie zaktualizowany albo zastąpiony.

Serwer połączony linią z kalendarzem ściennym; jeden dzień w siatce kalendarza jest zaznaczony na pomarańczowo

Do kiedy Debian i CentOS dostają aktualizacje bezpieczeństwa

Stan na dzień: 2026-10
Data Zdarzenie Źródło
2021-12-31 CentOS Linux 8: koniec cyklu życia. centos.org (otwiera się w nowym oknie)
2024-06-30 CentOS Linux 7: koniec cyklu życia. redhat.com (otwiera się w nowym oknie)
2026-08-31 Debian 11: koniec wsparcia LTS. wiki.debian.org (otwiera się w nowym oknie)
2028-06-30 Debian 12: koniec wsparcia LTS. wiki.debian.org (otwiera się w nowym oknie)
2030-06-30 Debian 13: koniec wsparcia LTS. Regularne aktualizacje bezpieczeństwa do 09.08.2028. debian.org (otwiera się w nowym oknie)

Która droga pasuje do której sytuacji wyjściowej? (stan: 2026-10)

Kryterium Debian 11 CentOS 7 lub 8 Proxmox VE 8
Droga i cel Aktualizacja istniejącego systemu etapami: najpierw do Debiana 12, potem do 13, bo Debian wspiera tylko przejście do kolejnej wersji. Celem jest zwykle Debian 13. Jeśli aplikacja nie działa jeszcze z jego wersją PHP, zostajemy przy Debianie 12. Nowa instalacja Debiana obok starego serwera, zwykle Debiana 13. Stary serwer pozostaje bez zmian aż do odbioru. Aktualizacja do Proxmox VE 9 według instrukcji producenta. Najpierw sprawdzona kopia zapasowa wszystkich maszyn wirtualnych i kontenerów, potem program kontrolny pve8to9, a przy kilku węzłach aktualizacja węzeł po węźle.

Dlaczego planujemy serwer i aplikację razem

Serwery bez poprawek często działają latami bez nadzoru, na przykład z CentOS 8 albo z Ubuntu 16.04, 18.04 i 20.04. Bez Ubuntu Pro te trzy wersje Ubuntu nie dostają aktualizacji bezpieczeństwa odpowiednio od kwietnia 2021, maja 2023 i maja 2025 (stan: 2026-10).

Nowy system operacyjny przynosi nowe oprogramowanie: Debian 11 dostarcza PHP 7.4, Debian 12 PHP 8.2, a Debian 13 PHP 8.4 (stan: 2026-10). Aplikacji napisanej dla PHP 7.4 nie da się przenieść na nowsze wersje bez sprawdzenia. Wtedy aktualizacja serwera jest zarazem aktualizacją aplikacji.

Dlatego planujemy jedno i drugie razem. Część dotyczącą aplikacji opisuje strona Aktualizacja do PHP 8, a przy ColdFusion lub Lucee strona Koniec wsparcia ColdFusion. Terminy Ubuntu podajemy na stronie Linux i DevOps.

Okno aplikacji stoi na serwerze, nawias po lewej łączy oba elementy i ma pomarańczową kropkę; po prawej kartka z planem

Pięć kroków, każdy z pisemnym wynikiem

  1. Inwentarz

    Spisujemy system operacyjny, usługi z wersjami, aplikacje, zaplanowane zadania, certyfikaty, wysyłkę poczty, kopie zapasowe, pakiety z obcych źródeł i zmienione pliki konfiguracyjne. Inwentarz otrzymują Państwo na piśmie.

  2. Kopia zapasowa i test odtworzenia

    Sprawdzamy, czy istnieje aktualna kopia zapasowa, odtwarzamy ją w systemie testowym i zapisujemy wynik w protokole.

  3. Środowisko testowe

    Budujemy nowy stan na kopii serwera i testujemy na nim Państwa aplikację. Potrzebne poprawki trafiają na listę uporządkowaną według ryzyka. System produkcyjny pozostaje bez zmian.

  4. Przełączenie w oknie serwisowym

    Plan, termin i drogę powrotu uzgadniamy z Państwem wcześniej na piśmie. Aktualizujemy albo przełączamy, a potem sprawdzamy wszystko, co stoi w inwentarzu.

  5. Dokumentacja i runbook

    Dokumentujemy konfigurację i opisujemy działanie serwera w instrukcji operacyjnej (runbook). Dzięki temu serwer może przejąć także inny dostawca.

Nadal serwery fizyczne? Przeniesienie na Proxmox lub do kontenerów

Często na jednym serwerze fizycznym działa dokładnie jedna aplikacja, a każda maszyna wymaga własnych aktualizacji i kopii zapasowych. Wirtualizujemy maszyny na Proxmox, w wersji, która ma aktualne wsparcie, albo przenosimy aplikacje do kontenerów:

  • inwentarz maszyn, ich zależności, sieci i potrzebnej mocy obliczeniowej
  • plan: co działa jako maszyna wirtualna, a co trafia do kontenera?
  • przeniesienie w oknach serwisowych z drogą powrotu, kopiami zapasowymi i testem odtworzenia jak wyżej

Potem mają Państwo mniej sprzętu do utrzymania i wymiany, a przed aktualizacją można utworzyć migawkę. Czy konsolidacja się opłaca, wyliczamy w planie: sprzęt, energia i licencje. O przenoszeniu aplikacji do kontenerów piszemy na stronie Z hostingu do kontenera.

Więcej o administracji Linux i infrastrukturze

Sześć małych osobnych komputerów po lewej, cienkie strzałki prowadzą do większej ramy podzielonej na przegródki po prawej, jedna przegródka jest wypełniona na pomarańczowo

Doświadczenie naszych inżynierów z serwerami Linux i wirtualizacją

Full stack i DevOps
od 2012 r., od kodu po serwer
Systemy operacyjne
Debian i Ubuntu w bieżącej eksploatacji, CentOS przy migracjach
Konfiguracja jako kod
Ansible z osobnymi inwentarzami dla produkcji i testów

Jak zaczynamy aktualizację serwera

  • Bezpieczny dostęp do serwera przez VPN lub klucze SSH, według Państwa standardów.
  • W systemie produkcyjnym zmieniamy coś dopiero wtedy, gdy test odtworzenia się powiódł.
  • Dane dostępowe, konfiguracja i dokumentacja zostają u Państwa.
  • Mówimy też wprost, gdy sama aktualizacja się nie opłaca, i proponujemy rozwiązanie z myślą o przyszłości.

A co, jeśli u nas ktoś będzie niedostępny? Dokumentację sporządzamy na życzenie. Repozytorium z reguły znajduje się u Państwa. Zastępstwo organizujemy na życzenie.

Więcej na stronach Doświadczenie i Współpraca.

Po lewej kartka z wierszami tekstu i linią podpisu z pomarańczowym haczykiem; strzałka wskazuje serwer narysowany przerywaną linią po prawej

Pierwszy krok: rozmowa wstępna, potem przegląd serwera

Przegląd serwera

Dla firm z serwerami Linux, których nikt już dokładnie nie zna: przed aktualizacją, po odejściu administratora albo gdy klient pyta o kopie zapasowe.

  • Wersja i stan wsparcia systemu operacyjnego i usług
  • Zabezpieczenie: dostęp SSH, zapora sieciowa, otwarte usługi i certyfikaty TLS
  • Aktualizacje: czego brakuje i jak były dotąd wdrażane
  • Kopie zapasowe: co jest zabezpieczane i czy test odtworzenia jest udokumentowany
  • Monitoring i logi: co jest monitorowane, a czego brakuje
  • Lista ustaleń według priorytetu

Na tym etapie niczego na serwerze nie zmieniamy. Aplikacja i kod nie należą do przeglądu, od tego jest Przegląd systemu legacy. Zakres i cenę ustalamy w rozmowie wstępnej i potwierdzamy na piśmie przed rozpoczęciem pracy. Na życzenie otrzymają Państwo potem ofertę stałej opieki.

Co zawiera wynik

Pisemna lista ustaleń według priorytetu z zaleceniami dotyczącymi zabezpieczenia, aktualizacji, kopii zapasowych i monitoringu oraz plan aktualizacji z oknami serwisowymi. Oba dokumenty należą do Państwa.

Dwa przypadki z naszej pracy

  • Przeglądarka, ramka z podpisem Apache i trzy tory do PHP, PHP i CFML; tor CFML i jego ramka są pomarańczowe

    Produkcyjny ColdFusion 2025 za Apache: pięć nieoczywistych pułapek

    Przygotowaliśmy produkcyjną instalację Adobe ColdFusion 2025 na Debianie 12, za serwerem Apache 2.4, który obsługuje już kilka innych serwisów. Sama instalacja trwa 34 sekundy. Konektor i łatwe do przeoczenia szczegóły konfiguracji wymagały więcej uwagi: błąd 503 przez IPv6, mapowania sięgające do każdego hosta wirtualnego i profil, który po cichu dokłada debugger.

  • Cztery koperty przechodzą przez bramki SPF, DKIM i DMARC, odhaczone na pomarańczowo, w drodze do skrzynki odbiorczej

    Dostarczalność poczty dla czterech domen firmowych

    Serwer pocztowy czterech domen firmowych niczego nie podpisywał, nie publikował polityki DMARC i był odrzucany przez Microsoft. Nasi inżynierowie sprawdzili go, przetestowali zmianę na jednej domenie i wdrożyli ją partiami. Efekt: wszystkie trzy mechanizmy przechodzą sprawdzenie w Gmailu, blokada Microsoftu została zdjęta, a użytkownicy niczego nie odczuli.

Pytania, które pojawiają się przed aktualizacją

Czy możemy na razie dalej używać Debiana 11 lub CentOS 7?

Technicznie tak, serwer działa dalej. Bez aktualizacji bezpieczeństwa każda luka, która wyjdzie na jaw po końcu wsparcia, pozostaje jednak otwarta, a z czasem jest ich coraz więcej (stan: 2026-10).

Do czasu aktualizacji ryzyko można zmniejszyć: udostępnić tylko niezbędne usługi, ograniczyć dostęp administracyjny do VPN, postawić WAF przed aplikacją i przetestować kopie zapasowe. Ryzyko nie znika przez to całkowicie. W rozmowie wstępnej powiemy Państwu, co jest do przyjęcia w przypadku Państwa serwera.

Czy można przejść z Debiana 11 od razu na Debiana 13?

Nie w istniejącym systemie. Debian wspiera aktualizację tylko z bezpośrednio poprzedniej wersji, czyli z 11 do 12, a potem z 12 do 13. Tak podają uwagi do wydania Debiana 13 (otwiera się w nowym oknie) (stan: 2026-10). Dlatego idziemy etapami i po każdym etapie testujemy.

Alternatywą jest nowa instalacja Debiana 13 obok starego serwera. Wymaga więcej przygotowań, ale stary serwer pozostaje bez zmian jako droga powrotu. Opłaca się przede wszystkim wtedy, gdy przez lata nagromadziło się w systemie oprogramowanie i konfiguracja, w których nikt już się nie orientuje.

Na jaki system przenoszą Państwo CentOS 7?

Na Debiana, naszą główną platformę. Debian 13 dostaje regularne aktualizacje bezpieczeństwa do 09.08.2028, a potem wsparcie LTS do 30.06.2030 (stan: 2026-10).

Nowy serwer stawiamy obok starego. Stary pozostaje bez zmian jako droga powrotu, dopóki nie odbiorą Państwo nowego.

Jak długo serwer będzie niedostępny podczas przełączenia?

Można to powiedzieć dopiero po przyjrzeniu się Państwa systemowi. Przełączenia zupełnie bez przerwy nie obiecujemy. Przebieg najpierw ćwiczymy na kopii, przełączenie wykonujemy w uzgodnionym z Państwem oknie serwisowym i mamy gotową drogę powrotu.

Przy nowej instalacji nowy serwer powstaje obok starego, a przerwa zwykle ogranicza się do samego przełączenia. Przy aktualizacji istniejącego systemu usługi i serwer uruchamiają się ponownie, więc trzeba liczyć się z przerwą.

Co daje przeniesienie aplikacji do kontenera?

Środowisko, które da się odtworzyć. Ta sama wersja i konfiguracja obowiązują u programisty, w środowisku testowym i na produkcji. Zapisane są w repozytorium, a nie w głowie jednej osoby. Nowe wersje PHP, Lucee lub ColdFusion testujemy obok produkcji i możemy je wycofać. Przeniesienie na inny serwer lub do innego dostawcy również staje się prostsze.

Kontener nie naprawia błędu w kodzie i nie podnosi wersji, która nie jest już wspierana. Ułatwia jedynie takie zmiany.

Jaka jest Państwa stawka godzinowa?

To zależy od zakresu, modelu współpracy i pilności. Prosimy krótko opisać Państwa sytuację, a po rozmowie otrzymają Państwo ofertę. Nie trzeba przy tym podawać budżetu. Stałe ceny podajemy przy produktach wejściowych.

Kiedy mogą Państwo zacząć?

Pierwszą odpowiedź otrzymają Państwo w ciągu jednego dnia roboczego. Kiedy zaczniemy pracę, zależy od bieżącego obłożenia i od zakresu. Powiemy to Państwu wiążąco podczas rozmowy wstępnej. Jeśli sprawa jest pilna, Ocena awaryjna w 48 godzin rozpoczyna się z chwilą, gdy uzyskamy dostęp do systemu.

Czy czasem pełnią Państwo dyżury w weekendy?

Tak. Wsparcie i awarie obsługujemy całą dobę (24/7), także w weekendy. Prace planowane na weekend, na przykład przełączenie w oknie serwisowym, wykonujemy po uzgodnieniu. W pozostałych sprawach jesteśmy dostępni od poniedziałku do piątku od 9:00 do 17:00 czasu środkowoeuropejskiego, a na zapytania odpowiadamy w ciągu jednego dnia roboczego.

Prosimy opisać serwer w trzech zdaniach

Wystarczy podać system operacyjny, wersję, aplikacje i miejsce, w którym stoi serwer (u Państwa lub u dostawcy hostingu). Odpowiadamy w ciągu jednego dnia roboczego.

Pola oznaczone jako „opcjonalnie” można zostawić puste.

Kontakt e-mailowy

Do kontaktu telefonicznego wystarczy numer: awarie całą dobę, w pozostałych sprawach w ciągu jednego dnia roboczego.

Jaki system, jaka technologia, co chcą Państwo osiągnąć? Prosimy nie przesyłać haseł ani poufnych dokumentów.

Odpowiedź w ciągu jednego dnia roboczego · bez zobowiązań

Wykorzystujemy Państwa dane wyłącznie do odpowiedzi na zapytanie. Prownex IT Services Sp. z o. o. jest administratorem danych. Okres przechowywania i Państwa prawa opisano w polityce prywatności.