Perché un disco virtuale sparse occupa l’intera dimensione dopo il ripristino di un backup?
Un disco virtuale sparse diventa completamente allocato quando il ripristino scrive le aree riempite di zeri come blocchi reali o ricrea l’immagine usando un formato thick.
Le immagini sparse in formato VHD, VHDX, raw e QCOW2 possono indicare una grande capacità logica consumando spazio solo per le aree allocate. Un backup può preservare perfettamente il contenuto dei file, ma perdere la mappa dei buchi, dei cluster non allocati, dello stato discard o dei metadati del thin provisioning. Il guest ripristinato può avviarsi normalmente anche se il file sull’host occupa ormai l’intera dimensione virtuale. Analizza il formato e l’allocazione prima di compattare o convertire l’unica copia ripristinata.
Confronta la dimensione logica con quella effettivamente allocata
Annota il formato dell’immagine, la dimensione virtuale, la dimensione apparente del file, i blocchi allocati sull’host, il filesystem di destinazione e se l’immagine ripristinata è contrassegnata come sparse o preallocata.
Microsoft spiega che i file sparse restituiscono zeri per le aree non allocate mantenendo una dimensione nominale maggiore; per questo la dimensione virtuale e lo spazio fisico occupato devono essere misurati separatamente.
Usa uno strumento che consideri l’allocazione invece di affidarti solo a un browser di file. Se la dimensione virtuale e quella allocata coincidono, probabilmente il ripristino ha materializzato i buchi o selezionato un formato fisso.
Determina se il backup ha preservato i buchi sparse
Esamina le opzioni del processo di backup relative a copia dei file, copia a blocchi, archiviazione, compressione e file sparse. Verifica se ha memorizzato le estensioni allocate o letto l’intero disco logico come un flusso continuo di byte.
La documentazione di GNU Coreutils indica che gli strumenti di copia devono ricreare i buchi sparse nella destinazione; in caso contrario, lunghe sequenze di zeri possono essere scritte come normali blocchi allocati.
Un ripristino con contenuti validi non dimostra che i metadati di allocazione siano stati preservati. Confronta una piccola immagine di test con buchi noti attraverso lo stesso percorso di backup e ripristino.
Verifica se la conversione dell’immagine ha disabilitato la sparsificazione
Esamina ogni passaggio di conversione tra l’oggetto di backup e l’immagine ripristinata. Annota il formato di input, il formato di output, l’opzione di preallocazione, la soglia sparse e l’eventuale utilizzo del copy offload.
QEMU indica che la conversione con qemu-img può rilevare i settori a zero e sopprimerli, mentre una soglia sparse pari a zero o un percorso di copy offload non supportato può produrre una destinazione completamente allocata.
Non riconvertire mai un’immagine mentre la macchina virtuale è in esecuzione. Lavora su una copia verificata e confronta i contenuti del disco virtuale prima di sostituire l’immagine ripristinata.
Verifica che il filesystem di destinazione supporti i file sparse
Controlla il supporto ai file sparse sul filesystem NAS di destinazione e su ogni volume intermedio di staging. Un ripristino scritto prima su un filesystem incompatibile può perdere i buchi prima di raggiungere l’archiviazione finale.
L’allocazione thin dipende dalle proprietà di provisioning dell’oggetto di archiviazione oltre che dalla sua dimensione logica. Una destinazione può supportare file di grandi dimensioni, ma ripristinare comunque l’immagine come oggetto completamente allocato quando l’applicazione di backup non ricrea i buchi.
Se il filesystem di staging o quello di destinazione non può preservare i buchi, il file potrebbe diventare completamente allocato prima di raggiungere il datastore finale della macchina virtuale. Testa prima il supporto sparse con un’immagine usa e getta.
Distingui il formato thick del ripristino dallo spazio libero del guest
Identifica se il disco ripristinato è raw preallocato, raw sparse, VHD fisso, VHDX dinamico o QCOW2. Lo spazio libero del guest non diventa automaticamente un buco sul lato host.
Red Hat distingue tra dischi virtuali preallocati e sparse: i dischi preallocati riservano immediatamente l’intera dimensione, mentre quelli sparse allocano spazio man mano che vengono scritti i dati.
Se la destinazione del ripristino era intenzionalmente thick, l’allocazione completa è prevista e non indica un danneggiamento. Decidi se il compromesso tra prestazioni e capacità giustifica la riconversione a un formato thin.
Recupera lo spazio riempito di zeri con un metodo offline supportato
Spegni la macchina virtuale, conferma di avere un backup separato e determina se i blocchi eliminati del guest sono stati riempiti di zeri o sottoposti a discard. Lo spazio libero del filesystem guest potrebbe contenere ancora vecchi dati non nulli.
Il flusso di lavoro virt-sparsify di Red Hat converte lo spazio libero riconosciuto in aree sparse sul lato host e avverte di non operare su immagini disco attive.
Esegui la compattazione solo su un’immagine duplicata, verifica in seguito il filesystem guest e conserva l’immagine ripristinata originale finché i test a livello applicativo non sono stati superati.
Controlla il comportamento della preallocazione e della liberazione dei buchi
Verifica se l’applicazione di ripristino ha preallocato la destinazione per motivi di affidabilità o prestazioni e se la destinazione supporta la successiva deallocazione degli intervalli.
L’interfaccia fallocate di Linux distingue l’allocazione di blocchi reali dalla liberazione dei buchi, mostrando perché scrivere zeri e deallocare spazio non sono la stessa operazione.
Non liberare direttamente i buchi in un formato di disco virtuale sconosciuto. Usa l’hypervisor o l’utilità per immagini che ne conosce i metadati e la disposizione dei cluster.
Convalida il disco ripristinato prima di sostituirlo
Avvia la copia compattata in isolamento, controlla filesystem, applicazioni, snapshot e spazio libero del guest, quindi confronta gli hash di file rappresentativi e la struttura dichiarata del disco virtuale.
La checklist di ripristino per home server di ZimaSpace fornisce il requisito complementare di dimostrare il ripristino dell’archiviazione e delle applicazioni prima di rimuovere la copia precedente.
Il problema è risolto quando il disco ripristinato conserva il formato thin previsto, lo spazio allocato sull’host riflette i dati effettivi del guest e la macchina virtuale supera le verifiche di avvio, carico di lavoro, backup e ripristino. Conserva l’immagine completamente allocata se la conversione produce errori o la piattaforma richiede il provisioning thick.
Prodotti consigliati
Supporto e consigli
Altro da leggere
Plex può condividere una GPU con un altro container Docker?
Plex e un altro container possono spesso accedere alla stessa GPU, ma è necessario testare il supporto dei driver, la mappatura dei dispositivi, il...
Come capire se un errore di Plex proviene dal client o dal server
Riproduci lo stesso elemento su un altro client, confronta il percorso della sessione, quindi raccogli le prove dal server solo dopo che l’ambito ti...
Come configurare la cache di Plex e l’archiviazione temporanea per la transcodifica
Proteggi lo stato persistente di Plex collocando i file temporanei di transcodifica su un’unità locale adatta, quindi verifica la pulizia, lo spazio libero e...
