Come migrare un sito o un'app su un nuovo server cloud
Per migrare in sicurezza verso un server cloud, lascia intatta la vecchia macchina finché la nuova non ha servito traffico reale. Questa guida è un piano per un sito, un negozio o un'applicazione: tre checklist (prima, passaggio, rollback), comandi da adattare e limiti onesti sul downtime. Dimensiona prima la destinazione con la guida al dimensionamento dei server cloud e scegli la regione con la guida alle sedi in Europa.
Scegli il metodo di migrazione
Quattro metodi coprono quasi ogni trasloco. Molti progetti ne combinano due.
| Metodo | Ideale per | Rischio principale |
|---|---|---|
| rsync dei file | Siti statici, upload, codice dell'app | I dati cambiano durante la copia, serve una sincronizzazione finale |
| Immagine o ripristino da backup | Stesso sistema e stessa struttura, ripristino testato | Driver e nomi di rete vecchi, più dati da spostare |
| Redeploy dell'app | Container e codice in git | Si dimentica lo stato nascosto sul vecchio disco |
| Replica del database | Database grandi o molto attivi | Impegno di configurazione e limiti di versione |
Parti da un server cloud da EUR 15.00/mese, verificato 2026-10 e prova lì l'intero piano.
Checklist prima della migrazione
- Inventario - elenca servizi, porte, job cron, impostazioni di posta, certificati, regole del firewall e ogni nome che punta al vecchio IP.
- Stato nascosto - cerca i file fuori dalla root web: upload, code, sessioni, licenze, segreti nelle variabili d'ambiente.
- Backup - fai un backup completo del vecchio server e ripristinalo una volta altrove, perché un backup non testato è solo una speranza.
- Accesso - solo chiavi SSH, un firewall e un utente di deploy senza root sul nuovo server.
- Snapshot - crea uno snapshot del nuovo server prima della prima sincronizzazione vera, così un errore costa minuti.
Copia file e dati
Gli esempi usano l'indirizzo di documentazione 203.0.113.10 come nuovo server. Sostituisci nomi e percorsi con i tuoi. I passi 1 e 2 si possono ripetere senza rischi; il passo 5 va eseguito solo quando il vecchio sito è in sola lettura.
# 1. Bulk copy while the old server keeps serving (repeat any time)
rsync -aHAX --numeric-ids --info=progress2 \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
# 2. Database dump and restore (MySQL / MariaDB shown)
mysqldump --single-transaction --routines --triggers appdb \
| gzip | ssh deploy@203.0.113.10 'gunzip | mysql appdb'
# 3. Test the new server under the real hostname, DNS untouched
curl -sS --resolve example.com:443:203.0.113.10 \
https://example.com/ -o /dev/null -w '%{http_code}\n'
# 4. Check the TTL resolvers will honour
dig +noall +answer example.com A
# 5. Final sync after the old site is read-only
rsync -aHAX --numeric-ids --delete \
-e ssh /var/www/ deploy@203.0.113.10:/var/www/
L'opzione --delete rimuove sulla destinazione i file che non esistono più nella sorgente. Usala solo nell'ultima esecuzione e solo se sai quale lato è il principale.
Prova prima con il file hosts
Prima di cambiare il DNS, fai risolvere il sito dal tuo computer verso il nuovo server. Aggiungi una riga al file hosts (/etc/hosts, oppure C:\Windows\System32\drivers\etc\hosts su Windows): 203.0.113.10 example.com www.example.com. L'opzione --resolve di curl (passo 3) fa lo stesso per una singola richiesta. Poi rimuovi la riga, altrimenti per settimane testerai il nuovo server senza accorgertene.
Abbassa il TTL del DNS ed esegui il passaggio
Abbassa il TTL dei record A e AAAA a circa 300 secondi, almeno un intero periodo del vecchio TTL prima del trasloco. Altrimenti i resolver tengono il vecchio indirizzo finché lo consente il vecchio TTL. Alcuni resolver ignorano un TTL breve, quindi aspettati per ore una coda di visitatori sul vecchio IP (una stima, non una misura).
Checklist del passaggio:
- TTL - il valore ridotto è attivo e il vecchio è scaduto.
- Sola lettura - il vecchio sito è in manutenzione o in sola lettura.
- Sincronizzazione finale - ultimo dump del database e passo 5 del codice sopra eseguiti.
- DNS - i record A e AAAA puntano al nuovo IP; quelli della posta restano invariati salvo che si sposti anche la posta.
- Smoke test - login, ordine, upload, e-mail, cron e certificato verificati sul nome pubblico.
- Vecchio server - lascialo acceso, raggiungibile e intatto.
Checklist di rollback
- Soglia - decidi in anticipo cosa conta come fallimento, per esempio pagamenti falliti o un tasso di 5xx, e chi decide.
- DNS indietro - riporta i record sul vecchio IP; con un TTL basso la maggior parte dei visitatori torna in minuti o ore.
- Scritture - riapri il vecchio sito. Se il nuovo ha accettato ordini o upload dopo il passaggio, esportali prima e riproducili sul vecchio.
Cosa richiede davvero lo zero downtime
Lo zero downtime dipende dall'architettura della tua applicazione e non è promesso per nessun progetto. Servono un'app senza stato, un database che replichi o accetti scritture su entrambi i lati, storage condiviso o replicato e un passaggio testato. Un sito classico con un solo database ha di solito una breve finestra in sola lettura di minuti.
Dopo il trasloco
Per almeno una settimana tieni d'occhio log degli errori, disco, memoria, tempi di risposta e consegna della posta. Rialza il TTL del DNS quando tutto è stabile. Dismetti il vecchio server solo dopo un ciclo completo di backup sul nuovo; un backup settimanale è incluso in ogni preset. Prova prima di impegnarti con la checklist del periodo di prova; un breve test può essere possibile scrivendo a sales@dcxv.com, a discrezione di DCXV e senza garanzia.
Configura il server cloud di destinazione oppure chiedi a un ingegnere della migrazione.
