Mutarea unui site de pe shared hosting pe un VPS Linux nu trebuie să însemne ore de cădere sau un haos în care unii vizitatori văd versiunea veche, iar alții pe cea nouă. Dacă migrarea este pregătită corect, întreruperea poate fi redusă la minimum, iar în multe cazuri utilizatorii nici nu observă schimbarea.
Cheia este să tratezi mutarea ca pe un proces în două etape: pregătirea noului server și schimbarea controlată a traficului. Nu începi cu DNS-ul, ci cu inventarul site-ului. Verifică ce rulează acum pe shared hosting: versiunea de PHP, extensiile folosite, baza de date, joburile cron, certificatele SSL, e-mailurile și orice dependență de cache sau de panoul de hosting. Dacă sari peste acest pas, riști ca site-ul să pornească pe VPS, dar să se blocheze exact în funcțiile importante.
Pregătirea VPS-ului Linux vine înainte de orice schimbare publică. Instalează stack-ul necesar, configurează utilizatorii, permisiunile, firewall-ul, backup-ul și monitorizarea de bază. Dacă folosești Nginx, documentația oficială arată clar cum poate funcționa ca reverse proxy, ceea ce poate fi util în anumite arhitecturi sau pentru aplicații separate. Important este ca noul mediu să fie cât mai apropiat de cel actual, dar mai curat și mai controlabil.
După server, urmează datele. Fișierele site-ului pot fi sincronizate în siguranță, iar pentru volume mai mari rsync rămâne una dintre cele mai bune opțiuni, tocmai pentru că transferă doar diferențele dintre sursă și destinație. Asta îl face util nu doar pentru copierea inițială, ci și pentru o sincronizare finală, chiar înainte de mutarea efectivă. Pentru baza de date, un export corect și un import verificat sunt esențiale. Documentația MariaDB arată că mariadb-dump este destinat exact pentru backup sau transfer către alt server de baze de date.
Partea care face diferența între o migrare liniștită și una stresantă este strategia DNS. Google Cloud explică în documentația sa că valoarea TTL controlează cât timp rezolvatoarele DNS păstrează informația în cache și avertizează că unele rezolvatoare pot ignora TTL-ul sau pot propaga schimbările cu întârziere. Pe scurt, dacă știi că vei muta site-ul, e bine să reduci TTL-ul cu suficient timp înainte, nu în ultimul minut. Astfel, când schimbi IP-ul, o parte mai mare din internet va actualiza mai repede noua rută.
Înainte să schimbi DNS-ul, testează site-ul pe VPS în mod izolat. Verifică paginile importante, autentificarea, formularele, căutarea, pluginurile, imaginile, încărcarea fișierelor și eventualele integrări externe. Dacă site-ul are magazin online, rezervări sau comentarii active, trebuie să fii atent mai ales la conținutul care se schimbă în timp real. Aici apare adevărata provocare: fișierele se mută ușor, dar datele dinamice cer un moment de sincronizare finală.
De aceea, pentru site-urile cu scrieri frecvente în baza de date, o fereastră scurtă de îngheț pentru acțiuni critice poate fi mai sigură decât o mutare “din mers”. Poți limita temporar comenzile, comentariile sau editările, faci ultimul export de bază de date, rulezi sincronizarea finală a fișierelor și abia apoi actualizezi DNS-ul. Asta reduce riscul ca date noi să rămână pe vechiul hosting și să nu ajungă pe VPS.
Nu uita de HTTPS. Certificatul trebuie pregătit din timp sau reemis imediat ce noul server răspunde corect pentru domeniu. Let’s Encrypt explică faptul că emiterea certificatelor se face automat prin protocolul ACME, cu ajutorul unui client dedicat. Cu alte cuvinte, nu lăsa SSL-ul pe lista de după lansare, pentru că utilizatorii văd imediat dacă site-ul răspunde nesigur.
După schimbarea DNS-ului, nu închide imediat vechiul hosting. Ține-l activ o perioadă, urmărește logurile, verifică răspunsurile serverului, cache-ul, certificatele și eventualele erori 404 sau 500. Dacă infrastructura ta este cPanel la ambele capete, există și opțiuni oficiale de Live Transfer, dar pentru multe proiecte mici și medii, o migrare clasică, bine planificată, rămâne cea mai predictibilă.
Pe scurt, migrarea fără downtime major nu depinde de un singur truc, ci de ordine: pregătești VPS-ul, copiezi datele, testezi, reduci TTL-ul din timp, faci sincronizarea finală și schimbi DNS-ul doar când noul server este gata. Dacă grăbești ultimul pas, riscul nu este doar downtime-ul, ci și pierderea de date sau apariția unor erori greu de observat în primele minute.
