Upgrade Ubuntu 26.04 pe VPS: in-place sau rebuild?

Pentru majoritatea VPS-urilor de producție, varianta sigură este reconstruirea serverului de la zero. Actualizarea in-place de la Ubuntu 24.04 la 26.04 are sens numai dacă serverul este curat, documentat, puțin personalizat și ușor de restaurat. Un rebuild paralel îți oferă un rollback real și expune incompatibilitățile cu PHP, Docker, bazele de date și pachetele externe înainte de mutarea traficului. Ubuntu 26.04 LTS primește mentenanță standard de securitate până în mai 2031, dar Ubuntu 24.04 rămâne suportat până în mai 2029. Nu există niciun motiv să forțezi un upgrade riscant înainte ca stack-ul tău să fie pregătit.

Scris de echipa tehnică ServerSpan

Decizia implicită este să reconstruiești serverele de producție și să actualizezi in-place serverele simple

Un upgrade in-place schimbă sistemul de operare de sub toate serviciile în același timp. Un rebuild curat creează un al doilea server, instalează deliberat versiunile software dorite, restaurează aplicația, o testează și mută traficul numai după validare.

Actualizarea in-place economisește timpul necesar pentru provisionare și migrare. Rebuild-ul necesită mai multă muncă administrativă la început, dar oferă o bază de date curată a pachetelor, o configurație predictibilă și un server vechi care poate rămâne disponibil în perioada de rollback.

Factor de decizie	Upgrade in-place	Rebuild de la zero
Scenariul potrivit	Server Ubuntu mic, apropiat de configurația standard, cu puține repository-uri externe	Aplicație de producție cu modificări acumulate sau cerințe stricte de recuperare
Deriva pachetelor	Este păstrată și transportată în Ubuntu 26.04	Este eliminată, cu excepția elementelor recreate intenționat
Rollback	Necesită de obicei restaurarea completă a VPS-ului sau revenirea la un snapshot	Traficul poate fi mutat înapoi pe serverul original
Repository-uri terțe	Sunt dezactivate în timpul upgrade-ului și pot bloca dependențe	Sunt adăugate numai după confirmarea suportului pentru Ubuntu 26.04
Docker, PHP și runtime-uri	Pachetele și configurația hostului sunt modificate direct	Sunt testate pe serverul înlocuitor înainte de cutover
Migrarea bazei de date	Schimbările de pachete și formate de date se produc pe hostul activ	Dump-ul, restaurarea, replicarea și validarea se pot face separat
Downtime	Poate fi mai scurt dacă totul funcționează corect	Este limitat de obicei la sincronizarea finală și mutarea traficului
Vizibilitatea erorilor	Unele probleme apar numai după înlocuirea pachetelor vechi	Majoritatea problemelor apar în timp ce serverul original este încă online

Un rebuild paralel este de regulă mai sigur atunci când VPS-ul generează venituri, acceptă date de la clienți, trimite e-mailuri sau găzduiește mai multe servicii fără legătură între ele. Costul serverului este rareori partea scumpă a unei migrări eșuate. Partea scumpă este reconstruirea în grabă a unui server de producție nedocumentat, în timp ce utilizatorii așteaptă.

Nu forța upgrade-ul LTS înainte ca acesta să fie oferit de Canonical

Existența imaginilor de instalare Ubuntu 26.04 nu înseamnă automat că upgrade-ul acceptat de la 24.04 la 26.04 este deja disponibil pe VPS-ul tău. Canonical deschide în mod normal upgrade-urile LTS la LTS după prima versiune punctuală a lansării țintă.

Verifică disponibilitatea fără să modifici sistemul:

sudo do-release-upgrade -c

Rezultatul corect trebuie să ofere explicit Ubuntu 26.04. Dacă utilitarul raportează că nu este disponibilă nicio versiune nouă, așteaptă. Nu adăuga parametrul -d pe un server de producție doar pentru a ocoli canalul normal de lansare. Canonical documentează acest parametru pentru versiuni de dezvoltare și evaluări timpurii, nu pentru migrarea obișnuită a serverelor de producție.

Datele actuale de lansare și mentenanță sunt publicate în documentația Canonical privind ciclul de viață Ubuntu. Procedura acceptată pentru servere este documentată în ghidul Ubuntu Server pentru upgrade-ul distribuției.

Deriva configurației de pachete arată dacă instalarea existentă mai este de încredere

Deriva pachetelor reprezintă diferența dintre serverul pe care crezi că îl ai și serverul care există în realitate. Include pachete instalate manual, pachete blocate, PPA-uri abandonate, fișiere de configurare suprascrise, instalatoare furnizate de vendori și componente rămase în urma unor experimente mai vechi.

Începe cu verificări care nu modifică sistemul:

cat /etc/os-release
uname -r
df -h /
df -ih /
apt-mark showhold
dpkg --audit
systemctl --failed

Un rezultat sănătos înseamnă că serverul rulează Ubuntu 24.04, are suficient spațiu liber și destui inode-uri, nu conține pachete blocate fără explicație, nu are operațiuni dpkg întrerupte și nu raportează servicii de producție eșuate. Un pachet configurat doar parțial sau un filesystem root plin reprezintă motive suficiente pentru a opri pregătirea upgrade-ului.

Înregistrează starea pachetelor instalate înainte de orice modificare:

dpkg-query -W -f='${binary:Package}\t${Version}\n' | sudo tee /root/packages-before-26.04.tsv > /dev/null
apt-mark showmanual | sudo tee /root/manual-packages-before-26.04.txt > /dev/null

Aceste fișiere nu vor restaura singure serverul. Ele îți oferă însă un punct de referință atunci când un daemon, o extensie PHP sau o comandă dispare după upgrade.

Repository-urile terțe sunt cea mai frecventă capcană a upgrade-ului

Canonical dezactivează repository-urile terțe și PPA-urile în timpul upgrade-ului distribuției. Software-ul instalat rămâne de regulă prezent, dar dependențele sale pot deveni incompatibile cu versiunile furnizate de Ubuntu 26.04.

Verifică atât intrările APT tradiționale, cât și fișierele source în formatul mai nou deb822:

grep -RhsE '^(deb |Types:|URIs:|Suites:)' \
  /etc/apt/sources.list \
  /etc/apt/sources.list.d/ 2>/dev/null

O listă scurtă care conține numai surse Ubuntu oficiale este un semn favorabil. Repository-urile pentru PHP, Docker, baze de date, agenți de monitorizare, software de backup, panouri de control sau produse de securitate trebuie verificate individual.

Reactivarea unui repository vechi prin simpla înlocuire a numelui versiunii Ubuntu din URL nu reprezintă un test de compatibilitate. Vendorul trebuie să publice pachete construite pentru Ubuntu 26.04. Dacă nu o face, păstrează serverul vechi sau înlocuiește componenta în timpul unui rebuild curat.

Containerele Docker nu elimină riscul upgrade-ului hostului

Containerizarea aplicației reduce problemele produse de dependențele aplicației, dar Docker Engine, containerd, comportamentul firewall-ului, driverele de stocare și Docker Compose rămân componente ale hostului.

Docker acceptă oficial Ubuntu 26.04. Asta nu dovedește că instalarea ta existentă poate fi actualizată fără probleme, mai ales când pachetele Docker provin dintr-un amestec între repository-urile Ubuntu și repository-ul Docker.

apt-cache policy docker-ce docker.io containerd.io
docker info
docker compose ls
docker ps --format 'table {{.Names}}\t{{.Image}}\t{{.Status}}'

Politica pachetelor trebuie să arate o singură sursă aleasă intenționat. Un amestec între docker.io, docker-ce, pachetele containerd ale distribuției și containerd.io furnizat de Docker trebuie curățat înainte de migrare.

Salvează separat fișierele Compose, datele bind-mounted, datele din volume, fișierele de environment și secretele. Copierea directorului /var/lib/docker nu reprezintă un backup portabil al aplicației.

Lista actuală a versiunilor Ubuntu acceptate este disponibilă în documentația oficială Docker Engine. Pentru problema mai largă a mentenanței, citește de ce actualizările automate oarbe pentru Docker nu reprezintă o strategie de mentenanță.

PHP poate părea funcțional în timp ce serverul web folosește socket-ul greșit

Problemele PHP apărute după upgrade-ul distribuției sunt cauzate frecvent de alegerea configurației greșite, nu de PHP în sine. Un serviciu PHP-FPM nou poate porni fără erori, în timp ce Nginx trimite în continuare cererile către socket-ul versiunii vechi. Apache poate încărca un modul diferit de versiunea PHP folosită în linia de comandă.

php -v
php --ini
php -m
systemctl list-units 'php*-fpm.service'
find /etc/php -maxdepth 2 -type d -print
grep -Rhs 'fastcgi_pass' /etc/nginx/sites-enabled/ 2>/dev/null

Compară versiunea PHP din linia de comandă, calea configurației încărcate, extensiile instalate, serviciile FPM active și socket-ul folosit de serverul web. Testează înainte de cutover cerințele aplicației pentru ionCube, ImageMagick, drivere de baze de date, Redis și extensii specifice aplicației.

Alege rebuild-ul în locul upgrade-ului in-place dacă VPS-ul rulează mai multe ramuri PHP, folosește un repository PHP terț, conține fișiere de pool modificate manual sau depinde de extensii proprietare care nu au publicat versiuni compatibile.

Rollback-ul bazei de date trebuie proiectat înainte de schimbarea sistemului de operare

Un snapshot al filesystemului nu este automat un backup al bazei de date consistent cu aplicația. Dacă baza de date scrie în timp ce snapshot-ul este creat, restaurarea poate implica reluarea jurnalului după crash, tranzacții lipsă sau date care nu mai corespund fișierelor încărcate în aplicație.

Inventariază motoarele și versiunile de baze de date existente:

mysql --version
mariadb --version
psql --version
sudo -u postgres pg_lsclusters 2>/dev/null

Comenzile pentru software care nu este instalat vor eșua fără să modifice sistemul. Trebuie să identifici motorul activ, sursa pachetelor, directorul datelor, traseul acceptat pentru upgrade și procedura de restaurare.

Pentru datele de producție, creează un backup logic prin instrumentele native ale motorului și păstrează separat o copie fizică sau una la nivelul providerului, acolo unde este disponibilă. Restaurează backup-ul logic pe o altă instanță și rulează verificările aplicației. Un dump netestat dovedește doar că a fost creat un fișier, nu că serviciul poate fi recuperat.

Un rebuild curat este mai sigur atunci când se schimbă versiunea majoră a bazei de date, motorul provine dintr-un repository extern, există replicare sau downtime-ul trebuie să rămână predictibil.

Un snapshot nu este un plan complet de rollback

Un upgrade in-place modifică mediul de boot, pachetele, fișierele serviciilor, configurația și starea bazelor de date pe același VPS. Revenirea la snapshot anulează și toate scrierile efectuate după crearea lui.

Un plan real de rollback trebuie să precizeze:

• Cum este trimis traficul înapoi către serverul vechi.
• Cum sunt oprite sau sincronizate scrierile în timpul cutover-ului.
• Care copie a bazei de date devine sursa autoritară.
• Cum sunt gestionate TTL-ul DNS, certificatele, cozile, joburile programate și e-mailurile trimise.
• Cât timp rămâne serverul vechi disponibil și protejat împotriva scrierilor.

Pentru alegerea unui instrument de backup pe servere cu resurse limitate, consultă comparația BorgBackup vs Restic pentru protejarea datelor de pe VPS.

Alege rebuild-ul când serverul îndeplinește oricare dintre condițiile de risc ridicat

• Instalarea conține mai mulți ani de modificări manuale și nu există documentație actuală pentru reconstruirea sa.
• Serverul rulează un panou de hosting, un stack de e-mail, un gateway VPN sau o bază de date folosită direct de clienți.
• PHP, Docker, MySQL, MariaDB sau PostgreSQL provin dintr-un repository terț.
• Aplicația depinde de o extensie proprietară sau de un modul de kernel.
• VPS-ul nu are acces sigur la consolă sau o procedură de recuperare testată.
• Spațiul liber este insuficient pentru pachetele descărcate, fișierele temporare și datele folosite în timpul migrării bazei de date.
• Timpul maxim acceptat pentru recuperare este mai scurt decât timpul necesar depanării unui upgrade eșuat.

Serverele cu panouri de control necesită atenție suplimentară. Verifică sistemele de operare acceptate de vendor și procedura oficială de migrare înainte de modificarea distribuției. Modelul de decizie este asemănător celui explicat în ghidul pentru conversia cPanel de pe Rocky Linux sau reconstruirea serverului de la zero.

Construiește serverul înlocuitor în paralel cu VPS-ul existent

Modelul cel mai sigur pentru producție este să provision-ezi un al doilea VPS KVM, să instalezi curat Ubuntu 26.04, să restaurezi aplicația, să o testezi printr-un hostname temporar sau printr-o regulă locală în fișierul hosts și să muți traficul numai după validare.

Gama KVM publicată de ServerSpan începe în prezent cu vm.Entry, la 4,99 EUR pe lună fără TVA, cu 1 nucleu CPU, 512 MB RAM și 10 GB SSD. vm.Ready este listat la 9,99 EUR pe lună fără TVA, cu 2 nuclee CPU, 2 GB RAM și 25 GB SSD. Acestea sunt configurații de intrare publicate, nu recomandări automate pentru orice workload. Dimensionează serverul înlocuitor pentru aplicație, baza de date, duplicarea temporară a datelor și instrumentele de migrare. Confirmă disponibilitatea imaginii Ubuntu 26.04 înainte de comandă.

Serverul temporar de migrare poate fi închis după expirarea perioadei de rollback. Păstrarea VPS-ului original intact în timpul testării valorează mai mult decât economisirea unei luni de facturare cu riscul de a pierde singura copie funcțională.

Folosește această succesiune pentru migrarea unui server de producție

1. Inventariază pachetele, repository-urile, serviciile active, porturile, joburile programate, versiunile runtime și utilizarea spațiului de stocare.
2. Verifică backup-urile restaurându-le în altă parte decât pe VPS-ul de producție.
3. Provision-ează serverul Ubuntu 26.04 cu suficient spațiu și suficientă memorie pentru operațiunile temporare.
4. Instalează pachetele din surse acceptate, în loc să copiezi baza de date a pachetelor de pe serverul vechi.
5. Restaurează fișierele aplicației și bazele de date, apoi validează serviciile web, cozile, cron-ul, e-mailurile și worker-ele de fundal.
6. Testează printr-un hostname privat sau printr-o regulă în fișierul hosts, fără să modifici traficul public.
7. Redu TTL-ul DNS înaintea ferestrei de mentenanță dacă mutarea traficului va fi controlată prin DNS.
8. Oprește scrierile în aplicație, efectuează sincronizarea finală și mută traficul.
9. Monitorizează logurile aplicației, erorile bazei de date, răspunsurile HTTP, utilizarea resurselor și joburile outbound.
10. Păstrează VPS-ul original pornit, dar protejat împotriva scrierilor accidentale, până la închiderea perioadei de rollback.

Dacă serverul existent este mic, apropiat de configurația standard, complet salvat și ușor de înlocuit, un upgrade in-place prin sudo do-release-upgrade este rezonabil după ce Canonical oferă canalul acceptat. Pentru serverele de producție cu modificări importante ale pachetelor, repository-uri externe, baze de date sau cerințe stricte de recuperare, reconstruirea de la zero este alegerea corectă.

Dacă ai nevoie de ajutor pentru inventarierea serverului vechi, planificarea cutover-ului sau rezolvarea problemelor cu pachetele și serviciile, serviciul ServerSpan de administrare servere Linux acoperă depanarea sistemului, problemele de package management, lucrul cu baze de date și actualizările sistemului de operare. Infrastructura înlocuitoare poate fi aleasă dintre planurile actuale de găzduire VPS.