Varför ser deduplicerade säkerhetskopior mindre ut än det utrymme som krävs för återställning?

Eva Wong är Teknisk skribent och den boende fixaren på ZimaSpace. En livslång nörd med en passion för hemma-labb och öppen källkod, hon specialiserar sig på att översätta komplexa tekniska koncept till tillgängliga, praktiska guider. Eva tror att självhosting ska vara roligt, inte skrämmande. Genom sina handledningar ger hon gemenskapen verktyg att avmystifiera hårdvaruinstallationer, från att bygga sin första NAS till att bemästra Docker-containrar.

Deduplicerade säkerhetskopior ser mindre ut eftersom upprepade delar lagras en gång, medan en återställning återskapar varje logisk fil och oberoende kopia.

Tio avbildningar av virtuella maskiner kan dela gigabyte med identiska block från operativsystemet i ett säkerhetskopieringsarkiv. När de återställs till ett vanligt filsystem återskapas tio adressutrymmen, såvida målet inte också stöder kompatibel delning, gles lagring eller komprimering. Arkivets storlek och återställningskapacitet beskriver därför olika representationer med olika regler för allokering och olika omkostnader på det valda målfilsystemet.

Deduplicering lagrar identiteten en gång och refererar till den många gånger

Säkerhetskopieringsprogram delar upp data i delar, skapar fingeravtryck av dem och lagrar endast delar som inte redan finns. Manifest bevarar vilka delar som hör till varje fil och återställningspunkt. Arkivet kan representera många logiska kopior med en fysisk nyttolast plus referenser.

En översikt över deduplicering av säkerhetskopior förklarar hur redundanta kopior tas bort från säkerhetskopieringslagring. Besparingen beror på upprepat innehåll, inte bara på antalet filer.

Återställning vänder på den mappningen. Varje fil får sina ordnade byte på den begärda destinationen. Om målet saknar blockdelning förbrukar upprepade delar separata extentar igen. Datareduktion var en egenskap hos arkivet, inte ett löfte om att varje återställningsmål förblir lika kompakt.

Komprimering, gles lagring och metadata ökar skillnaden

Komprimering minskar antalet lagrade byte utifrån innehållets entropi. Glesa filer utelämnar långa nollområden, men ett återställningsalternativ kan materialisera dessa luckor. Allokeringsenheter, kontrollsummor, utökade attribut och filsystemmetadata skapar extra omkostnader på destinationen som arkivets sammanfattningar kanske inte räknar med.

En lagringsförklaring skiljer glesa filer från allokerad storlek: en fil kan rapportera en stor logisk längd samtidigt som den förbrukar färre fysiska block. Återställningsverktyg måste bevara luckorna uttryckligen för att behålla den besparingen.

Det motsatta kan också inträffa. En komprimerad destination eller en klon med copy-on-write kan hålla återställda data mindre än den logiska storleken. Det finns ingen universell omräkningsfaktor från arkivbyte till återställda byte, eftersom representation, lagringsuppsättning och målfilsystem alla spelar roll.

När deduplicering inte är huvudorsaken

Förklaringen håller inte när en enda icke-duplicerad fil oväntat blir större. Kryptering, förkomprimerade medier, format för databasexport eller en ändring av tunn provisionering kan i stället vara avgörande. En säkerhetskopieringskatalog kan också visa endast unika data för ett visst omfång, medan återställningen omfattar flera valda ögonblicksbilder.

En teknisk diskussion om dedupliceringsgrad betonar att logiska och fysiska storlekar måste skiljas åt när dedupliceringsgrader rapporteras. Kvoter utan angivet omfång kan leda kapacitetsplaneringen fel.

Mekanismen gäller inte heller om de återställda filernas hashvärden eller antal skiljer sig från den valda säkerhetskopian. Då handlar problemet om urval eller integritet, inte om förväntad expansion. Mindre säkerhetskopieringsmängd motiverar inte att man underdimensionerar det tillfälliga utrymmet före verifiering.

Mät en återställning i stället för att lita på kvoten

Välj en representativ återställningsuppsättning och registrera logiska källbyte, unika arkivbyte, komprimerade byte, glesa extentar, filantal och målets allokeringsenhet. Återställ till en isolerad destination med både alternativ som bevarar gles lagring och standardalternativ, och verifiera sedan hashvärden och allokerat utrymme.

Använd en lagringsplan med delad modellagring så att testdestinationen inte tränger undan aktiva tjänster. Håll arkivets lagringsregler och målets komprimeringsinställningar oförändrade när körningarna jämförs.

Dimensionera återställningen utifrån det större av det uppmätta allokerade resultatet och den logiska datamängdens storlek plus arbetsmarginal, inte utifrån den deduplicerade arkivmängden. Om bevarande av gles lagring ändrar resultatet ska detta beroende dokumenteras. Om filidentiteten eller antalet filer ändras ska du avbryta och lösa återställningens korrekthet innan kapaciteten finjusteras.

Teknik- och AI-hubb

Mer att läsa

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.