Cum să Mutați Toate Conturile cPanel de pe un Server pe Altul

Migrarea tuturor conturilor cPanel între servere este procesul de transfer al fiecărui domeniu găzduit, fișierele sale, bazele de date MySQL, conturile de email, zonele DNS, certificatele SSL și sarcinile cron dintr-o instanță WHM sursă într-o instanță WHM destinație — de obicei folosind WHM Transfer Tool integrat printr-o conexiune SSH autentificată. Când este executat corect, acest proces nu necesită nicio copiere manuală a fișierelor și păstrează intactă toată metadatele contului.

Acest ghid acoperă fluxul complet de migrare la nivel de producție: verificări preliminare, configurarea Transfer Tool, strategia de tranziție DNS, validarea post-migrare și curățarea — inclusiv cazurile limită care cauzează eșecuri silențioase în mediile reale.

Cerințe preliminare și lista de verificare pre-migrare

Omiterea pregătirii este cea mai frecventă cauză a migrărilor cPanel eșuate sau incomplete. Înainte de a atinge oricare dintre servere, verificați fiecare element de mai jos.

Acces root pe ambele servere. WHM Transfer Tool se autentifică pe serverul sursă prin SSH ca root. Dacă serverul sursă are PermitRootLogin no în /etc/ssh/sshd_config, trebuie fie să îl activați temporar, fie să preconfigurați autentificarea SSH bazată pe cheie pentru root.

Versiuni cPanel/WHM compatibile. cPanel poate transfera conturi de la versiuni mai vechi la versiuni mai noi, dar nu invers. O destinație care rulează cPanel 110 poate prelua de la o sursă care rulează cPanel 98, dar inversul va eșua. Verificați versiunile în WHM sub Server Information sau rulați:

cat /usr/local/cpanel/version

Versiuni PHP și MySQL identice sau compatibile. Dacă sursa rulează PHP 7.4 și MySQL 5.7 în timp ce destinația rulează PHP 8.2 și MySQL 8.0, aplicațiile pot să nu funcționeze după transfer chiar dacă fișierele sunt copiate corect. Auditați versiunile PHP instalate și handlerii impliciți pe ambele servere înainte de a continua.

Spațiu suficient pe disc la destinație. Transfer Tool necesită spațiu liber cel puțin egal cu dimensiunea totală comprimată a tuturor conturilor transferate, plus spațiu suplimentar pentru extragere. Rulați df -h pe destinație și comparați cu utilizarea totală a discului de cont vizibilă în vizualizarea List Accounts din WHM pe sursă.

Reguli de firewall care permit SSH între servere. Serverul destinație inițiază o conexiune SSH de ieșire către sursă. Asigurați-vă că portul 22 (sau portul SSH personalizat) este deschis pe firewall-ul serverului sursă pentru adresa IP a destinației.

Backup-uri complete ale conturilor pe sursă. Generați un backup cPanel complet pentru fiecare cont înainte de a începe. Acesta este punctul dvs. de recuperare dacă transferul corupte sau copiază parțial un cont.

/scripts/pkgacct username /backup/directory

Dacă rulați noul mediu pe un plan de VPS Hosting, confirmați că VPS-ul dvs. are cPanel/WHM deja licențiat și instalat înainte de a continua. O instalare nouă cPanel necesită o licență validă legată de adresa IP a serverului.

Pasul 1: Instalați și configurați cPanel/WHM pe serverul destinație

Dacă cPanel nu este încă instalat pe destinație, rulați instalatorul oficial ca root. Acest proces durează 20–45 de minute în funcție de hardware:

cd /home && curl -o latest -L https://securedownloads.cpanel.net/latest && sh latest

După finalizarea instalării, accesați WHM la https://your-server-ip:2087 și completați expertul de configurare inițială. Acordați atenție deosebită la:

• Hostname: Setați un nume de domeniu complet calificat (FQDN) care se rezolvă la IP-ul serverului. Un hostname care nu poate fi rezolvat cauzează eșecuri în livrarea emailurilor după migrare.
• Nameservers: Configurați hostname-urile nameserver-elor și adresele lor IP dacă intenționați să găzduiți DNS pe noul server.
• PHP handlers: Instalați aceleași versiuni PHP disponibile pe serverul sursă folosind WHM > MultiPHP Manager pentru a evita problemele de compatibilitate ale aplicațiilor.
• Versiunea MySQL/MariaDB: Potriviți versiunea motorului de baze de date a serverului sursă unde este posibil, sau testați compatibilitatea aplicației cu versiunea mai nouă înainte de a migra conturile de producție.

Pentru echipele care gestionează mai multe medii client, un VPS cu cPanel oferă un mediu preconfigurat care elimină complet faza de instalare manuală.

Pasul 2: Configurați WHM Transfer Tool

WHM Transfer Tool este metoda autoritativă pentru migrarea în masă a conturilor. Gestionează ambalarea, transferul, extragerea și crearea contului în mod atomic pentru fiecare cont.

2.1 Accesați Transfer Tool

Pe serverul destinație, conectați-vă la WHM și navigați la:

WHM > Transfers > Transfer Tool

Acesta este un punct critic care îi derutează pe mulți administratori: Transfer Tool este întotdeauna rulat de pe serverul destinație care preia conturile de la sursă — nu invers.

2.2 Conectați-vă la serverul sursă

Introduceți următoarele detalii de conexiune:

• Remote Server Address: Adresa IP sau hostname-ul serverului sursă
• Remote SSH Port: Implicit este 22; utilizați portul actual dacă a fost schimbat (verificați /etc/ssh/sshd_config pe sursă pentru directiva Port)
• Metoda de autentificare: Parolă root sau cheie SSH (autentificarea bazată pe cheie este puternic preferată pentru securitate și fiabilitate)

Pentru a utiliza autentificarea prin cheie SSH, copiați cheia publică root a serverului destinație pe sursă:

ssh-copy-id -i /root/.ssh/id_rsa.pub -p 22 root@source-server-ip

Odată conectat, Transfer Tool interoghează serverul sursă și returnează o listă cu toate conturile cPanel, pachetele și configurațiile de reseller.

2.3 Selectați conturile și domeniul de transfer

Puteți selecta toate conturile sau un subset. Pe lângă conturile individuale, Transfer Tool oferă și:

• Pachete: Transferați definițiile planurilor de găzduire astfel încât conturile să-și păstreze alocările de resurse
• Zone DNS: Copiați toate fișierele de zonă, esențial dacă noul server va acționa ca nameserver autoritar
• Privilegii Reseller și ACL-uri: Păstrați configurațiile conturilor reseller și permisiunile asociate acestora

2.4 Configurați opțiunile de transfer

Două setări de aici au un impact operațional semnificativ:

Express Transfer automatizează tranziția DNS prin actualizarea zonelor DNS pe serverul sursă pentru a indica IP-ul destinației imediat după copierea fiecărui cont. Aceasta minimizează fereastra în care un domeniu se rezolvă la serverul vechi. Utilizați aceasta doar dacă destinația este pregătită să servească trafic imediat și ați confirmat că toate aplicațiile funcționează corect.

Mail Routing: Setați aceasta la Automatic dacă nu aveți un motiv specific pentru a forța rutarea locală sau la distanță. Rutarea incorectă a emailurilor este una dintre principalele cauze ale eșecurilor de livrare a emailurilor post-migrare.

2.5 Inițiați transferul

Faceți clic pe Copy pentru a începe procesul. WHM va:

1. Se va conecta prin SSH la serverul sursă
2. Va rula pkgacct pentru a crea o arhivă comprimată a fiecărui cont
3. Va transfera arhiva la destinație prin SSH/SCP
4. Va rula restorepkg pe destinație pentru a extrage și crea contul
5. Va înregistra rezultatul pentru fiecare cont

Monitorizați cu atenție jurnalul de transfer în timp real. Erorile pentru conturile individuale nu opresc procesul general — un cont poate eșua silențios în timp ce altele reușesc. Examinați jurnalul complet după finalizarea transferului și rulați din nou conturile eșuate individual.

Durata transferului depinde de volumul total de date și lățimea de bandă dintre servere. Un server cu 50 GB de date de cont pe un link de 1 Gbps se finalizează de obicei în mai puțin de 30 de minute. Pe un link de 100 Mbps, planificați 60–90 de minute.

Pasul 3: Strategia de tranziție DNS

Gestionarea DNS este locul unde migrările creează cel mai adesea perioade extinse de nefuncționare. Înțelegerea mecanicii de propagare este esențială pentru minimizarea impactului asupra utilizatorilor.

3.1 Reduceți TTL înainte de migrare

În mod ideal, cu 24–48 de ore înainte de migrare, reduceți TTL-ul pe toate înregistrările A pentru domeniile găzduite la 300 de secunde (5 minute). Aceasta asigură că odată ce actualizați înregistrările DNS, modificarea se propagă global în câteva minute, nu ore. Dacă nu ați făcut acest lucru în avans, trebuie să luați în considerare valoarea TTL existentă ca fereastră maximă de propagare.

3.2 Actualizați zonele DNS

Dacă noul server este nameserver-ul autoritar pentru domenii, actualizați înregistrările A în fiecare fișier de zonă prin WHM > DNS Functions > Edit DNS Zone, schimbând IP-ul de la adresa serverului vechi la cea nouă.

Dacă domeniile folosesc un furnizor DNS extern sau DNS de registrar, conectați-vă la fiecare registrar sau panou de gestionare DNS și actualizați manual înregistrările A. Pentru actualizări în masă pe mai multe domenii, majoritatea registrarilor oferă acces API sau import CSV.

3.3 Actualizați înregistrările glue ale nameserver-elor

Dacă migrați și nameserver-ele (de ex., ns1.yourdomain.com), trebuie să actualizați înregistrările glue la registrarul de domenii — nu doar fișierul de zonă. Înregistrările glue sunt mapări de adrese IP pentru nameserver-ele înregistrate sub același domeniu pe care îl servesc. Neactualizarea înregistrărilor glue este o omisiune frecventă care cauzează eșecul complet al rezoluției DNS pentru toate domeniile găzduite.

3.4 Verificați propagarea

Utilizați dig pentru a verifica rezoluția din mai multe locații geografice:

dig A yourdomain.com @8.8.8.8
dig A yourdomain.com @1.1.1.1

Verificați încrucișat cu un verificator de propagare web. Propagarea globală completă se finalizează de obicei în 1–4 ore când TTL-ul a fost redus în prealabil, sau până la 48 de ore când TTL-ul nu a fost redus în avans.

Dacă domeniile dvs. sunt înregistrate prin Înregistrare Domenii, actualizările nameserver-elor pot fi gestionate direct din același panou de control, simplificând procesul de tranziție.

Pasul 4: Validarea post-migrare

Nu declarați niciodată o migrare completă bazându-vă exclusiv pe jurnalul de succes al Transfer Tool. Validați fiecare strat al stivei în mod independent.

4.1 Funcționalitatea aplicației web

Accesați fiecare domeniu transferat direct prin IP folosind o suprascriere a fișierului hosts (pentru a ocoli propagarea DNS) și verificați că aplicația se încarcă corect:

# Add to /etc/hosts on your local machine temporarily
203.0.113.50  yourdomain.com www.yourdomain.com

Verificați erorile de conexiune la baza de date, căile de fișiere lipsă și configurațiile de aplicații defecte. Site-urile WordPress eșuează frecvent dacă acreditivele bazei de date wp-config.php fac referire la localhost dar calea socket-ului MySQL diferă între servere.

4.2 Integritatea bazei de date

Conectați-vă la cPanel pentru fiecare cont și verificați că bazele de date există și sunt accesibile. Pentru bazele de date critice, rulați o verificare de integritate:

mysqlcheck -u root -p --all-databases --check

4.3 Funcționalitatea emailului

Testați emailul de intrare și de ieșire pentru fiecare cont. Verificați că înregistrările MX se rezolvă corect și că serverul de email acceptă conexiuni pe porturile 25, 465 și 587. Verificați /var/log/exim_mainlog pentru erorile de livrare:

tail -f /var/log/exim_mainlog

Pentru companiile cu infrastructură de email dedicată, Email Hosting oferă medii de email izolate care nu sunt afectate de migrările serverelor web.

4.4 Verificarea certificatelor SSL

Confirmați că certificatele SSL s-au transferat corect și sunt active. În WHM, navigați la SSL/TLS > Manage SSL Hosts și verificați că fiecare domeniu are un certificat valid, neexpirat. AutoSSL ar trebui să reemită automat certificatele Let’s Encrypt pentru cele care nu s-au transferat, dar declanșați-l manual pentru a evita așteptarea rulării programate:

/usr/local/cpanel/bin/autossl_check --all

Dacă gestionați certificatele independent, Certificatele SSL pot fi instalate direct pe noul server fără dependență de procesul de transfer.

4.5 Sarcini cron și activități programate

Sarcinile cron sunt transferate ca parte a pachetului de cont, dar verificați-le în cPanel > Cron Jobs pentru fiecare cont. Acordați atenție deosebită sarcinilor cron care fac referire la căi absolute de fișiere sau variabile de mediu specifice serverului care pot diferi pe noul server.

Pasul 5: Curățare și întărire post-migrare

5.1 Suspendați conturile pe serverul sursă

Odată ce DNS-ul s-a propagat și validarea este completă, suspendați toate conturile pe serverul sursă prin WHM > List Accounts > Suspend. Nu le ștergeți încă. Suspendarea previne scrierea de date noi pe sursă, menținând-o disponibilă ca fallback dacă apare o problemă critică post-migrare.

5.2 Backup post-migrare

Creați un backup complet proaspăt al tuturor conturilor pe noul server imediat după migrare. Starea transferată este noua dvs. linie de bază:

/scripts/cpbackup --force

Verificați că backup-urile se finalizează cu succes și sunt stocate într-o locație separată de server — ideal o destinație de backup off-server configurată în WHM > Backup Configuration.

5.3 Monitorizarea performanței

Monitorizați utilizarea resurselor noului server timp de 72 de ore post-migrare. Metrici cheie de urmărit:

• Media de încărcare CPU (ar trebui să rămână sub numărul de nuclee CPU în condiții normale de încărcare)
• Utilizarea memoriei și activitatea de swap
• Timpul de așteptare I/O pe disc (timpul de așteptare I/O ridicat indică blocaje de stocare)
• Jurnalul de interogări lente MySQL pentru interogările care performează slab pe noua schemă sau versiunea motorului

Utilizați top, iostat și vmstat pentru monitorizare în timp real și examinați Resource Monitor al cPanel în WHM pentru consumul de resurse per cont.

5.4 Dezafectați serverul sursă

După o perioadă minimă de observare de 7 zile fără probleme raportate, puteți dezafecta serverul sursă. Înainte de a termina vechiul server, arhivați un backup final în stocare rece. Această arhivă servește ca înregistrare legală și operațională și costă foarte puțin de păstrat.

Comparație metode de migrare a conturilor cPanel

Capcane frecvente și cum să le evitați

Eșecuri silențioase ale transferului de cont. Transfer Tool continuă procesarea chiar și când conturile individuale eșuează. Citiți întotdeauna jurnalul complet de transfer — nu presupuneți succesul pentru că instrumentul s-a terminat fără să se oprească.

Nepotrivirea privilegiilor utilizatorului MySQL. restorepkg recreează utilizatorii bazei de date, dar dacă un nume de utilizator al bazei de date depășește limita de 32 de caractere a MySQL (o problemă frecventă cu conturile vechi), utilizatorul este creat cu un nume trunchiat și acreditivele bazei de date ale aplicației nu mai corespund. Auditați numele lungi ale bazelor de date înainte de migrare.

Dependențe de module Perl și software personalizat. Aplicațiile care se bazează pe module Perl compilate personalizat, pachete Python sau biblioteci de sistem instalate în afara căilor gestionate de cPanel nu se vor transfera. Aceste dependențe trebuie reinstalate manual pe destinație.

Discrepanțe ale cotelor de disc. Sistemul de cote de disc al cPanel folosește cote la nivel de sistem de fișiere. După migrare, cotele pot să nu reflecte cu acuratețe până când rulează scriptul de recalculare a cotelor:

/scripts/fixquotas

Conflicte de reguli ModSecurity. Dacă serverul sursă a avut reguli ModSecurity personalizate sau o versiune diferită a setului de reguli față de destinație, site-urile transferate pot primi erori 403 neașteptate. Examinați jurnalele ModSecurity la /usr/local/apache/logs/error_log după migrare.

Lacune de permisiuni ale contului reseller. ACL-urile reseller și atribuirile de pachete se transferă, dar dacă WHM-ul destinație are liste de funcționalități diferite configurate, resellerii pot constata că conturile lor au mai puține sau diferite capabilități față de cele așteptate. Auditați configurațiile reseller post-migrare.

Pentru mediile cu trafic ridicat unde toleranța la nefuncționare este aproape zero, luați în considerare rularea migrării pe un Server Dedicat cu resurse dedicate, eliminând riscul de contention de resurse în timpul fazelor de transfer și validare.

Matricea de decizie tehnică

Utilizați această matrice pentru a determina abordarea de migrare în funcție de caracteristicile mediului:

Întrebări frecvente

Pot migra conturile cPanel fără acces root la serverul sursă?

Nu. WHM Transfer Tool necesită acces SSH root la serverul sursă pentru a rula pkgacct și a citi toate datele contului. Dacă accesul root nu este disponibil, singura alternativă este să solicitați fișiere de backup cPanel individuale (arhive .tar.gz) de la administratorul serverului sursă și să le restaurați manual folosind restorepkg pe destinație.

Cât durează o migrare completă a serverului cPanel?

Timpul de transfer depinde de volumul total de date și lățimea de bandă a rețelei dintre servere. Un server cu 100 GB de date de cont pe un link dedicat de 1 Gbps se transferă de obicei în 15–30 de minute. Pe conexiuni partajate sau limitate, aceleași date pot dura câteva ore. Propagarea DNS adaugă 1–48 de ore suplimentare în funcție de valorile TTL.

Certificatele SSL se transferă automat?

Certificatele SSL instalate prin AutoSSL (Let’s Encrypt) nu se transferă ca certificate valide — sunt reemise de AutoSSL pe serverul destinație deoarece sunt legate de IP-ul serverului și cont. Certificatele achiziționate comercial stocate în cPanel se transferă ca parte a pachetului de cont, dar trebuie verificate și reactivate post-migrare.

Ce se întâmplă cu emailul de pe vechiul server în timpul ferestrei de migrare?

Emailul livrat la vechiul server în timpul ferestrei de migrare este stocat în coada de email a vechiului server și cutiile poștale ale utilizatorilor. Nu se replică automat pe noul server. Pentru a preveni pierderea emailurilor, fie mențineți serviciile de email ale vechiului server funcționale până când DNS-ul se propagă complet, fie configurați Exim-ul vechiului server să relayeze emailul de intrare la IP-ul noului server în perioada de tranziție.

Poate WHM Transfer Tool migra conturi între sisteme de operare diferite (de ex., CentOS la AlmaLinux)?

Da. Transfer Tool este agnostic față de sistemul de operare la nivelul aplicației — transferă datele contului cPanel, nu configurațiile la nivel de sistem de operare. Migrările de la CentOS 7 la AlmaLinux 8 sau Rocky Linux 8 sunt complet suportate și reprezintă cel mai frecvent scenariu de migrare în urma sfârșitului de viață al CentOS 7. Verificați că orice configurații personalizate la nivel de sistem (politici SELinux, module kernel personalizate, servicii non-cPanel) sunt replicate manual pe destinație.