Prepara e testa prima il nuovo server, copia i dati con un metodo di coerenza supportato dall'applicazione, definisci una finestra di cutover e preserva il vecchio ambiente. Il rollback deve tenere conto delle scritture accettate sul nuovo server, non solo di una modifica a DNS.
Inventaria il servizio prima di spostare la macchina
Una migrazione include più dei file dell'applicazione. Elenca database, upload, job pianificati, worker di coda, certificati, domini, segreti e integrazioni in uscita. Registra le versioni software e i presupposti operativi che contano, come i permessi dei file e i percorsi di archiviazione. Un nuovo server dedicato può rivelare una dipendenza dimenticata che era stata installata silenziosamente anni prima sul vecchio ambiente.
Assegna un responsabile per la decisione di cutover e definisci come si presenta il successo. Includi controlli visibili all'utente, coerenza dei dati e capacità di recuperare l'accesso. Conferma che la nuova configurazione sia consegnata e utilizzabile prima di annunciare una data di migrazione. Una conferma d'ordine o una specifica hardware elencata non equivalgono a una destinazione funzionante pronta a ricevere dati di produzione.
Costruisci la destinazione come ambiente separato
Installa lo stack richiesto, stabilisci l'amministrazione e configura il firewall previsto. Mantieni privati i segreti e imposta deliberatamente i permessi dei servizi. Verifica il comportamento previsto dell'hostname e del certificato dell'applicazione prima che si sposti il traffico pubblico. La documentazione sui virtual host di Apache illustra perché il routing per hostname è una decisione di configurazione separata dall'indirizzo del server. Una pagina predefinita funzionante non prova che sia configurato l'host applicativo corretto.
Usa un dataset ripristinato rappresentativo per la prova, con email in uscita, pagamenti e job pianificati disabilitati o reindirizzati verso sistemi di test sicuri. Questo impedisce all'ambiente di test di agire su utenti reali. Esercita login, upload, lavoro in background e ripristino. Registra la procedura e la sua durata, così la finestra reale si basa su un processo osservato anziché sull'ottimismo.
Scegli un confine dati coerente
Usa un metodo di backup o replica supportato dal database e dall'applicazione. PostgreSQL distingue dump SQL, backup del file system e archiviazione continua, ciascuno con i propri presupposti. Le sue indicazioni sui dump osservano che i dump del database possono essere internamente coerenti mentre i ruoli a livello di cluster e altri dettagli richiedono una gestione separata. Leggi i requisiti per il sistema esatto che esegui invece di copiare indiscriminatamente file di dati aperti.
Pianifica come il database si relaziona a upload e stato delle code. Se un record punta a un file copiato in un momento diverso, l'applicazione ripristinata può essere incompleta anche quando entrambe le copie sono riuscite individualmente. Decidi se mettere brevemente in pausa le scritture, usare una configurazione di replica testata o eseguire un export specifico dell'applicazione. Mantieni quella decisione di coerenza esplicita nel runbook.
| Fase | Prove richieste | Decisione |
|---|---|---|
| Prova | Applicazione e dati ripristinati superano i controlli | La destinazione può essere considerata per il cutover |
| Sincronizzazione finale | Punto di ripristino coerente definito | Procedi solo con le modifiche residue comprese |
| Cambio del traffico | Routing e comportamento del certificato corretti | Monitora entrambe le destinazioni |
| Rollback | Posizione di tutte le nuove scritture accettate | Riconcilia i dati prima di riportare il traffico |
Prepara il routing del traffico senza promettere cambiamenti istantanei
Il time-to-live di DNS controlla per quanto tempo i record possono essere memorizzati nella cache, come spiegato nella documentazione DNS di Cloudflare. Esamina presto il TTL se DNS fa parte della migrazione e lascia che i record già in cache scadano secondo l'impostazione precedente. Cambiare il valore al momento del cutover non può accorciare retroattivamente ogni risposta in cache. Client diversi possono raggiungere destinazioni diverse durante la transizione.
Mantieni disponibile il vecchio ambiente mentre i cambiamenti di routing si stabilizzano, con una policy deliberata su se possa ancora accettare scritture. Evita di eseguire consumer di coda o job pianificati duplicati, a meno che l'applicazione non sia progettata per farlo. Monitora le richieste su entrambi i lati e conferma da client indipendenti l'hostname previsto, il certificato TLS e la versione dell'applicazione.
Definisci il rollback dopo l'inizio delle scritture
Prima che il nuovo sistema accetti modifiche, riportare il traffico può essere relativamente semplice. Dopo, una semplice inversione di DNS può perdere lavoro o creare due cronologie in conflitto. Definisci come verrebbero preservati o riconciliati i record e gli upload appena creati. Se l'applicazione non può unirli in modo sicuro, un periodo di manutenzione controllato può essere preferibile a un ritorno improvvisato alla vecchia copia.
Stabilisci le condizioni che richiedono di mettere in pausa la migrazione e mantieni raggiungibile il responsabile delle decisioni. Conserva i log e le prove utili secondo le regole di conservazione del progetto. Non eliminare la vecchia macchina o la sua copia di ripristino indipendente solo perché la home page si è caricata una volta. Il periodo di conservazione dovrebbe coprire le esigenze concordate di verifica e rollback.
Chiudi la migrazione con controlli operativi
Dopo il cutover, verifica backup, avvisi, rinnovo dei certificati, lavoro pianificato e recupero dell'accesso. Conferma che l'host monitorato sia la nuova destinazione e che non rimangano integrazioni di test in produzione. Esamina gli errori dell'applicazione e i tempi visibili all'utente con traffico ordinario. Aggiorna l'inventario e il runbook, così il prossimo amministratore non deve dedurre cosa è cambiato.
Le famiglie dedicate di SwissOctet offrono configurazioni fisiche diverse, ma il lavoro di migrazione e l'assistenza gestita devono essere confermati per il servizio scelto. Usa il catalogo per selezionare risorse adeguate, poi costruisci uno spostamento testato intorno ai dati della tua applicazione. Una migrazione è completa quando il servizio e il suo processo di ripristino funzionano sulla destinazione, non semplicemente quando i file sono stati trasferiti.
La tua checklist pratica.
- Inventaria dati, job, segreti e integrazioni.
- Verifica la destinazione consegnata prima di pianificare.
- Prova con integrazioni esterne sicure.
- Definisci la coerenza tra database e upload.
- Pianifica la transizione del routing e la prevenzione dei job duplicati.
- Specifica il rollback per le nuove scritture.
- Verifica backup e monitoraggio dopo il cutover.
I dettagli che contano.
Posso migrare copiando la directory dell'applicazione?+
Solo se questo cattura tutto ciò di cui il servizio ha bisogno e preserva la coerenza. Database, upload, job, segreti e configurazione di solito richiedono attenzione separata.
Abbassare il TTL di DNS rende istantaneo il cutover?+
No. Le risposte già in cache possono rimanere fino alla fine della loro durata precedente e i client possono aggiornarsi in momenti diversi.
Il rollback consiste solo nel puntare DNS al vecchio server?+
Non dopo che il nuovo server accetta scritture. Devi tenere conto di quei record e file prima di riportare il traffico.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- PostgreSQL: Backup e ripristino www.postgresql.org
- PostgreSQL: coerenza e ripristino dei dump SQL www.postgresql.org
- Apache: documentazione sui virtual host httpd.apache.org
- Cloudflare DNS: time to live developers.cloudflare.com
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.