Migrare in sicurezza i dati di un VPS con rsync

Censire prima di copiare

Elenca file applicativi, proprietà, ACL, attributi estesi, database, segreti, attività pianificate, servizi, regole firewall, DNS, certificati e storage esterno. Conferma capacità sufficiente sulla destinazione e compatibilità di utenti, filesystem, pacchetti del sistema operativo e versioni applicative. Riduci il TTL DNS prima del passaggio solo se coerente con il piano DNS; i record in cache possono comunque durare più del previsto.

Crea e verifica un backup indipendente della sorgente. Mantienila invariata e disponibile durante il trasferimento iniziale. Definisci i controlli di successo e la decisione di rollback prima di annunciare la finestra di manutenzione.

• Non copiare come dati ordinari filesystem virtuali quali /proc, /sys, /dev o /run.
• Quando opportuno usa strumenti nativi di backup, replica o dump del database.
• Non inserire mai chiavi private nella cronologia dei comandi o in note condivise.

Predisporre i dati applicativi con una simulazione

Per una directory come /srv/app/, prova dalla sorgente con sudo rsync -aHAX --numeric-ids --info=progress2 --dry-run -e "ssh -i /root/.ssh/migration_key" /srv/app/ admin@DESTINATION:/srv/app/. Sostituisci utente, percorso della chiave, destinazione e percorsi dei dati. La barra finale indica di copiare il contenuto della directory sorgente, senza creare un ulteriore livello.

Esamina ogni percorso ed errore. Verifica che l’account remoto possa scrivere in sicurezza sulla destinazione; l’accesso root non è necessario ed è spesso disabilitato. Quando la simulazione è corretta, ripeti senza --dry-run. Non aggiungere --delete solo per rendere identiche le directory: un errore nei percorsi potrebbe cancellare dati preziosi.

• Per grandi trasferimenti esegui il comando in una sessione terminale persistente.
• Limita la banda se la copia può influire sul traffico di produzione.
• Registra opzioni del comando e versioni degli strumenti.

Sospendere le scritture ed eseguire il passaggio finale

Porta l’applicazione in uno stato di manutenzione o sola lettura documentato. Ferma gli esatti servizi di scrittura con la procedura supportata, quindi esegui il backup finale del database o completa la replica. Ripeti lo stesso comando rsync, trasferendo soltanto i file cambiati. Mantieni la manutenzione fino al completamento della convalida.

Avvia i servizi sulla destinazione con la configurazione prevista, limitando inizialmente l’accesso pubblico se possibile. Controlla stato, accesso, scrittura, code, certificati, log e dipendenze. Aggiorna DNS o routing soltanto dopo il superamento delle prove. Non cambiare nella stessa finestra versione dell’applicazione e località di hosting, salvo accettare espressamente il rischio combinato.

• Registra l’ora di arresto delle scritture e il risultato finale.
• Convalida proprietà dei file e controlli di accesso obbligatori.
• Sorveglia endpoint vecchio e nuovo durante la transizione DNS.

Verificare, osservare e conservare il rollback

Per un confronto più approfondito, esegui il comando rsync originale con --checksum --dry-run in una finestra adatta; il calcolo legge entrambi gli insiemi e può essere oneroso. Per database e object storage preferisci controlli di integrità applicativi. Dopo il passaggio monitora errori, latenza, risorse, attività in background e callback esterni.

Mantieni intatta la sorgente ma impedisci scritture concorrenti finché termina la finestra di rollback. Segui poi il piano di conservazione e cancellazione sicura. La migrazione è completa solo quando backup, monitoraggio, documentazione e recupero fanno riferimento alla destinazione.