Migra su Hosting Offshore Senza Downtime

Nessuno sposta un sito attivo per divertimento. Succede perché l'host attuale all'improvviso vuole una foto del tuo passaporto, o inoltra un reclamo con una scadenza di ventiquattro ore, o perché il paese in cui si trova il suo datacenter ha smesso di sembrare un posto sensato dove tenere i tuoi dati. Qualunque sia stata la spinta, il trasloco in sé è la parte pericolosa — è l'unico momento in cui il sito può andare offline, e l'unico momento in cui un passo distratto può inchiodare il nuovo server all'identità che stavi cercando di lasciarti alle spalle.

Entrambi i rischi hanno la stessa cura, e non è uno strumento. È l'ordine delle operazioni. Una migrazione condotta nella sequenza giusta non ha alcuna finestra in cui il sito è irraggiungibile, perché entrambi i server sono attivi nello stesso momento e il DNS è l'ultima cosa a spostarsi. Una migrazione condotta nella sequenza sbagliata produce un'interruzione e una traccia insieme. Quello che segue è quella sequenza, scritta per chi si sposta verso un host offshore, no-KYC, piuttosto che per chi passa da un provider mainstream a un altro — la meccanica è la stessa, ma la pulizia successiva no.

Cosa significa davvero «zero downtime»

L'espressione viene usata con leggerezza, ed è proprio quella leggerezza a far male. Servire HTTP da due macchine contemporaneamente è facile. Mantenere lo stato coerente mentre due macchine servono insieme è la parte difficile, ed è l'unica parte che può davvero perdere dati. Quindi, prima di pianificare qualsiasi cosa, stabilisci quale di questi casi stai davvero gestendo, perché la risposta definisce la forma dell'intera nottata.

Nota che solo la prima riga è davvero gratuita. Ovunque altrove, «zero downtime» significa «un freeze delle scritture così breve che nessuno apre un ticket per segnalarlo». Due minuti di sola lettura alle 04:00 sono un errore di arrotondamento; due ore di scritture divise su due database sono un weekend di riconciliazione. Scegli il freeze.

Abbassa il TTL del DNS giorni prima di spostarti

Questo è l'unico passo che richiede tempi di anticipo, ed è per questo che viene per primo ed è quello che tutti saltano. Il tuo TTL — time to live — dice a ogni resolver di internet per quanto tempo può mettere in cache il tuo record prima di richiederlo di nuovo. Se il tuo record A ha un TTL di 86400, un resolver che lo ha interrogato un'ora fa continuerà a distribuire il vecchio IP per altre ventitré ore, indipendentemente da cosa cambi presso il registrar.

Il dettaglio critico è che abbassare il TTL è a sua volta soggetto al vecchio TTL. I resolver vengono a conoscenza del nuovo valore, più basso, solo quando la vecchia copia in cache scade. Quindi porta il TTL a 300 secondi almeno un intero periodo del vecchio TTL prima del cutover — con un TTL di un giorno, questo significa farlo 24-48 ore prima. A quel punto il mondo converge sul tuo nuovo record entro cinque minuti dalla modifica, e il cutover smette di essere un evento carico di suspense.

Riporta il TTL a un valore ragionevole qualche giorno dopo il trasloco. Un TTL di 300 secondi è un ottimo strumento temporaneo e una pessima impostazione permanente: moltiplica il volume delle tue query e rende il tuo provider DNS un single point of failure molto più netto.

Fai l'inventario di ciò che sposti, non di ciò che ricordi

Ogni migrazione fallita ha lo stesso post-mortem: qualcosa che nessuno aveva elencato non è stato copiato. La web root e il database sono le due cose che tutti ricordano; l'elenco qui sotto è tutto il resto, e vale la pena percorrerlo alla lettera piuttosto che a memoria.

• Lavori pianificati. crontab -l per ogni utente, più i timer systemd. Gli hook di rinnovo e i job notturni si nascondono qui.
• Definizioni dei servizi. Unit systemd personalizzate, i vhost del web server, i pool PHP-FPM, qualsiasi configurazione di supervisor.
• Segreti e ambiente. File .env, chiavi API, password del database, salt dell'applicazione — e nota che questi andrebbero ruotati, non semplicemente copiati.
• Materiale TLS. I certificati e, cosa più importante, l'account ACME e la configurazione di rinnovo.
• Identità di posta. Chiavi private DKIM, record SPF e DMARC. Una discrepanza qui non si rompe rumorosamente; manda semplicemente e silenziosamente la tua posta nello spam.
• Media caricati. Spesso fuori dalla web root, spesso la cosa più grande che possiedi.
• Tutto ciò che è esterno e si fida del tuo IP. Allowlist del gateway di pagamento, destinazioni webhook, firewall del database, API di terze parti con restrizioni IP. Questa è la causa numero uno di «il sito funziona ma il checkout è rotto» alle 03:00.
• L'elenco dei pacchetti. dpkg --get-selections o l'equivalente, così la nuova macchina ha le stesse estensioni e librerie invece di averne quasi le stesse.

Scrivi l'elenco prima di iniziare a copiare. L'inventario è anche il tuo piano di test più avanti — ogni riga è qualcosa da verificare sul nuovo server prima che il DNS sappia che esiste.

Costruisci prima il nuovo server, e fai l'hardening prima che contenga qualcosa

Ordina la destinazione con anticipo e lasciala in esecuzione vuota per un giorno o due. Non c'è alcun costo nella sovrapposizione — un piccolo VPS offshore costa pochi dollari al mese — e c'è moltissimo valore nel non fare la build sotto pressione di tempo con un database congelato in attesa.

Fai corrispondere il vecchio ambiente con attenzione: la stessa distribuzione e versione principale, la stessa versione principale di PHP, Node o Python, la stessa versione principale del database. La tentazione di modernizzare mentre sei lì dentro è enorme e va resistita completamente. Se il sito si rompe dopo il cutover, vuoi che sia cambiata esattamente una variabile. Aggiorna lo stack due settimane dopo, in un noioso pomeriggio, con la possibilità di tornare indietro.

Fai l'hardening mentre è ancora vuoto. SSH solo a chiavi, un firewall default-deny, aggiornamenti di sicurezza automatici — la checklist di hardening della prima ora è esattamente questo elenco, ed è molto più facile applicarla a una macchina che non contiene ancora nulla. Se i dati sono abbastanza sensibili da giustificare un cambio di giurisdizione, questo è anche il momento giusto per decidere sulla crittografia dei dati a riposo, perché aggiungerla in un secondo momento significa un'altra migrazione.

Copia i dati due volte: un passaggio lento, poi uno veloce

L'istinto è copiare tutto durante la finestra di manutenzione. Fai il contrario. Esegui una copia completa giorni prima, mentre il vecchio sito serve felicemente il traffico, poi esegui un secondo passaggio al cutover che sposta solo ciò che è cambiato. Il primo passaggio può richiedere sei ore e nessuno se ne accorge. Il secondo richiede novanta secondi, ed è quello il tuo intero budget di downtime.

Per i file, rsync -aHAX --numeric-ids preserva permessi, proprietà, hard link e attributi estesi; il flag --numeric-ids conta perché gli UID raramente coincidono tra due macchine appena costruite. Eseguilo una volta in anticipo, poi di nuovo immediatamente prima del cutover con gli stessi argomenti — la seconda esecuzione trasferisce solo il delta.

I database richiedono lo stesso trattamento in due fasi ma strumenti diversi. Un mysqldump --single-transaction o pg_dump ti dà uno snapshot coerente in anticipo su cui costruire e testare. Al cutover, o esegui un secondo dump durante il tuo breve freeze delle scritture, oppure — per un database grande dove anche un freeze breve fa male — imposta il nuovo server come replica del vecchio con giorni di anticipo, lascia che si allinei, e poi promuovilo. La replica riduce il freeze a secondi. Trasforma anche una migrazione di due ore in un progetto di due giorni, quindi usala solo quando la dimensione lo richiede davvero.

Testa il nuovo server prima che il DNS sappia che esiste

Puoi servire il vero hostname dal nuovo IP senza cambiare un solo record pubblico, e dovresti farlo — è questo che rende il cutover privo di sorprese. Aggiungi una riga al tuo /etc/hosts locale che punta il dominio verso il nuovo IP, oppure salta questo passaggio e lascia che sia curl a farlo per una singola richiesta:

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

Ora percorri l'inventario. Apri la home page e tre pagine interne. Accedi. Invia un modulo. Carica un file. Controlla che la connessione al database sia quella nuova, locale, e non stia ancora puntando al vecchio host attraverso internet — un errore che funziona perfettamente fino al momento in cui cancelli il vecchio server. Esegui i cron job a mano e leggi il loro output. Verifica i redirect e che un URL mancante restituisca ancora 404 invece di 200.

Emetti il certificato TLS ora, prima del cutover, non dopo. Usa una DNS-01 challenge, che dimostra il controllo del dominio tramite un record TXT e quindi funziona anche mentre il record A punta ancora al vecchio server. Se aspetti la validazione HTTP-01 dopo la modifica del DNS, ogni visitatore che arriva presto riceve un avviso di certificato durante l'intervallo — un'interruzione autoinflitta esattamente nella finestra che stavi cercando di proteggere.

Il cutover, in ordine

A questo punto il nuovo server è costruito, ha ricevuto l'hardening, è popolato, testato sotto il vero hostname e detiene un certificato valido. Il cutover in sé è ormai un elenco breve e noioso, che è esattamente l'obiettivo.

1. Annuncia la finestra se qualcun altro dipende dal sito, poi metti il vecchio sito in modalità di sola lettura o manutenzione.
2. Disattiva cron e i worker in background sul vecchio host. Fallo prima di avviarli sul nuovo, mai dopo.
3. Esegui il passaggio finale del delta con rsync e il dump finale del database, e importalo.
4. Avvia l'applicazione sul nuovo server e riesegui i tuoi smoke test tramite --resolve, contro i dati finali.
5. Cambia i record A e AAAA verso il nuovo IP. Con un TTL di 300 secondi, il mondo segue entro cinque minuti.
6. Attiva cron e i worker sul nuovo host.
7. Osserva entrambi i log di accesso fianco a fianco. Il traffico defluisce dal vecchio server e appare su quello nuovo; quando il vecchio tace, il cutover è completo.
8. Lascia il vecchio server acceso, in funzione e intoccato per una settimana. È il tuo rollback.

Il passo otto è quello che la gente salta, ed è l'assicurazione più economica dell'elenco. Per il prezzo di pochi dollari mantieni la possibilità di far tornare il DNS indietro — un recupero di cinque minuti — per tutto il tempo necessario a esserne sicuro.

Cosa lascia dietro di sé la migrazione

Ecco la parte che le guide generiche alla migrazione omettono, e la parte che conta di più se ti sei spostato per privacy piuttosto che per prezzo. Spostare un sito non ne cancella la storia. Diversi registri pubblici e semi-pubblici del vecchio assetto sopravvivono permanentemente al trasloco, e sapere quali sono fa la differenza tra una rottura pulita e la falsa sensazione di averne fatta una.

Il riassunto onesto è che una migrazione non può riscrivere il passato — può solo smettere di aggiungerci altro. Questo vale comunque moltissimo, ma cambia la decisione: se il tuo modello di minaccia richiede che nessun osservatore possa collegare il nuovo sito al vecchio, spostare lo stesso dominio su un nuovo host non lo ottiene, e nessuna quantità di cura durante il cutover lo otterrà. Quel caso richiede un nome nuovo e un inizio pulito, di cui parliamo tra poco. Se il tuo obiettivo è invece smettere di generare registri identificativi da oggi in avanti, e spostare il baricentro legale verso una giurisdizione che hai scelto tu, il trasloco fa esattamente questo. La nostra guida all'OpSec del server copre le abitudini che lo mantengono pulito in seguito.

La questione del dominio: portarlo con te, o ripartire da zero?

Il sito e il dominio sono decisioni indipendenti, ed è comune confonderle. Puoi spostare l'hosting oggi e lasciare il registrar in pace per sempre; nulla nel cambio di server richiede di toccare il dominio. Se tu debba farlo dipende interamente da cosa il dominio già sa di te.

• Tieni il dominio, cambia il registrar. Sensato quando il dominio ha valore — link, posizionamento, un nome che le persone digitano. Sistema il futuro del record WHOIS, non la sua storia, e mantiene intatto ogni segnale di ranking. È la risposta giusta per la maggior parte dei siti commerciali.
• Tieni il dominio, non cambiare nulla se non l'host. Perfettamente ragionevole quando ti sei spostato per giurisdizione, uptime o posizione rispetto al DMCA piuttosto che per l'anonimato. La mossa più semplice possibile, zero rischio SEO.
• Nuovo dominio, redirect del vecchio. Preserva il posizionamento, e collega pubblicamente e permanentemente i due nomi. Scegli questa opzione per la continuità, mai per la privacy — il redirect è il collegamento.
• Nuovo dominio, rottura pulita. L'unica opzione che recide davvero il legame, e ti costa ogni posizionamento e ogni link in entrata che avevi. Registralo in modo privato fin dall'inizio, perché un dominio è anonimo solo quanto lo è stata la sua prima registrazione. La nostra guida alla registrazione anonima di domini con crypto spiega come farlo correttamente.

Scegli con consapevolezza, e scegli prima del cutover piuttosto che durante. Cambiare idea sul dominio dopo che il DNS si è già spostato significa fare la parte delicata due volte.

Dismetti il vecchio host in modo corretto

Una settimana o due dopo il cutover, quando i log del nuovo server sono noiosi e quelli del vecchio sono vuoti, è il momento di chiudere il vecchio account. Fallo in questo ordine, perché la scorciatoia allettante — premere annulla — è quella che lascia i tuoi dati sul disco di qualcun altro.

1. Conferma che nulla punti ancora al vecchio IP: controlla eventuali indirizzi hardcoded in webhook di terze parti, allowlist, monitoraggio, e qualsiasi record DNS che hai dimenticato, come un sottodominio vagante tipo mail o cpanel.
2. Ruota ogni segreto che sia mai vissuto su quella macchina — password del database, chiavi API, salt dell'applicazione, chiavi DKIM, chiavi SSH. Non portarle avanti con una copia.
3. Rimuovi le tue chiavi pubbliche SSH e qualsiasi accesso di supporto dal vecchio server.
4. Elimina l'applicazione, i dump e i backup, poi sovrascrivi lo spazio libero così che una lettura casuale del volume riciclato non restituisca nulla.
5. Solo a questo punto termina il servizio, e rimuovi qualsiasi metodo di pagamento memorizzato dal vecchio account.

L'intera sequenza in una pagina

Togli il ragionamento e una migrazione di host sono nove passi, di cui solo due hanno urgenza:

1. Due giorni prima: abbassa il TTL del DNS a 300 secondi.
2. Due giorni prima: ordina e fai l'hardening del server di destinazione, facendo corrispondere il vecchio stack versione per versione.
3. Giorni prima: scrivi l'inventario — cron, segreti, TLS, chiavi di posta, media, allowlist IP, pacchetti.
4. Giorni prima: esegui la prima copia completa dei dati, da host a host.
5. Prima della finestra: emetti il certificato tramite DNS-01 e testa tutto tramite --resolve.
6. La finestra (minuti): blocca le scritture, disattiva il vecchio cron, esegui la copia del delta e il dump finale, avvia la nuova app.
7. La finestra (secondi): cambia il record A, poi attiva il cron sul nuovo host.
8. La settimana successiva: tieni in vita il vecchio server come rollback, osserva entrambi i file di log, poi rialza il TTL.
9. In seguito: ruota i segreti, cancella in modo sicuro, disdici — e ricorda cosa il trasloco non ha potuto cancellare.

Niente in questo elenco è difficile. Ogni passo che fa male è un passo fatto fuori ordine — un TTL abbassato la notte stessa, un certificato emesso dopo la modifica del DNS, un cron job lasciato armato su una macchina che non è più autorevole. Fai la sequenza nel modo giusto e la parte interessante di una migrazione diventa scegliere dove mettere il server, non il trasloco in sé. Se non l'hai ancora deciso, la guida alle giurisdizioni è il punto da cui partire.