Migrare de la shared hosting la VPS: Ghidul "Zero Downtime" (pas cu pas)

"Frica de schimbare" te costă bani

În industria de hosting, noi numim fenomenul ăsta "Vendor Lock-in pe bază de frică". Vedem proprietari de afaceri blocați în planuri de shared hosting de 5€/lună care "crapă" de fiecare dată când trimit un newsletter. Ei știu că au nevoie de un Server VPS. Știu că site-ul se mișcă în reluare. Dar sunt îngroziți de ideea că mutarea pe un server nou înseamnă 48 de ore de erori "Site Not Found".

Am făcut peste 1.500 de migrări în total. Dacă treaba e făcută ca la carte, vizitatorii tăi- și Google - nici nu vor ști că s-a întâmplat ceva, până nu vor observa că site-ul se încarcă instant. Mutarea dintr-un mediu shared limitat către un VPS de înaltă performanță nu e magie; e o secvență de pași logici. Acest ghid prezintă procedura exactă rsync/bază de date pe care o folosim la ServerSpan pentru a garanta zero downtime.

Faza 1: Strategia "TTL" dinaintea migrării

Teoria:
Cea mai mare cauză a downtime-ului nu este transferul fișierelor, ci propagarea DNS. Dacă Time To Live (TTL) al domeniului tău este setat la 14400 secunde (4 ore) și schimbi serverele, jumătate din planetă va vedea serverul vechi, iar cealaltă jumătate pe cel nou. Asta duce la probleme de date tip "split-brain" (date desincronizate), unde comenzile clienților se pierd pe serverul vechi. Poți citi mai multe despre cum funcționează înregistrările DNS aici.

Implementarea:
Cu 48 de ore înainte de a planifica migrarea, intră în contul de la registrar (sau Cloudflare) și scade TTL-ul înregistrărilor A la 300 de secunde (5 minute).

Cazul limită (Edge Case):
Unii registrari ieftini au TTL hardcodat la o oră. Dacă ești în barca asta, n-ai de ales decât să aștepți. De aceea recomandăm să muți DNS-ul de la furnizorul de hosting imediat. Folosește un serviciu DNS dedicat.

---

---

Faza 2: Sincronizarea mediului (Environment matching)

Teoria:
Shared hosting-ul e adesea în urmă cu tehnologia. S-ar putea să rulezi PHP 7.4 pe vechiul host, în timp ce noul tău VPS Linux vine cu PHP 8.2 standard. Mutarea unui site WordPress vechi pe un stack modern va genera erori critice instantaneu.

Implementarea:
Verifică mai întâi versiunea curentă. Creează un fișier `info.php` pe hostul shared:

<?php phpinfo(); ?>

Asigură-te că această configurare VPS se potrivește inițial cu această versiune. Poți face upgrade după ce migrarea e stabilă. La ServerSpan, imaginile noastre de Managed VPS îți permit să schimbi versiunile PHP per domeniu ca să eviți exact șocul ăsta.

Faza 3: Mutarea fișierelor (Nu mai folosi FTP)

Teoria:
FTP-ul e depășit și ineficient. Deschide o conexiune nouă pentru fiecare fișier în parte. Dacă ai un site Magento sau WordPress cu 50.000 de fișiere mici, prin FTP îmbătrânești lângă calculator. Ai nevoie de `rsync`. Deoarece majoritatea host-urilor shared îți oferă acces SSH (sau măcar un terminal web), ar trebui să "tragi" fișierele dinspre noul VPS.

Implementarea:
Loghează-te pe noul Server VPS prin SSH. Rulează comanda de mai jos pentru a copia fișierele de pe vechiul host. Asta păstrează permisiunile, data modificării și symlink-urile.

# Sintaxa: rsync [flags] [user]@[remote_host]:[source_path] [destination_path]

rsync -avzP --exclude 'wp-content/cache' user@old-shared-host.com:~/public_html/ /var/www/html/

Cazul limită (Edge Case):
Stocare VPS vs. limite Inode. Host-urile shared măsoară adesea utilizarea în "inode-uri" (număr de fișiere). Când faci `rsync` la milioane de fișiere cache minuscule, s-ar putea să atingi limita de inode-uri pe noua partiție dacă nu e formatată corect. Exclude întotdeauna folderul `/cache`. Oricum vrei ca noul server să genereze un cache curat.

Faza 4: Migrarea bazei de date

Teoria:
Fișierele sunt statice; bazele de date sunt dinamice. Ăsta e momentul adevărului. Ca să nu ai date corupte, pune vechiul site în "Maintenance Mode" pentru cele 5 minute cât durează operațiunea. Dacă nu faci asta, un client ar putea să-și facă cont fix în timp ce tu exporți baza, iar contul lui va fi pierdut.

Implementarea:
Pe vechiul host, exportă baza de date:

mysqldump -u username -p database_name > dump.sql

Transfer-o pe noul VPS NVMe (folosește `scp` sau `rsync`) și import-o:

mysql -u root -p new_database_name < dump.sql

Cazul limită (Edge Case):
Encodarea caracterelor (Eroarea "????"). Vedem des furnizori de VPS ieftin care au implicit encodarea `latin1`. Dacă baza ta de date veche e `utf8mb4` (care suportă diacritice și emoji) și o imporți într-un server setat pe `latin1`, tot textul se va transforma în semne de întrebare. Verifică mereu ca `/etc/mysql/my.cnf` pe noul server să aibă `character-set-server = utf8mb4` înainte de import.

---

---

Faza 5: Trucul cu fișierul "hosts" (Testarea)

Teoria:
Trebuie să vezi dacă site-ul merge pe noul server înainte să schimbi DNS-ul pentru tot internetul. Poți păcăli calculatorul tău să creadă că domeniul s-a mutat deja.

Implementarea:
Editează fișierul `hosts` pe laptopul tău.

• Windows: `C:\Windows\System32\drivers\etc\hosts`
• Mac/Linux: `/etc/hosts`

Adaugă o linie la final:

192.0.2.123  domeniultau.ro www.domeniultau.ro

Înlocuiește `192.0.2.123` cu noul tău IP VPS. Acum, deschide browserul. Tu navighezi pe site-ul de pe noul server, în timp ce restul lumii e încă pe cel vechi. Testează coșul de cumpărături, formularele de contact și login-ul de admin.

Faza 6: Comutarea și SSL-ul

Teoria:
După ce te-ai convins că totul e OK, intră la furnizorul DNS și actualizează înregistrarea A (A Record) către noul IP. Deoarece ai scăzut TTL-ul în Faza 1, schimbarea se va propaga global în câteva minute. Pentru detalii despre transferul complet al domeniului, consultă ghidul nostru despre transferul fără downtime.

Implementarea:
Rulează imediat Certbot (Let's Encrypt) pe noul server. Certificatele SSL nu se migrează bine; e mai curat să generezi unul nou.

certbot --nginx -d domeniultau.ro -d www.domeniultau.ro

Cazul limită (Edge Case):
Dacă folosești Cloudflare Proxy (Norul Portocaliu), nu trebuie să aștepți propagarea. Doar schimbă IP-ul în dashboard-ul Cloudflare. Totuși, asigură-te că firewall-ul de pe noul plan de VPS Hosting (UFW/iptables) permite conexiuni de la IP-urile Cloudflare, altfel site-ul va fi offline cu eroarea 522.

Faza 7: Curățenia post-migrare

Teoria:
Ești pe un VPS dedicat puternic acum. Nu lăsa setările implicite. Fișierele de configurare din shared hosting (`wp-config.php`, `.htaccess`) sunt pline de limitări pentru a nu consuma resurse.

Implementarea:
Mărește limitele PHP imediat. Ai plătit pentru RAM; folosește-l.

memory_limit = 256M
upload_max_filesize = 64M
max_execution_time = 300

De asemenea, șterge orice plugin-uri de backup care salvează arhive pe discul local. Acum ar trebui să folosești soluții de backup VPS la nivel de server sau stocare offsite.

Gânduri de final din partea echipei tehnice

Prima migrare e cea mai grea. Anxietatea e reală, dar recompensa e pe măsură. Un site care se mută de la shared hosting la un pachet de Găzduire VPS ServerSpan vede de obicei o reducere a TTFB (timpul până la primul byte) de 600ms sau mai mult. Asta e aur curat pentru SEO.

Dacă cititul despre flag-uri `rsync` și seturi de caractere MySQL îți dă transpirații, amintește-ți că noi asta facem toată ziua. ServerSpan oferă asistență gratuită la migrare cu planurile noastre managed. Noi ne ocupăm de `dump.sql`, de TTL și de stres, ca tu doar să te loghezi și să vezi un site care zboară.