cPanel pe Rocky Linux după v134: conversie in-place la AlmaLinux sau rebuild de la zero? Ghid practic de decizie pentru migrare

Dacă serverul tău cPanel rulează încă pe Rocky Linux, decizia nu mai este dacă trebuie să migrezi. Decizia este cum. Pentru majoritatea serverelor curate pe Rocky 9, o conversie in-place la AlmaLinux este cea mai rapidă cale către un sistem din nou suportat. Pentru sistemele mai vechi pe Rocky 8, pentru stack-uri puternic personalizate sau pentru servere cu ani de drift operațional, o reconstrucție curată pe AlmaLinux este de obicei alegerea mai sigură pe termen lung.

Ce s-a schimbat după v134

În martie 2026, eliminarea suportului Rocky Linux de către cPanel a devenit o problemă operațională activă, nu un avertisment pentru viitor. Dacă rămâi pe Rocky, îți îngheți practic stratul cPanel și accepți un risc în creștere legat de lipsa actualizărilor pentru panou, remediilor întârziate și o cale tot mai îngustă înapoi către mentenanță normală. Explicația noastră anterioară despre renunțarea cPanel la Rocky Linux în versiunea 134 acoperă schimbarea de bază. Acest articol răspunde la întrebarea mai dificilă: ar trebui să convertești serverul existent in-place sau să reconstruiești pe un sistem AlmaLinux nou și să migrezi către el?

Răspunsul depinde de igiena pachetelor, obiectivul privind versiunea majoră, opțiunile de rollback și cât risc orientat spre client poți tolera. Este aceeași distincție care apare în orice schimbare serioasă de infrastructură: un update versus upgrade de server nu este niciodată doar despre pachete. Este despre raza de impact, viteza de recuperare și dacă ai suficientă încredere în mașina actuală pentru a o păstra ca fundație.

Regula scurtă de decizie

Alege conversia in-place atunci când serverul este sănătos, setul de pachete este apropiat de așteptările standard cPanel și vrei cea mai rapidă cale către un sistem de operare suportat, cu perturbare minimă.

Alege un rebuild curat atunci când serverul poartă ani de modificări manuale, depozite third-party, kerneluri personalizate, opțiuni neclare de rollback sau când folosești această migrare forțată ca momentul potrivit pentru a curăța stack-ul, a trece la o versiune majoră nouă, a redimensiona VPS-ul sau a schimba modul în care sunt organizate conturile clienților.

• Alege conversia in-place dacă vrei viteză, serverul actual este stabil și poți accepta o fereastră de mentenanță centrată în jurul unui reboot și a validării ulterioare.
• Alege rebuild-ul curat dacă vrei cea mai curată stare posibilă, auditabilitate mai bună sau o cale mai sigură pentru sisteme vechi și dezordonate.
• Nu rămâne pe Rocky ca stare permanentă decât dacă ai deja migrarea programată și accepți în mod deliberat riscul pe termen scurt.

Când conversia in-place este alegerea corectă

Conversia in-place este opțiunea pragmatică pentru multe implementări cPanel pe un singur server. Dacă mașina funcționează deja bine, emailul este stabil, backup-urile sunt consistente, iar personalizările sunt limitate, înlocuirea pachetelor Rocky cu pachete AlmaLinux este de obicei cea mai eficientă rută. Păstrezi aceeași structură de fișiere, aceleași conturi, aceeași instalare cPanel și, în cele mai multe cazuri, aceeași configurație IP. Pentru un VPS de producție unde downtime-ul trebuie să rămână scurt, asta contează.

Acest lucru este valabil în special pe Rocky 9. Dacă obiectivul tău este pur și simplu să revii rapid pe un sistem de operare suportat de cPanel, cu cât mai puține schimbări operaționale, conversia same-major este de obicei o decizie rațională. Rezolvi problema imediată de suport fără să introduci un al doilea proiect.

• Serverul este deja pe Rocky 9 și, în rest, este sănătos.
• Ai snapshot-uri la nivel de hypervisor sau un backup full-image verificat.
• Ai acces la consolă și nu depinzi doar de SSH.
• Nu rulezi module de kernel neobișnuite sau personalizări low-level de stocare.
• Instalarea cPanel este apropiată de valorile implicite ale vendorului, cu puțin drift RPM third-party.
• Ai nevoie de cea mai rapidă cale pentru a reveni la patching normal.

Pentru multe firme, acesta este răspunsul corect. Este adesea și răspunsul cu costul cel mai mic, pentru că nu trebuie să ții un al doilea server pornit zile întregi cât timp validezi cutover-ul. Dacă ai nevoie de un mediu potrivit pentru testare sau de un plan de fallback în paralel, pagina noastră despre servere virtuale acoperă opțiunile VPS folosite de obicei pentru astfel de ferestre de migrare.

Când un rebuild curat este alegerea mai sigură

O migrare forțată este uneori primul moment de sinceritate pe care un administrator îl are cu un server cPanel vechi după ani întregi. Dacă mașina a fost patch-uită reactiv, moștenită de la un furnizor anterior, încărcată cu repository-uri abandonate sau editată manual dincolo de orice audit simplu, conversia in-place păstrează fiecare compromis ascuns și fiecare workaround uitat. Aici rebuild-ul curat câștigă.

Un rebuild este și alegerea mai bună atunci când ești pe Rocky 8 și vrei să ajungi pe o bază nouă cu suport mai lung, în loc să faci mai întâi o conversie same-major și apoi să suprapui un upgrade de versiune majoră. Ghidarea actualizată ELevate de la cPanel contează aici, dar contează și realismul. O conversie same-major urmată de o ridicare de versiune majoră poate funcționa. Înseamnă și mai multe piese în mișcare, mai multe reboot-uri și mai multe șanse de probleme de margine. Dacă serverul este critic și mediul este dezordonat, construirea unui target AlmaLinux curat și migrarea conturilor în el este adesea decizia de business cu risc mai mic.

• Serverul este pe Rocky 8 și vrei să termini pe AlmaLinux 9 sau 10, nu doar să supraviețuiești momentului actual.
• Ai multe repository-uri third-party, RPM-uri custom sau module de kernel nesuportate.
• Mașina are ani de drift de configurare și nimeni nu are încredere deplină în starea ei.
• Vrei să redimensionezi, să schimbi IP-uri, să reorganizezi conturi sau să cureți datorie tehnică în timpul mutării.
• Rulezi un mediu cu multe conturi și valoare mare, unde predictibilitatea contează mai mult decât viteza.
• Vrei validare etapizată pe un sistem paralel înainte de cutover-ul clienților.

Blocaje de preflight care ar trebui să oprească o conversie făcută în aceeași zi

Nu trata conversia ca pe un update obișnuit de pachete. Oprește-te și reevaluează dacă găsești oricare dintre situațiile de mai jos:

• /boot are prea puțin spațiu liber.
• Accesul la consolă nu este disponibil sau nu a fost testat.
• Backup-urile există doar teoretic și nu au fost restaurate recent.
• Repository-urile third-party sunt încă active și livrează pachete de bază.
• Sunt instalate kerneluri custom, unelte RAID speciale sau module out-of-tree.
• Verificările de integritate ale pachetelor cPanel deja dau erori.
• Nu poți explica exact cum vor fi validate emailul, DNS-ul, reînnoirea SSL și backup-urile după reboot.
• Nu ai un punct clar de rollback.

Un preflight practic pe serverul sursă începe de obicei cu verificări precum acestea:

cat /etc/os-release
/usr/local/cpanel/cpanel -V
df -h /boot
dnf repolist
rpm -qa | egrep 'kmod-|kernel|imunify|cloudlinux|ea-|alt-'
/usr/local/cpanel/scripts/check_cpanel_pkgs --fix

Dacă rezultatele arată deja zgomotos, un rebuild începe să aibă mai mult sens. Dacă arată curat, conversia rămâne o opțiune solidă. Dacă apar semne de întrebare legate de bootloader sau kernel, verifică-ți postura de recovery în același mod în care ai trata un incident sensibil la reboot, cum sunt cazurile discutate în ghidul nostru despre analiza kernel panic în 2026.

Puncte de rollback și logica de cutover pentru clienți

Aici eșuează multe migrări. Administratorii se concentrează pe acțiunea asupra pachetelor și neglijează secvența orientată spre client din jurul ei.

• Punct de rollback unu: creează un snapshot complet la nivel de hypervisor sau un backup image-level imediat înainte de schimbare.
• Punct de rollback doi: generează backup-uri actuale pentru conturile cPanel critice pentru business.
• Punct de rollback trei: documentează pașii de validare a serviciilor înainte să atingi sistemul de operare.

Pentru o conversie in-place, cutover-ul pentru clienți este simplu pentru că nu există un nou hostname de destinație sau o mutare DNS. Riscul real este regresia serviciilor după reboot. Validarea trebuie să acopere website-uri, fluxul de email, zonele DNS, AutoSSL, backup-urile, joburile cron și starea serviciilor cPanel înainte să declari succesul.

Pentru un rebuild, logica de cutover este mai deliberată. Scade TTL-ul DNS cu suficient timp înainte. Construiește serverul AlmaLinux de destinație. Restaurează conturile prin transfer WHM sau backup-uri cPanel. Validează site-urile prin hosts file testing sau metode temporare de preview. Apoi mută traficul într-o fereastră planificată. Rebuild-urile pot dura mai mult la pregătire, dar îți oferă o ieșire controlată dacă noul server nu se validează curat.

O cale practică de migrare pentru fiecare scenariu

Scenariul 1: Rocky 9, server curat, drift redus

Convertește in-place. Este de obicei cea mai rapidă decizie rezonabilă. Ține proiectul îngust: backup, conversie la AlmaLinux, reboot, validarea serviciilor, apoi actualizarea cPanel după ce sistemul de operare este confirmat ca sănătos. Nu amesteca în aceeași fereastră de mentenanță curățenie fără legătură cu migrarea.

Scenariul 2: Rocky 8, server vechi, istoric neclar al pachetelor

Reconstruiește de la zero pe o versiune AlmaLinux suportată și migrează conturile către ea. Aici ideea că „fresh este mai lent” poate fi înșelătoare. Un rebuild reduce adesea riscul total pentru că nu mai ai încredere într-un sistem încărcat cu ani de drift. Dacă vechiul server are nevoie și de un refresh de resurse, folosește migrarea ca momentul potrivit pentru a dimensiona corect destinația. Ghidul nostru despre alegerea planului VPS potrivit este util când trebuie să încetezi să ghicești și să dimensionezi ținta corect.

Scenariul 3: Rocky 8, server curat, dar vrei AlmaLinux 9

Aici ai două căi reale. Una este conversia same-major mai întâi, urmată de o ridicare controlată de versiune majoră cu ELevate. Cealaltă este un server AlmaLinux 9 construit de la zero și o migrare a conturilor în el. Prima cale este atractivă dacă serverul este curat și structura conturilor este simplă. A doua este de obicei mai bună dacă sensibilitatea la uptime este ridicată, numărul de conturi este mare sau vrei un handoff operațional mai curat după ce migrarea este încheiată.

Greșeli frecvente care provoacă downtime evitabil

• Tratarea schimbării de OS ca pe un ciclu obișnuit de patching pe timp de noapte.
• Omiterea verificării accesului la consolă înainte de reboot.
• Lăsarea repository-urilor third-party active și speranța că rezolvarea dependențelor va merge de la sine.
• Combinarea update-urilor de panou, a conversiei de OS, a schimbărilor PHP și a tuning-ului de mail în aceeași fereastră.
• Nefinalizarea testării serviciilor vizibile pentru client după revenirea sistemului.
• Presupunerea că „web-ul răspunde” înseamnă că migrarea este gata.

Un plan bun de rebuild evită și mutarea problemelor vechi de stack pe noua mașină. Dacă deja te întrebi dacă cPanel mai este panoul potrivit, compară compromisurile operaționale în articolul nostru DirectAdmin vs cPanel. Dacă obiectivul tău real este un strat de aplicație mai curat după migrare, vezi notele noastre despre optimizarea PHP 8.5 și Nginx pentru VPS-uri cu trafic intens după ce mutarea de platformă este finalizată.

Recomandarea ServerSpan

Pentru majoritatea serverelor cPanel pe Rocky 9, convertește in-place la AlmaLinux și păstrează proiectul strâns controlat. Este cea mai rapidă cale înapoi către un sistem de operare suportat și, de obicei, menține downtime-ul limitat la fereastra de mentenanță planificată.

Pentru serverele pe Rocky 8, mediile mai vechi și stack-urile critice de business cu multe conturi, alege rebuild-ul curat mai des decât îți vine inițial. Timpul suplimentar de planificare cumpără de obicei o bază operațională mai curată, o logică de rollback mai simplă și un rezultat mai bun pe termen lung decât suprapunerea conversiei, a ridicării de versiune și a curățeniei într-un singur proiect.

Dacă vrei cea mai scurtă cale sigură, folosește un VPS ServerSpan ca mediu de destinație sau fallback și tratează migrarea ca pe un proiect controlat, nu ca pe o sesiune de shell făcută în grabă. Dacă vrei ajutor pentru execuția mutării, serviciul nostru de cPanel management este alegerea naturală pentru migrații și validări specifice cPanel. Dacă această decizie forțată te face să realizezi că nu ai nevoie deloc de root access sau de complexitatea unui control panel, web hosting standard este adesea răspunsul mai simplu și mai ieftin.

Mișcarea greșită este să amâni fără un plan. Mișcarea corectă este să decizi ce risc preferi: riscul controlat al unei conversii in-place pe un server sănătos sau costul controlat al unei reconstrucții curate pe AlmaLinux, cu cutover făcut în termenii tăi.

Scris de ServerSpan SysAdmin Team, Echipa SysAdmin - ServerSpan

ServerSpan SysAdmin Team redactează și revizuiește ghiduri de producție pentru operațiuni Linux, panouri de control, migrări și recovery de servere.