Cum îți muți VPS-ul la un furnizor nou fără întrerupere

Fiecare poveste de groază despre o migrare are aceeași parte din mijloc: cineva a schimbat întâi DNS-ul și abia apoi a început să copieze. Întreruperea în timpul unei mutări aproape niciodată nu vine din copierea lentă. Vine din pașii făcuți în ordinea greșită.

Iată ordinea care merge, fie că pleci de la alt furnizor, fie că te muți între două dintre planurile noastre.

1. Cu două zile înainte: scade TTL-ul

Găsește înregistrările DNS pe care le vei schimba (de obicei A, AAAA și orice CNAME care indică spre ele) și scade-le TTL-ul la 300 de secunde. Apoi așteaptă cel puțin cât era vechiul TTL. O înregistrare cu un TTL de o zi înseamnă că unele resolvere vor servi adresa veche încă o zi după ce o schimbi și nimic din ce faci pe server nu poate grăbi asta.

E pasul pe care oamenii îl sar și e cel care transformă o comutare de cinci minute într-o zi în care jumătate dintre utilizatori văd serverul vechi.

2. Fă un inventar al serverului vechi

Vei reconstrui mașina asta în altă parte, așa că notează ce face de fapt. Nu ce îți amintești că face. Ce face:

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

Adaugă pe listă: certificatele TLS și cum se reînnoiesc, fișierele de mediu cu secrete, regulile de firewall, utilizatorii și cheile lor SSH, baza de date și mărimea ei și tot ce vorbește cu serverul după adresa IP. Ultimul grup e cel perfid: lista albă a unui partener, setările de webhook ale unui procesator de plăți, o verificare de monitorizare.

3. Construiește serverul nou lângă cel vechi

Comandă serverul nou și lasă-l pe cel vechi în pace. Alege un plan din lista VPS cu același disc sau cu unul mai mare decât folosești acum, nu decât ți s-a vândut. Dacă mașina veche primește orice trafic de intrare (un site, webhookuri, un API), cea nouă are nevoie de propriul IPv4. Un plan NAT acceptă conexiuni de intrare doar pe portul SSH, iar ce poate și ce nu poate face un singur port redirecționat explică de ce contează.

Conectează-te, instalează aceleași pachete, recreează utilizatorii și firewallul. Ghidul de conectare acoperă cheile și prima autentificare.

4. Sincronizează fișierele de două ori

Prima sincronizare copiază tot cât serverul vechi lucrează în continuare. Poate dura ore; e în regulă.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids păstrează proprietarii fișierelor după număr, ceea ce evită clasica surpriză „totul aparține utilizatorului greșit”, când cele două sisteme au creat utilizatorii în altă ordine. Dacă n-ai folosit niciodată rsync prin SSH, transferul de fișiere pe un VPS te duce prin el.

A doua sincronizare, chiar înainte de comutare, copiază doar ce s-a schimbat de la prima. De obicei durează câteva secunde.

5. Mută baza de date cu grijă

Fișierele sunt ușoare. O bază de date care primește scrieri e singura parte în care „fără întrerupere” cere fie un mic compromis, fie mai multă muncă.

Calea simplă: faci dump și restore o dată pentru test, apoi, la comutare, oprești scrierile pentru un minut (treci aplicația în mod read-only sau o oprești), iei un dump proaspăt, îl restaurezi pe serverul nou și pornești aplicația acolo. Pentru majoritatea proiectelor mici, asta înseamnă o pauză de un minut sau două, anunțată dinainte.

Calea fără pauză: configurezi replicarea de la baza de date veche spre cea nouă, o lași să ajungă la zi, apoi o promovezi pe cea nouă la comutare. E mai multă configurare și merită când chiar și un minut de scrieri pierdute e inacceptabil.

6. Testează serverul nou înainte să-l vadă altcineva

DNS-ul indică încă serverul vechi, deci îl poți testa pe cel nou în privat. Trimite o cerere pentru domeniul tău real spre adresa nouă:

curl --resolve example.com:443:203.0.113.10 https://example.com/health

Dacă certificatul nu e încă acolo, testează la fel prin HTTP sau adaugă o linie temporară în fișierul hosts și dă clic prin site într-un browser. Verifică autentificările, încărcările, sarcinile de fundal și e-mailurile trimise. E cel mai ieftin moment să descoperi o extensie PHP lipsă.

7. Comută și lasă serverul vechi pornit

Fă sincronizarea finală a fișierelor și pasul bazei de date, apoi schimbă înregistrările DNS. Cu un TTL de 300 de secunde, cea mai mare parte a traficului se mută în câteva minute. Urmărește logul de acces al serverului vechi: va primi în continuare un firicel de cereri de la resolverele și clienții care ignoră TTL-ul. Lasă-l pornit, neschimbat, câteva zile. Apoi actualizează ce indică vechiul IP: listele albe ale partenerilor, URL-urile de webhook și, pentru e-mail, reverse DNS-ul adresei noi (pe planurile noastre cu IP dedicat îl setezi singur, vezi reverse DNS) și înregistrarea SPF.

Ce se strică cel mai des

În ordinea aproximativă în care le vedem: un timer systemd pe care nu l-a trecut nimeni pe listă, un fișier de configurație cu vechiul IP scris direct, fișiere ale utilizatorului greșit, un firewall care blochează chiar portul aplicației, un certificat care se reînnoiește pe serverul vechi, dar nu și pe cel nou, și e-mailuri care ajung în spam pentru că adresa nouă nu are încă reverse DNS.

Unde nu se potrivește lista asta

O bază de date aglomerată, cu scrieri constante și fără toleranță la pauze, are nevoie de replicare făcută cum trebuie și de o repetiție, nu de o listă de pe un blog. Serverele Windows se mută cu alte unelte decât rsync. Iar dacă mutarea e de fapt despre mărime, citește întâi asta: planurile de aici cresc pe loc. Trecerea la un plan mai mare cu același tip de rețea adaugă vCPU, RAM și disc cu o singură repornire, fără nicio migrare. Doar micșorarea cere un server nou. Dacă te muți pentru că nu ești sigur că mașina e destul de mare, când ai nevoie de fapt de 64 GB de RAM te poate scuti de drum, iar VPS vs shared hosting vs server dedicat vs cloud te ajută dacă nu ești sigur că un VPS e casa potrivită.