Hur minskar innehållsdefinierad chunkning duplicerade säkerhetskopieringsdata?
Innehållsdefinierad chunkning förbättrar deduplicering av säkerhetskopior genom att välja chunkgränser utifrån filinnehållet, vilket gör att oförändrade områden kan återanvändas efter infogningar eller borttagningar.
Inkrementella säkerhetskopior innehåller ofta stora filer som till största delen är oförändrade mellan versionerna: virtuella diskavbildningar, e-postarkiv, databaser som kopierats som filer, projektpaket och exporterade mediebibliotek. Om varje chunk börjar vid en fast byteposition kan en liten infogad header nära början förskjuta alla efterföljande gränser, trots att de senare bytena är identiska. Innehållsdefinierad chunkning gör att segmenteringen följer lokala bytemönster i stället för absoluta positioner, så att säkerhetskopian kan synkroniseras med gamla chunkar igen efter det ändrade området.
Fasta chunkgränser kan göra en liten redigering till många nya chunkar
En chunkare med fast storlek delar upp data vid positioner som exempelvis var 1 MiB, oavsett vad bytena innehåller. När byte infogas nära början förskjuts den gamla och den nya dataströmmen i förhållande till varandra. Därför innehåller varje senare fast chunk en annan kombination av byte, även om nästan allt underliggande innehåll är oförändrat.
Innehållsdefinierad chunkning utvecklades för deduplicering eftersom innehållsbaserade brytpunkter kan upptäcka redundans som fasta offsetvärden missar efter lokala redigeringar. Fördelen är inte att CDC förutsäger vilka filer som liknar varandra, utan att den ger dedupliceringen en segmentering som kan överleva förskjutna positioner.
Om en hel fil ersätts med orelaterade byte kan ingen chunkalgoritm skapa duplicerat innehåll. CDC ger störst nytta när versionerna delar stora, oförändrade byteområden, men dessa områden har flyttats i förhållande till filens början.
Ett rullande fingeravtryck söker efter lokala brytpunkter i dataströmmen
CDC flyttar ett fönster över indata och uppdaterar ett fingeravtryck när byte träder in i och lämnar fönstret. En gräns deklareras när fingeravtrycket uppfyller ett konfigurerat villkor, med hänsyn till regler för minsta och största chunkstorlek som förhindrar onaturligt små eller stora chunkar.
Borgs chunkare använder ett rullande innehållsfingeravtryck, så att nästa möjliga gräns kan utvärderas utan att hela fönstret behöver hashberäknas från början. Eftersom fingeravtrycket beror på närliggande byte kan samma lokala sekvens utlösa samma brytpunkt även när dess absoluta offset i filen har ändrats.
Det rullande fingeravtrycket är därför en mekanism för att hitta gränser, inte den slutliga identiteten för lagrade säkerhetskopieringsdata. Om man behandlar dessa två hashvärden som utbytbara blir förklaringen av var dedupliceringen faktiskt avgör återanvändning mindre korrekt.
Minsta, största och genomsnittliga chunkstorlek påverkar också gränssökningen. De styr hur ofta möjliga brytpunkter övervägs och hur mycket metadata arkivet måste hantera.
CDC synkroniseras på nytt efter en redigering i stället för att förbli förskjuten
Efter en infogning eller borttagning ser det rullande fönstret först andra byte och skapar därför andra chunkgränser runt redigeringen. När det helt har flyttats in i ett tillräckligt långt oförändrat område kan det möta samma lokala innehållsmönster och börja skapa brytpunkter på positioner som överensstämmer med den äldre versionen.
Borg påpekar att innehållsdefinierade gränser kan förbli stabila i förhållande till oförändrat innehåll även när byte infogas eller tas bort på andra platser. Det är denna återsynkronisering som begränsar många redigeringar till ett litet antal nya chunkar i stället för att ogiltigförklara resten av filen.
Restic delar på liknande sätt upp filer i blobbar med variabel längd med hjälp av ett glidande fingeravtryck, så att oförändrade blobbar med variabel längd kan refereras igen mellan ögonblicksbilder. Arkivet behöver fortfarande ett index för att känna igen blobbar som redan har lagrats.
Återsynkroniseringsavståndet beror på chunkparametrarna och det ändrade bytemönstret, så CDC lovar inte att exakt en ny chunk skapas för varje redigering. Fördelen är statistisk lokalitet: ändringar löper mindre risk att förskjuta alla senare gränser.
En stark chunkidentifierare avgör återanvändningen efter att gränsen har valts
Att hitta en gräns besvarar bara frågan var en möjlig chunk slutar; arkivet måste fortfarande avgöra om hela chunkinnehållet redan finns. Det andra beslutet använder en starkare innehållsidentifierare eller en autentiserad hash över den färdiga chunken och söker efter den i arkivets index.
Borg skiljer uttryckligen sin gränshash från den kryptografiska chunkidentitet som används som dedupliceringskriterium. Restic refererar på samma sätt till lagrade blobbar med hjälp av en stark innehållshash i stället för att behandla det rullande fingeravtrycket som bevis på att två chunkar är identiska.
Denna tvåstegsdesign förklarar lagringsflödet tydligt: den rullande hashen väljer en möjlig segmentering, innehållshashen identifierar den resulterande chunken och arkivuppslaget avgör om den ska lagras eller återanvändas. Besparingarna från dedupliceringen uppstår först i de två sista stegen, även om CDC gör det betydligt mer sannolikt att matchningarna överlever redigeringar.
Chunkstorlek och datatransformering sätter gränsen mellan beräkningskostnad och besparing
Mindre genomsnittliga chunkar isolerar ändringar mer exakt, men ökar antalet fingeravtryck, indexposter, uppslagningar, metadataobjekt och lagringsreferenser. Större chunkar minskar indexeringskostnaden, men gör att en liten redigering kan ogiltigförklara en större enhet återanvändbart innehåll.
FastCDC fokuserar på att minska CPU-kostnaden för rullande hashberäkning samtidigt som en stark redundansdetektering bibehålls. Det visar att själva chunkningen kan bli en betydande kostnad innan några duplicerade byte har eliminerats. De bästa parametrarna balanserar chunkningsarbete, indexstorlek och likhetsmönstret i säkerhetskopieringsuppsättningen.
Transformering före chunkning kan också ta bort den bytelikhet som CDC är beroende av. Kryptering med olika nonce-värden, format som skriver om större delen av en fil efter en liten logisk ändring eller vissa komprimeringslayouter kan få två logiskt liknande versioner att se orelaterade ut på bytenivå.
ZimaSpaces analys av omkostnader för dedupliceringsindex behandlar den andra sidan av denna avvägning: finare återanvändning kräver mer metadata och minne för att hålla reda på vad som redan finns. CDC är värdefullt när den återvunna lagringskapaciteten överstiger den extra kostnaden för chunkning och indexering, inte bara för att chunkar med variabel storlek låter mer avancerade.
Rekommenderade produkter
Teknik- och AI-hubb
Mer att läsa
Vad är Plex-tillståndet och vilka delar måste bevaras?
Beständig Plex-tillståndsinformation är den information som bevarar serverupplevelsen efter omstarter och återuppbyggnad; media och tillfälliga omkodningsdata har separata funktioner.
Hur hanterar Plex autentisering för lokala och fjärranslutna sessioner?
Plex-autentisering börjar med serverns och kontots identitet, därefter avgör lokala eller fjärranslutna nätverksvägar åtkomligheten och hur säkra anslutningar fungerar.
Varför kan Plex-sökningar bli långsammare när biblioteksdata ökar?
Att biblioteket växer är inte i sig en diagnos. Testa frågeformen, indexen, cachetillståndet, lagringsfördröjningen och skrivaktiviteten innan du skyller på databasens storlek.
