Varför förbrukar en gles virtuell disk hela sin storlek efter en återställning från säkerhetskopia?
En tunn virtuell disk blir fullt allokerad när återställningen skriver nollfyllda områden som riktiga block eller återskapar avbildningen i ett tjockt format.
Tunna VHD-, VHDX-, raw- och QCOW2-avbildningar kan rapportera en stor logisk kapacitet samtidigt som de bara använder lagringsutrymme för allokerade områden. En säkerhetskopia kan bevara filinnehållet perfekt men ändå förlora informationen om hål, oallokerade kluster, discard-status eller metadata för tunn provisionering. Den återställda gästen kan starta normalt även om värdfilen nu upptar hela sin virtuella storlek. Diagnostisera format och allokering innan du komprimerar eller konverterar den enda återställda kopian.
Jämför logisk storlek med faktisk allokerad storlek
Notera avbildningens format, virtuella storlek, filens skenbara storlek, allokerade block på värden, destinationsfilsystem samt om den återställda avbildningen är markerad som tunn eller förallokerad.
Microsoft förklarar att tunna filer returnerar nollor för oallokerade områden samtidigt som de behåller en större nominell filstorlek, så virtuell storlek och fysisk förbrukning måste mätas separat.
Använd ett verktyg som tar hänsyn till allokering i stället för att enbart förlita dig på en filhanterare. Om virtuell och allokerad storlek nu är lika stora har återställningen sannolikt materialiserat hål eller valt ett fast format.
Avgör om säkerhetskopian bevarade tunna hål
Granska säkerhetskopieringsjobbets alternativ för filkopiering, blockkopiering, arkivering, komprimering och tunna filer. Ta reda på om det lagrade allokerade extent eller läste hela den logiska disken som en sammanhängande byteström.
GNU Coreutils dokumenterar att kopieringsverktyg måste återskapa tunna hål på destinationen; annars kan långa sekvenser av nollor skrivas som vanliga allokerade block.
En innehållsmässigt giltig återställning bevisar inte att allokeringsmetadata bevarades. Jämför en liten testavbildning med kända hål genom samma säkerhetskopierings- och återställningsväg.
Kontrollera om konverteringen av avbildningen inaktiverade tunn allokering
Granska varje konverteringssteg mellan säkerhetskopieobjektet och den återställda avbildningen. Notera indataformat, utdataformat, alternativ för förallokering, tröskelvärde för tunna områden samt om kopieringsavlastning användes.
QEMU anger att qemu-img-konvertering kan identifiera nollsektorer och utelämna dem, medan ett nollställt tröskelvärde för tunna områden eller en sökväg utan stöd för kopieringsavlastning kan skapa en helt allokerad destination.
Konvertera aldrig en avbildning medan den virtuella maskinen körs. Arbeta med en verifierad kopia och jämför innehållet på de virtuella diskarna innan du ersätter den återställda avbildningen.
Verifiera att destinationsfilsystemet stöder tunna filer
Kontrollera stöd för tunna filer på destinations-NAS:ens filsystem och på varje mellanliggande volym för mellanlagring. En återställning som först skrivs till ett inkompatibelt filsystem kan förlora hålen innan den når den slutliga lagringen.
Tunn allokering beror både på lagringsobjektets egenskaper för provisionering och på dess logiska storlek. En destination kan stödja stora filer men ändå återställa avbildningen som ett fullt allokerat objekt när säkerhetskopieringsprogrammet inte återskapar hålen.
Om mellanlagrings- eller destinationsfilsystemet inte kan bevara hål kan filen bli fullt allokerad innan den når det slutliga datalagret för virtuella maskiner. Testa stöd för tunna filer med en avbildning som kan tas bort först.
Skilj mellan tjockt återställningsformat och ledigt utrymme i gästen
Identifiera om den återställda disken är raw förallokerad, raw tunn, fast VHD, dynamisk VHDX eller QCOW2. Ledigt utrymme i gästen blir inte automatiskt ett hål på värden.
Red Hat skiljer mellan förallokerade och tunna virtuella diskar: förallokerade diskar reserverar hela storleken direkt, medan tunna diskar allokerar lagringsutrymme när data skrivs.
Om återställningsmålet avsiktligt var tjockt är full allokering förväntad och inte ett tecken på skada. Avgör om avvägningen mellan prestanda och kapacitet motiverar att konvertera tillbaka till ett tunt format.
Återvinn nollställt utrymme med en stödd offline-metod
Stäng av den virtuella maskinen, bekräfta att det finns en separat säkerhetskopia och avgör om borttagna block i gästen har nollställts eller kasserats. Ledigt utrymme i gästens filsystem kan fortfarande innehålla gamla data som inte består av nollor.
Reds arbetsflöde för virt-sparsify omvandlar identifierat ledigt utrymme till tunna områden på värden och varnar för att använda verktyget på aktiva diskavbildningar.
Kör komprimering endast på en duplicerad avbildning, verifiera gästens filsystem efteråt och behåll den ursprungliga återställda avbildningen tills tester på programnivå har godkänts.
Kontrollera beteendet för förallokering och hålskapande
Kontrollera om återställningsprogrammet förallokerade destinationen för tillförlitlighet eller prestanda och om destinationen därefter stöder frigöring av intervall.
Linux-gränssnittet fallocate skiljer mellan att allokera riktiga block och att skapa hål, vilket visar varför det inte är samma sak att skriva nollor som att frigöra utrymme.
Skapa inte hål direkt i ett okänt virtuellt diskformat. Använd hypervisorn eller avbildningsverktyget som förstår dess metadata och klusterlayout.
Validera den återställda disken innan du ersätter den
Starta den komprimerade kopian isolerat, kontrollera filsystem, program, ögonblicksbilder och ledigt utrymme i gästen, och jämför sedan representativa filhashar samt den virtuella diskens rapporterade struktur.
ZimaSpaces checklista för återställning av hemservrar innehåller det närliggande kravet att bevisa återställning av lagring och program innan den tidigare kopian tas bort.
Problemet är löst när den återställda disken behåller sitt avsedda tunna format, allokerat utrymme på värden motsvarar faktiska data i gästen och den virtuella maskinen klarar verifiering av start, arbetsbelastning, säkerhetskopiering och återställning. Behåll den fullt allokerade avbildningen om konverteringen ger fel eller om plattformen kräver tjock provisionering.
Rekommenderade produkter
Support och tips
Mer att läsa
Kan Plex dela ett GPU-kort med en annan Docker-container?
Plex och en annan container kan ofta använda samma GPU, men du måste testa drivrutinsstöd, enhetsmappning, belastningen på videoenheten, minne och återställningsbeteende.
Så avgör du om ett Plex-fel kommer från klienten eller servern
Återskapa samma objekt på en annan klient, jämför sessionsvägen och samla sedan in serverbevis först efter att scope har visat var felet faktiskt finns.
Så konfigurerar du Plex-cache och tillfällig lagring för omkodning
Skydda beständigt Plex-tillstånd genom att placera temporära transkodningsfiler på lämplig lokal lagring och verifiera rensning, ledigt utrymme samt omstartsfunktionssätt.
