Checklist di migrazione VPS: backup, DNS, TLS e rollback
Una sequenza pratica di migrazione per un'applicazione self-hosted: inventario, backup coerenti, una destinazione testata, scritture controllate, cutover DNS e un percorso di ripristino.
In breve
Una migrazione VPS controllata inventaria servizi e dati, crea un backup coerente, verifica una destinazione ripristinata, testa l'instradamento di hostname e TLS, coordina le scritture finali e DNS, e preserva un rollback consapevole dei dati. Nessuna checklist da sola garantisce zero downtime.
Inventaria l'applicazione prima di spostarla
Elenca i servizi, le versioni, le porte, le attività pianificate, i database, i file caricati e la configurazione necessari per il funzionamento dell'applicazione. Identifica dove avvengono le scritture e da quali servizi esterni dipende. Una directory web copiata non è una migrazione completa quando i dati risiedono altrove.
Registra i nomi DNS correnti, i record IPv4 attivi e IPv6, i metodi di rinnovo dei certificati e un percorso di accesso al ripristino. Conserva i segreti nei tuoi strumenti di deployment privati. Non inserire password, chiavi private o dump di database in una document root pubblica o in una checklist di migrazione condivisa.
Crea un backup coerente e dimostra che si ripristina
Usa il meccanismo di backup supportato dal database anziché copiare file arbitrari mentre le scritture continuano. Per SQLite, l'Online Backup API crea uno snapshot coerente del database. In modalità WAL, il file WAL partecipa allo stato persistente del database, quindi copiare solo il file principale del database può omettere modifiche confermate.
Un backup coerente del database non è automaticamente coerente con caricamenti, code o file archiviati separatamente. Coordina la loro acquisizione con la tua applicazione. Ripristina in una posizione di test separata e verifica record, riferimenti ai file e comportamento dell'applicazione prima di considerare il backup utilizzabile.
Prepara la destinazione prima di modificare DNS
Crea gli utenti, i permessi, le versioni di runtime, i servizi e le directory dell'applicazione previsti sul nuovo server. Ripristina il backup di test nella sua posizione dati di destinazione, fuori dalla document root pubblica dove appropriato. Controlla proprietà e accesso usando l'account di servizio che eseguirà effettivamente l'applicazione.
Preserva i siti non correlati su un server condiviso. Usa una document root, un virtual host e un runtime dedicati, convalida la configurazione del web-server e prepara un rollback che ripristini solo i file e la configurazione di proprietà di questa modifica.
Testa l'hostname e il certificato reali sul nuovo server
Una richiesta del browser a un indirizzo IP nudo non riproduce l'instradamento basato sull'hostname o la validazione del certificato. curl --resolve consente a un test di utilizzare l'hostname previsto e un IP di destinazione scelto mantenendo i normali controlli di hostname e TLS. Controlla anche lo stato HTTP e il contenuto previsto dell'applicazione. L'esempio utilizza valori solo di documentazione; sostituiscili con il tuo dominio e la tua destinazione verificati.
Un certificato valido e un percorso di rete consentito devono già esistere perché quel test abbia successo. Non disabilitare mai la verifica del certificato per dichiarare pronta la migrazione. La validazione ACME basata su DNS può convalidare un dominio senza cambiarne l'indirizzo del web-server; la validazione basata su HTTP ha requisiti di raggiungibilità diversi. Testa il rinnovo separatamente dall'emissione iniziale.
curl --fail-with-body --show-error --resolve example.com:443:203.0.113.10 https://example.com/Scegli un piano di controllo delle scritture e sincronizzazione finale
Pianifica un breve periodo di manutenzione o un altro meccanismo di coerenza appropriato all'applicazione. Ferma o reindirizza i writer che hai identificato, esegui il backup finale coerente del database, sincronizza i file modificabili corrispondenti e verifica il risultato. I worker delle code, i webhook e le attività cron possono scrivere anche quando l'interfaccia pubblica sembra tranquilla.
Usa una prova a vuoto prima di una sincronizzazione di file. Non aggiungere flag di eliminazione né copiare intere directory di sistema come scorciatoia. Mantieni il vecchio servizio ripristinabile finché non hai controllato la nuova applicazione e stabilito quale posizione è autoritativa per le scritture.
Modifica DNS, poi osserva entrambe le famiglie di indirizzi
Aggiorna i record richiesti per il servizio e tieni conto delle cache dei resolver esistenti. Controlla le risposte autoritative e diversi percorsi client normali. Se un record AAAA obsoleto rimane attivo, i client IPv6 possono continuare a raggiungere il vecchio server mentre i client IPv4 raggiungono quello nuovo.
Testa accesso, letture, scritture, caricamenti, attività in background e callback esterni sul nuovo servizio. Evita di eseguire due copie scrivibili indipendenti della stessa applicazione durante la transizione. Mantieni una regola chiara per gestire il traffico che raggiunge ancora la vecchia destinazione.
Rendi il rollback una decisione sui dati oltre che una decisione su DNS
Definisci le condizioni di guasto che attivano un rollback e chi controlla il cutover. Ripristinare solo DNS non è sufficiente dopo che nuove scritture hanno raggiunto la destinazione: devi preservare o riconciliare quei dati prima di tornare a una copia precedente.
Mantieni la sorgente e i backup per un periodo di ripristino appropriato. Rimuovi i vecchi accessi e dismetti le risorse solo dopo aver controllato destinazione, backup, rinnovo e monitoraggio. La conservazione e la cancellazione dovrebbero seguire la politica di servizio effettiva, non un numero fisso generico di ore.