Mutarea unui site pe serverul BLACKBOX

Ghidul descrie mutarea unui site de la alt furnizor pe un server BLACKBOX cu o întrerupere cât mai scurtă pentru vizitatori: inventarul, copierea fișierelor și a bazei de date, testul pe calculatorul dvs. și schimbarea DNS. Comenzile pentru servere se rulează prin SSH; câteva verificări le faceți pe calculatorul dvs. Adresa serverului nou este în panoul app.blackbox.md, pagina „Serverele mele” (app.blackbox.md/my-servers, bara laterală → „Infrastructură” → „Serverele mele”), câmpul „IP”.

Disponibil pentru: oricine are acces root prin SSH la un server BLACKBOX și poate modifica DNS-ul domeniului. Mutarea făcută de echipa BLACKBOX: la cerere, prin suport (ultima secțiune).

Planul pe scurt

Până la etapa 7, vizitatorii folosesc vechiul server. Singura pauză este sincronizarea finală, cât timp vechiul site este în modul de mentenanță.

Pasul 1. Faceți inventarul

Pe vechiul server, dacă aveți acces SSH (CALE_VECHE este directorul site-ului):

du -sh CALE_VECHE
php -v
php -m
crontab -l

La găzduirea partajată, versiunea PHP a site-ului poate fi alta decât cea afișată de php -v: verificați-o și în panoul găzduirii.

Pe calculatorul dvs., aflați cine administrează DNS-ul (NS) și unde ajunge emailul (MX). Linux sau macOS:

dig +short NS DOMENIU
dig +short MX DOMENIU

Windows:

nslookup -type=NS DOMENIU
nslookup -type=MX DOMENIU

Alegeți apoi planul și sistemul de operare (Planurile VPS: cum alegeți, Sistemele de operare disponibile). Discul trebuie să încapă și fișierele de export. Versiunea PHP din depozitele standard:

Pasul 2. Coborâți TTL-ul cu 48 de ore înainte

TTL-ul spune cât timp păstrează serverele DNS din lume un răspuns în cache. Cu cel puțin 48 de ore înainte de comutare, schimbați TTL-ul înregistrărilor A (și AAAA sau CNAME, dacă există) pentru DOMENIU și www la 300 de secunde. Adresa IP nu o schimbați încă. Verificați la serverul NS al domeniului (SERVER_NS este unul dintre numele afișate de comanda NS de mai sus); numărul de după nume este TTL-ul:

dig +noall +answer DOMENIU A @SERVER_NS

Pe Windows, căutați în rezultat rândul ttl =:

nslookup -debug -type=A DOMENIU SERVER_NS

• Dacă ați conectat contul Cloudflare sau GoDaddy în pagina „DNS” a panoului, apăsați creionul („Editează”) pe rândul înregistrării, alegeți TTL-ul din listă și apăsați „Salvează”: la Cloudflare, 300; la GoDaddy, minimul din listă este 600 (10 minute). Vedeți Gestionarea înregistrărilor DNS din panou. La alt furnizor DNS, schimbați TTL-ul în panoul lui.
• La Cloudflare, înregistrările „Proxied” (în panou, caseta „Proxy”) au TTL automat și schimbarea IP-ului ajunge aproape imediat. Cu modul SSL „Full (strict)”, serverul nou are nevoie de un certificat valid încă de la comutare: cel mai simplu, treceți înregistrările pe „DNS only” pe durata mutării și reactivați proxy-ul după ce HTTPS funcționează.

Important Fără acest pas, unii vizitatori pot ajunge la vechiul server încă mult după comutare: cât era TTL-ul vechi, uneori 86400 de secunde (o zi). După 48 de ore, serverele DNS au preluat TTL-ul de 300, iar noua adresă ajunge la vizitatori în aproximativ 5 minute (10 minute cu un TTL de 600).

Pasul 3. Pregătiți serverul nou

1. Comandați serverul și conectați-vă la el: Conectarea la server prin SSH (Windows, macOS, Linux).
2. Instalați serverul web și limbajul aplicației: Server web cu HTTPS: nginx sau Apache și Let's Encrypt, WordPress pe LEMP (nginx, MariaDB, PHP), Aplicații Node.js, Python și alte servicii: nginx ca reverse proxy sau Instalarea Docker și Docker Compose.
3. Instalați serverul de baze de date și creați baza și utilizatorul: Baze de date: MariaDB/MySQL și PostgreSQL. Cu aceleași nume și parole ca la vechiul server aveți mai puțin de modificat.
4. Creați configurația serverului web pentru DOMENIU și www.DOMENIU. Certificatul Let's Encrypt îl obțineți la pasul 7.

Filtrarea din rețea administrată de BLACKBOX lasă să treacă implicit SSH (22), HTTP (80), HTTPS (443) și ping. Țineți baza de date pe același server cu site-ul; pentru alte porturi scrieți suportului (Firewall: filtrarea din rețea și ufw/firewalld pe server).

Pasul 4. Copiați fișierele

Direct de pe vechiul server (recomandat)

Serverul nou preia fișierele de la cel vechi. Conectați-vă la serverul nou și porniți o sesiune tmux, ca să continue copierea chiar dacă legătura cade:

tmux new -s migrare

În sesiune, rulați copierea; vi se cere parola vechiului server (la prima conectare, confirmați întâi cu yes):

mkdir -p /var/www/DOMENIU
rsync -avzP root@IP_SERVER_VECHI:CALE_VECHE/ /var/www/DOMENIU/

• Slash-ul de la sfârșitul CALE_VECHE/ copiază conținutul directorului, nu directorul însuși.

• Dacă la vechiul furnizor nu sunteți root, folosiți utilizatorul primit de la el.

• Dacă SSH-ul vechiului furnizor folosește alt port decât 22 (PORT), adăugați-l cu -e. La fel procedați la comenzile rsync de la pasul 5.

  rsync -avzP -e "ssh -p PORT" root@IP_SERVER_VECHI:CALE_VECHE/ /var/www/DOMENIU/

• Dacă acolo intrați cu o cheie de pe calculator, încărcați-o în ssh-agent (Generarea unei chei SSH (Windows, macOS, Linux)) și conectați-vă la serverul nou cu -A, ca rsync să folosească cheia fără s-o copiați pe server:

  ssh -A root@IP_SERVER

• Ieșiți din sesiune cu Ctrl + B, apoi D; reveniți cu tmux attach -t migrare. Dacă tmux sau rsync lipsesc, instalați-le ca în Transferul fișierelor pe server (scp, rsync, SFTP).

Prin calculatorul dvs.

Dacă vechiul furnizor oferă doar FTP sau un manager de fișiere, descărcați fișierele (sau o arhivă din panoul găzduirii) pe calculator și urcați-le pe serverul nou cu rsync, scp sau un client SFTP, ca în Transferul fișierelor pe server (scp, rsync, SFTP).

La final, dați fișierele utilizatorului serverului web. Pe Ubuntu și Debian:

chown -R www-data:www-data /var/www/DOMENIU

Pe AlmaLinux și CentOS Stream, utilizatorul este nginx sau apache, iar SELinux cere etichete corecte: detaliile sunt în același articol despre transferul fișierelor.

Pasul 5. Mutați baza de date

MySQL sau MariaDB

Pe vechiul server (--single-transaction face o copie consistentă fără să oprească site-ul; dacă aveți doar phpMyAdmin, folosiți exportul lui în format SQL):

mysqldump --single-transaction --routines --triggers -u UTILIZATOR_BD -p NUME_BD | gzip > NUME_BD.sql.gz

Pe serverul nou, după ce ați creat baza și utilizatorul, preluați fișierul din directorul personal al utilizatorului vechi și importați-l:

rsync -avP root@IP_SERVER_VECHI:NUME_BD.sql.gz /root/
gunzip < /root/NUME_BD.sql.gz | mysql NUME_BD

PostgreSQL

Pe vechiul server:

pg_dump -Fc -h localhost -U UTILIZATOR_BD NUME_BD > NUME_BD.dump

Pe serverul nou, baza trebuie să aibă ca proprietar utilizatorul aplicației. Dacă nu le-ați creat încă (prima comandă cere parola noului utilizator):

sudo -u postgres createuser --pwprompt UTILIZATOR_BD
sudo -u postgres createdb -O UTILIZATOR_BD NUME_BD

Preluați exportul și restaurați-l; cu --role, tabelele aparțin utilizatorului aplicației:

rsync -avP root@IP_SERVER_VECHI:NUME_BD.dump /tmp/
sudo -u postgres pg_restore --no-owner --no-acl --role=UTILIZATOR_BD -d NUME_BD /tmp/NUME_BD.dump

După sincronizarea finală (pasul 7), ștergeți fișierele de export de pe ambele servere.

Actualizați configurația aplicației

Gazda bazei devine de regulă localhost (la găzduirea partajată era adesea alt server). Căile vechi rămase în fișiere le găsiți cu comanda de mai jos. Apoi goliți cache-ul aplicației, dacă are unul.

grep -rl "CALE_VECHE" /var/www/DOMENIU

Pasul 6. Testați prin fișierul hosts

Fișierul hosts îndreaptă domeniul spre serverul nou doar pe calculatorul dvs.; ceilalți vizitatori văd în continuare vechiul site. Adăugați la sfârșitul fișierului linia:

IP_SERVER DOMENIU www.DOMENIU

Windows

1. În meniul Start tastați „Notepad”, faceți clic dreapta pe aplicație și alegeți „Executare ca administrator”.

2. Deschideți C:\Windows\System32\drivers\etc\hosts (în fereastra de deschidere alegeți afișarea tuturor fișierelor, *.*), adăugați linia și salvați.

3. În PowerShell, goliți cache-ul DNS și verificați: în rezultatul ping trebuie să apară IP_SERVER.

   ipconfig /flushdns
   ping -n 1 DOMENIU

macOS și Linux

1. Deschideți fișierul, adăugați linia, salvați cu Ctrl + O, Enter și ieșiți cu Ctrl + X:

   sudo nano /etc/hosts

2. Pe macOS, goliți cache-ul DNS:

   sudo dscacheutil -flushcache
   sudo killall -HUP mDNSResponder

3. Verificați: în rezultat trebuie să apară IP_SERVER.

   ping -c 1 DOMENIU

Ce testați

Redeschideți browserul și verificați tot ce folosesc vizitatorii: paginile principale, zona de administrare, formularele, încărcarea imaginilor, căutarea, coșul și plata. Serverul nou nu are încă certificat pentru domeniu, deci la https:// browserul afișează o eroare sau un avertisment de securitate: la acest test este normal. Dacă site-ul trece singur pe https:// și browserul nu vă lasă să continuați, instalați pe serverul nou certificatul actual de pe vechiul server (pasul 7, punctul 6). Nu porniți încă sarcinile cron pe serverul nou, ca să nu trimită emailuri sau să proceseze comenzi în paralel cu vechiul server.

După test, ștergeți linia din fișierul hosts și goliți din nou cache-ul DNS.

Pasul 7. Sincronizarea finală și comutarea

1. Opriți modificările pe vechiul site (modul de mentenanță al aplicației sau o pagină temporară), ca să nu se piardă comenzi sau comentarii noi.

2. Rulați din nou comanda rsync de la pasul 4: copiază doar fișierele schimbate.

3. Exportați și importați din nou baza de date, ca la pasul 5. Un export făcut cu mysqldump înlocuiește la import tabelele existente; la exportul din phpMyAdmin, activați în opțiuni adăugarea instrucțiunilor DROP TABLE. La PostgreSQL, adăugați --clean --if-exists la pg_restore.

4. La furnizorul DNS, schimbați valoarea înregistrărilor A pentru DOMENIU și www în IP_SERVER (un CNAME www → DOMENIU poate rămâne). Ștergeți înregistrările AAAA ale vechii găzduiri. Nu modificați MX și TXT (excepțiile sunt în secțiunea „Emailul”). Pașii: Cum îndreptați domeniul către server.

5. După circa 5 minute (10 minute cu un TTL de 600), verificați că răspunsul este IP_SERVER. Linux sau macOS:

   dig +short DOMENIU A @1.1.1.1

   Windows:

   nslookup DOMENIU 1.1.1.1

6. Obțineți imediat certificatul Let's Encrypt (cu Apache, --apache în loc de --nginx; instalarea certbot: Server web cu HTTPS: nginx sau Apache și Let's Encrypt):

   certbot --nginx -d DOMENIU -d www.DOMENIU

   Până atunci, vizitatorii care ajung deja pe serverul nou prin HTTPS văd un avertisment. Ca să evitați această pauză, instalați pe serverul nou, înainte de comutare, certificatul actual și cheia lui, copiate de pe vechiul server. Un certificat comercial îl mutați oricum așa.

7. Porniți sarcinile cron pe serverul nou și opriți-le pe cel vechi.

8. Urmăriți jurnalele serverului web (cu Apache: /var/log/apache2/ pe Ubuntu și Debian, /var/log/httpd/ pe AlmaLinux și CentOS Stream) și pe cele ale aplicației:

   tail -f /var/log/nginx/access.log /var/log/nginx/error.log

Pasul 8. După comutare

• Urmăriți jurnalul de acces al vechiului server: când nu mai sosesc vizitatori, ci doar roboți ocazionali, toată lumea folosește serverul nou.
• Păstrați vechea găzduire activă câteva zile și verificați formularele, plățile, emailurile trimise de site și sarcinile cron.
• Readuceți TTL-ul înregistrărilor la 3600.
• Configurați copiile de rezervă: BLACKBOX nu face copii automate ale serverului dvs. Vedeți Strategia de backup pentru serverul dvs..

Ireversibil Anularea vechii găzduiri șterge de regulă definitiv fișierele, bazele de date și căsuțele de email de acolo. Anulați-o doar după ce totul funcționează pe serverul nou, emailul a fost mutat (dacă era tot acolo) și aveți o copie finală a vechiului site.

Emailul

Emailul nu se mută odată cu site-ul. Înregistrarea MX aflată la pasul 1 vă spune ce faceți:

Dacă site-ul trimite emailuri (formulare, notificări), configurați-l să le trimită prin serverul SMTP al furnizorului de email, cu utilizator și parolă, nu direct de pe serverul nou.

Atenție Dacă emailul este găzduit în altă parte, nu modificați înregistrările MX: mesajele noi ar fi îndreptate spre un server fără căsuțe de email și nu ar mai ajunge la dvs.

Mutarea făcută de echipa BLACKBOX

Pagina „Migrare gratuită de la alți furnizori” (blackbox.md/solutions/migration, meniul „Soluții” → „Migrarea proiectelor”) descrie serviciul de migrare la cerere: fișiere, baze de date, panouri de control, email și comutarea DNS. Pentru clienții noi cu un VPS sau hosting plătit, migrarea unui singur VPS, cont de hosting sau panou de control către un serviciu BLACKBOX nou este publicată ca gratuită; proiectele complexe primesc o ofertă separată. Condițiile exacte le confirmă echipa la evaluare.

Apăsați „Cere o evaluare gratuită” pe acea pagină sau scrieți-ne direct, cu adresa site-ului, vechiul furnizor și ce trebuie mutat: Servicii profesionale la cerere: administrare, DevOps, migrare, Cum contactați suportul BLACKBOX.

Întrebări frecvente

Importul MySQL se oprește cu eroarea Unknown collation: 'utf8mb4_0900_ai_ci'. Exportul vine din MySQL 8, iar pe serverul nou rulează MariaDB, care nu cunoaște această colaționare. Înlocuiți-o în fișier și importați din nou:

gunzip /root/NUME_BD.sql.gz
sed -i 's/utf8mb4_0900_ai_ci/utf8mb4_unicode_ci/g' /root/NUME_BD.sql
mysql NUME_BD < /root/NUME_BD.sql

Pe serverul nou se deschide doar prima pagină; celelalte dau 404. Regulile din .htaccess nu funcționează cu nginx. Pentru WordPress și majoritatea aplicațiilor PHP, configurația nginx are nevoie de try_files $uri $uri/ /index.php?$args;: vedeți WordPress pe LEMP (nginx, MariaDB, PHP).

Pot păstra adresa IP de la vechiul furnizor? Nu. Serverul BLACKBOX are propria adresă IPv4; de aceea se schimbă înregistrările DNS. Serverele NS ale domeniului nu trebuie schimbate.

Am comandat un plan „VPS hosting” cu panou de control. Se aplică ghidul? Etapele (inventar, TTL, test, comutare) sunt aceleași, dar site-ul se creează prin panoul instalat. Întrebați suportul ce panou are serverul și cum importați site-ul: Planurile „VPS hosting” cu panou de control.