Come proteggere i backup delle macchine virtuali durante la manutenzione dello storage dell’host

Proteggi i backup delle macchine virtuali durante la manutenzione dello storage dell’host interrompendo prima le nuove scritture, verificando i punti di ripristino esistenti e conservando almeno una copia utilizzabile al di fuori dello storage sottoposto a manutenzione.

Su un home server o un piccolo NAS, la manutenzione spesso interessa gli stessi dischi, pool, HBA, enclosure o datastore che contengono anche i backup delle VM. Per questo l’ordine corretto è più importante del nome dello strumento: sospendi l’attività di backup, verifica che i punti di ripristino siano leggibili, rendi la manutenzione reversibile e solo dopo intervieni sul livello di storage dell’host.

Identifica quali backup dipendono dallo storage che intendi modificare

Inizia elencando ogni VM, container, job di backup, repository, posizione degli snapshot e destinazione della replica che legge dallo storage sottoposto a manutenzione o vi scrive. La domanda fondamentale non è dove viene eseguita la VM, ma se la catena di backup o il catalogo di ripristino dipendono dal componente che stai per mettere offline.

Una trappola comune nei laboratorio domestici è conservare i dischi delle VM e il repository di backup in dataset diversi, ma nello stesso pool, enclosure USB, controller o macchina singola. Questo migliora l’organizzazione, ma non protegge il backup se il rischio della manutenzione riguarda l’intero pool, controller o host.

Se un percorso di ripristino dipende dallo stesso storage, contrassegna quel backup come non disponibile durante la finestra di manutenzione. Procedi solo dopo aver ottenuto una seconda copia, una copia remota o un’esportazione verificata che non richieda il dispositivo sottoposto a manutenzione.

Imposta la destinazione di backup in modalità senza nuove scritture

La finestra di manutenzione più sicura inizia impedendo l’avvio di nuove scritture di backup, operazioni di eliminazione, compattazione, replica e raccolta dei dati inutilizzati mentre il livello di storage viene modificato. Un repository inattivo è più facile da gestire rispetto a uno che sta riscrivendo indici o blocchi in background.

Proxmox Backup Server supporta le modalità di manutenzione in sola lettura e offline del datastore; le operazioni in conflitto possono terminare prima che la modalità diventi effettiva. Questa distinzione è importante perché la modalità di sola lettura può consentire ancora i ripristini, mentre la modalità offline blocca sia le letture sia le scritture.

Usa la modalità meno invasiva che protegga l’attività. Per firmware, cablaggio, importazione di pool, sostituzione di dischi o riparazione del filesystem, la modalità offline è generalmente più sicura; per i controlli lato repository che richiedono soltanto di impedire nuove scritture, può bastare la sola lettura. Non affidarti alla memoria: annota la modalità e i job disabilitati.

Verifica i punti di ripristino prima di spostare o riparare lo storage

Un backup che non è stato verificato è soltanto un potenziale punto di ripristino. Prima della manutenzione, esegui la verifica dello strumento oppure effettua almeno un piccolo ripristino isolato dai punti di ripristino più recenti e più vecchi che intendi conservare.

Proxmox Backup Server offre job di verifica programmati, così i dati di backup possono essere controllati periodicamente invece di essere considerati affidabili solo al momento del ripristino. Per la manutenzione, un risultato di verifica recente è più utile di una notifica di backup completato con successo risalente a settimane prima.

Se la verifica non riesce, interrompi il piano di manutenzione e ripara prima il set di backup. Se viene verificato un solo punto di ripristino, conservalo isolato e non eliminare né compattare nulla finché non esiste un secondo percorso di ripristino funzionante.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Conserva una copia di ripristino al di fuori dell’area interessata dalla manutenzione

Prima di modificare dischi, pool, controller, opzioni di montaggio o layout del repository, sposta almeno una copia di ripristino al di fuori dell’area interessata. Può trattarsi di un disco rimovibile, un altro NAS, un Proxmox Backup Server remoto, uno storage di oggetti cloud o un’esportazione temporanea delle VM più importanti.

La documentazione di Veeam sui repository con scalabilità orizzontale considera la manutenzione del repository un’operazione con stato e spiega che un extent può essere impostato in modalità di manutenzione per attività come l’applicazione di patch o l’aggiornamento di un extent. La lezione di fondo vale in generale: la manutenzione deve essere coordinata con lo stato del repository, non eseguita come un intervento cieco sullo storage.

Per un home server, scegli la copia in base alle tue reali esigenze di ripristino. Un’esportazione avviabile può essere migliore per una VM critica, mentre la replica di backup con deduplicazione può essere più adatta a molte VM. La copia è valida solo quando sai dove si trova, come sbloccarla e come ripristinarla senza utilizzare lo storage dell’host sottoposto a manutenzione.

Riattiva i job solo dopo aver verificato il percorso di ripristino

Al termine della manutenzione, non riattivare subito tutti i job programmati. Prima rimonta o importa correttamente lo storage, verifica la proprietà del repository e lo spazio libero, quindi esegui un test di lettura sui backup esistenti prima di consentire nuove scritture.

Le attività di manutenzione dei backup possono richiedere molta I/O; le best practice di Veeam descrivono la manutenzione completa dei file di backup come un processo che genera un nuovo file di backup completo e successivamente elimina quello originale. È proprio il tipo di operazione che dovresti evitare di sovrapporre a riparazioni dello storage o a dischi instabili.

Riattiva i servizi in questo ordine: stato dello storage, accesso in lettura al repository, elenco dei punti di ripristino, piccolo test di ripristino e infine scritture programmate. Se un passaggio è lento, incompleto o incoerente, lascia i job disabilitati e svolgi le verifiche necessarie prima che una nuova catena di backup nasconda il problema.

Domande frequenti

Posso lasciare in esecuzione i backup delle VM mentre sostituisco un disco dell’host?

Solo se il repository di backup e il percorso di ripristino sono chiaramente al di fuori dello storage sottoposto a manutenzione. Se la destinazione di backup condivide il pool, il controller, l’enclosure o una dipendenza dall’host, interrompi prima le nuove scritture.

È sufficiente uno snapshot della VM come protezione prima della manutenzione dello storage?

No. Uno snapshot sullo stesso storage può aiutare per un breve rollback, ma non protegge da guasti del pool, del controller, dell’enclosure o dell’host. Conserva una copia di backup indipendente.

Se la manutenzione riguarda anche la replica ZFS, controlla il comportamento della conservazione e dello spazio libero prima della finestra operativa; un pool di destinazione pieno può trasformare una semplice attività di manutenzione nello stesso tipo di guasto descritto nella guida di ZimaSpace su come impedire che la replica degli snapshot riempia un pool di destinazione.