# Un runbook di migrazione su server dedicato che protegge i dati | SwissOctet Insights https://swissoctet.com/it/insights/dedicated-server-migration-runbook/ SwissOctet / Approfondimenti / Dedicati e GPU Dedicati e GPU Applicato · 6 min di lettura Un runbook di migrazione su server dedicato che protegge i dati Prova lo spostamento, stabilisci un confine dati coerente e definisci cosa significa rollback dopo che il nuovo sistema accetta scritture. Di SwissOctet Editorial Salva guida Copia link IN QUESTA PAGINA 01 Inventaria il servizio prima di spostare la macchina 02 Costruisci la destinazione come ambiente separato 03 Scegli un confine dati coerente 04 Prepara il routing del traffico senza promettere cambiamenti istantanei 05 Definisci il rollback dopo l'inizio delle scritture 06 Chiudi la migrazione con controlli operativi La tua checklist pratica Fonti e approfondimenti Torna alla libreria LA RISPOSTA DIRETTA 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. 01 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. 02 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. 03 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 04 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. 05 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. 06 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. TRASFORMALO IN AZIONE 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. Scarica la checklist DOMANDE COMUNI 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. RIFERIMENTI PRIMARI 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. COLLEGA LE CONOSCENZE Infrastruttura correlata. Metal Atlas Svizzera Metal Zenith Svizzera Metal EPYC Svizzera MANTIENI IL FILO Le tue prossime note sul campo. Esplora tutte le guide NOTA SUL CAMPO / 01 + Dedicati e GPU Fondamenta VPS o dedicato: scegli il confine che fa per te Comprendi cosa cambia una macchina fisica, cosa non cambia e quando diventa un passo utile per il tuo carico di lavoro. 4 min di lettura Leggi la guida NOTA SUL CAMPO / 02 + Operazioni del day-two Applicato Costruisci un backup che puoi davvero ripristinare Scegli un obiettivo di ripristino, proteggi una copia indipendente e prova il ripristino prima che un incidente ti costringa a farlo. 4 min di lettura Leggi la guida NOTA SUL CAMPO / 03 + Dedicati e GPU Avanzato Definisci un budget di VRAM per GPU prima di scegliere l'hardware Tieni conto di pesi, attivazioni, cache e buffer temporanei, poi testa il carico di picco invece del solo file del modello. 6 min di lettura Leggi la guida