Per spostare una VM fra due ambienti Proxmox separati si può creare un backup su Proxmox Backup Server e ripristinarlo sull’host di destinazione. Il trasferimento del disco è solo una parte della migrazione: rete, dipendenze e dati modificati dopo il backup decidono se il servizio può davvero entrare in produzione.
Nel lavoro sulle infrastrutture Romiltec, il passaggio dal laboratorio a un ambiente operativo richiede soprattutto una procedura ripetibile. Questa guida descrive il metodo di backup e restore; non è una live migration e non promette assenza di interruzioni.
Cosa deve essere pronto prima del backup
Annota versione di Proxmox VE, tipo di macchina virtuale, BIOS o UEFI, storage, dimensione dei dischi, bridge e modello di CPU. Un disco ripristinato non porta con sé la GPU passata in passthrough né rende disponibile sul nuovo host un bridge che esisteva solo a casa.
Controlla anche i dati esterni alla VM: volumi remoti, mount di rete, database separati e servizi di autenticazione. Il backup della VM non li include automaticamente. Le chiavi necessarie a decifrare un backup devono essere recuperabili anche se il sistema originale non è più disponibile.
Per applicazioni che scrivono su database, scegli una strategia di consistenza. Il guest agent può contribuire al congelamento del filesystem, ma questo non sostituisce in ogni caso una procedura applicativa o un dump coerente. La documentazione di Proxmox VE sui backup distingue modalità e vincoli da valutare sul proprio carico.
PBS collega i backup, non il quorum dei cluster
Gli host sorgente e destinazione possono accedere allo stesso PBS senza appartenere allo stesso cluster Proxmox VE. È una distinzione utile quando il laboratorio usa una connessione domestica e la destinazione ha requisiti operativi diversi.
Prevedi credenziali con permessi adeguati, connessione protetta e verifica del certificato. Se usi namespace separati, controlla che l’account della destinazione possa leggere proprio il backup da migrare. Raggiungere la porta del servizio non dimostra che il restore sia autorizzato.
Seleziona e proteggi il punto di ripristino
Il backup candidato va identificato per VM e timestamp. Esegui la verifica prevista da PBS e, prima della migrazione, una prova di ripristino. La verifica del datastore e l’avvio dell’applicazione controllano aspetti diversi: entrambi servono.
PBS consente di proteggere uno snapshot dalla rimozione finché non si toglie la protezione. Per un punto di ripristino che deve accompagnare un rilascio è più esplicito che sperare che la retention lo conservi abbastanza a lungo.
Un chiarimento rispetto alla versione precedente di questo articolo: prune e garbage collection sono operazioni distinte. Il prune rimuove i metadati degli snapshot selezionati; la GC recupera i chunk non più referenziati secondo le proprie regole. Non è corretto attribuire al solo prune la cancellazione immediata dei chunk durante un restore.
Ripristina prima su una rete isolata
- Registra PBS come storage sul nodo di destinazione e seleziona lo snapshot verificato.
- Scegli VM ID e storage di destinazione, controllando spazio disponibile e compatibilità della configurazione.
- Prima di avviare, collega la VM a un bridge isolato o lascia la scheda scollegata.
- Avvia dalla console e adatta indirizzo, gateway, DNS e configurazione applicativa.
- Verifica il servizio prima di permettergli di raggiungere utenti e sistemi esterni.
Il comando qm guest exec richiede una VM avviata con guest agent funzionante. Non è uno strumento per modificare dall’interno una VM spenta. Per intervenire offline serve un metodo di accesso al disco appropriato; per molti casi una prima accensione isolata e la console sono più semplici da controllare.
Blocca anche gli effetti in uscita durante la prova: un cron duplicato può inviare email, un worker può consumare la coda di produzione, un’integrazione può chiamare un sistema cliente. Due copie della stessa VM non devono diventare due esecutori della stessa attività.
Il cutover dipende dai dati scritti dopo il backup
Per un servizio senza stato può bastare distribuire una configurazione aggiornata. Per un’applicazione che riceve scritture devi decidere come trasferire la differenza: finestra di manutenzione con backup finale, replica applicativa o un’altra procedura coerente con il database.
Un esempio: se il backup è delle 02:00 e alle 10:00 sposti il DNS, le scritture di quelle otto ore non compaiono magicamente sulla nuova VM. La procedura deve dire quando si fermano le scritture, quando si copia l’ultimo stato e come si verifica che il nuovo sistema lo contenga.
| Controllo | Esito da verificare |
|---|---|
| Applicazione | Login, lettura e scrittura su un caso concordato |
| Dati | Presenza degli ultimi record attesi e degli allegati |
| Rete | DNS, certificato e percorso reale degli utenti |
| Attività periodiche | Una sola istanza attiva di scheduler e worker previsti |
| Operatività | Monitoraggio e nuovo backup sulla destinazione |
Il rollback va progettato prima delle nuove scritture
Conservare la vecchia VM spenta aiuta, ma riaccenderla dopo che la nuova ha ricevuto dati può creare una seconda divergenza. Scrivi prima quali errori fanno scattare il ritorno e come vengono recuperate le scritture ricevute nel frattempo.
Per stimare i tempi misura separatamente backup, trasferimento, restore e controlli applicativi. La deduplicazione di PBS può ridurre il traffico, ma non rende uguali una prima copia e i backup successivi. Dimensione virtuale del disco, dati effettivi e banda disponibile non sono la stessa misura.
Il laboratorio diventa utile quando questo passaggio è ripetibile. Per il disegno della sorgente puoi partire dalla guida a Proxmox in un homelab; per il risultato operativo, considera conclusa la migrazione soltanto dopo una verifica del servizio e del suo nuovo backup.