Hoe vermindert contentgedefinieerde chunking dubbele back-upgegevens?

Inhoudsgebaseerde chunking verbetert back-updeduplicatie door chunkgrenzen te kiezen op basis van de bestandsinhoud, zodat ongewijzigde delen na invoegingen of verwijderingen opnieuw kunnen worden gebruikt.

Incrementele back-ups bevatten vaak grote bestanden die tussen versies grotendeels ongewijzigd blijven: virtuele-schijfkopieën, e-mailarchieven, databases die als bestanden zijn gekopieerd, projectbundels en geëxporteerde mediabibliotheken. Als elke chunk op een vaste byte-offset begint, kan het invoegen van een kleine header vooraan elke daaropvolgende grens verschuiven, ook al zijn de bytes verderop identiek. Inhoudsgebaseerde chunking laat de segmentatie lokale bytepatronen volgen in plaats van absolute posities, zodat de back-up na het gewijzigde gedeelte opnieuw kan synchroniseren met oude chunks.

Vaste grenzen kunnen van één kleine bewerking veel nieuwe chunks maken

Een chunker met vaste grootte knipt op posities zoals elke 1 MiB, ongeacht wat de bytes bevatten. Wanneer er vooraan bytes worden ingevoegd, raken de oude en nieuwe gegevensstromen ten opzichte van elkaar verschoven. Daardoor bevat elke daaropvolgende vaste chunk een andere combinatie van bytes, ook al bleef vrijwel alle onderliggende inhoud hetzelfde.

Inhoudsgebaseerde chunking is voor deduplicatie ontwikkeld, omdat op inhoud gebaseerde knippunten redundantie detecteren die vaste offsets na lokale bewerkingen kunnen missen. Het voordeel is niet dat CDC voorspelt welke bestanden op elkaar lijken; het geeft de deduplicator een segmentatie die verschoven posities kan overleven.

Als een volledig bestand wordt vervangen door niet-gerelateerde bytes, kan geen enkel chunkingalgoritme dubbele inhoud maken. CDC helpt vooral wanneer versies grote, ongewijzigde bytegebieden delen, maar deze ten opzichte van het begin van het bestand zijn verschoven.

Een rollende vingerafdruk zoekt lokale knippunten in de bytestroom

CDC verplaatst een venster over de invoer en werkt een vingerafdruk bij terwijl bytes dat venster binnenkomen en verlaten. Er wordt een grens vastgesteld wanneer de vingerafdruk aan een geconfigureerde voorwaarde voldoet, binnen regels voor minimale en maximale chunkgrootte die extreem kleine of grote chunks voorkomen.

De chunker van Borg gebruikt een rollende inhoudsvingerafdruk, zodat de kosten voor het evalueren van de volgende mogelijke grens niet vereisen dat het hele venster telkens opnieuw wordt gehasht. Omdat de vingerafdruk afhankelijk is van nabije bytes, kan dezelfde lokale reeks dezelfde knip activeren, zelfs wanneer de absolute bestandspositie is veranderd.

De rollende vingerafdruk is daarom een mechanisme om grenzen te vinden en niet de uiteindelijke identiteit van opgeslagen back-upgegevens. Als je die twee hashes als uitwisselbaar behandelt, wordt de uitleg van waar deduplicatie daadwerkelijk over hergebruik beslist minder nauwkeurig.

Ook de minimale, maximale en gemiddelde chunkgrootte beïnvloeden het zoeken naar grenzen. Ze bepalen hoe vaak mogelijke knippen worden overwogen en hoeveel metadata de repository moet beheren.

CDC synchroniseert na een bewerking opnieuw in plaats van blijvend verschoven te blijven

Na een invoeging of verwijdering ziet het rollende venster aanvankelijk andere bytes en produceert het rond de bewerking andere chunkgrenzen. Zodra het volledig in een voldoende lang ongewijzigd gebied terechtkomt, kan het dezelfde lokale inhoudspatronen tegenkomen en opnieuw knippen op posities die overeenkomen met de oudere versie.

Borg merkt op dat inhoudsgebaseerde grenzen stabiel ten opzichte van ongewijzigde inhoud kunnen blijven, zelfs wanneer elders bytes worden ingevoegd of verwijderd. Die hersynchronisatie zorgt ervoor dat veel bewerkingen beperkt blijven tot een klein aantal nieuwe chunks, in plaats van de rest van het bestand ongeldig te maken.

Restic splitst bestanden op vergelijkbare wijze op in blobs met variabele lengte met behulp van een verschuivende vingerafdruk, zodat ongewijzigde blobs met variabele lengte in verschillende snapshots opnieuw kunnen worden gebruikt. De repository heeft nog steeds een index nodig om die al opgeslagen blobs te herkennen.

De afstand tot hersynchronisatie hangt af van de chunkingparameters en het gewijzigde bytepatroon. CDC belooft dus niet dat er voor elke bewerking precies één nieuwe chunk verschijnt. Het voordeel is statistische lokaliteit: het is minder waarschijnlijk dat wijzigingen elke daaropvolgende grens verschuiven.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Een sterke chunkidentificatie bepaalt het hergebruik nadat de grens is gekozen

Het vinden van een grens beantwoordt alleen de vraag waar een kandidaat-chunk eindigt; de repository moet nog steeds bepalen of de volledige chunkinhoud al bestaat. Voor die tweede beslissing wordt een sterkere inhoudsidentificatie of geauthenticeerde hash over de voltooide chunk gebruikt, waarna deze in de repository-index wordt opgezocht.

Borg maakt expliciet onderscheid tussen zijn grenshash en de cryptografische chunkidentiteit die als criterium voor deduplicatie wordt gebruikt. Ook Restic verwijst naar opgeslagen blobs met een sterke inhoudshash, in plaats van de rollende vingerafdruk te behandelen als bewijs dat twee chunks identiek zijn.

Dit ontwerp in twee stappen maakt de opslagroute duidelijk: de rollende hash kiest de kandidaatsegmentatie; de inhoudshash identificeert de resulterende chunk; de repository-opzoeking beslist tussen opslaan en hergebruik. De besparing door deduplicatie ontstaat pas in de laatste twee stappen, ook al zorgt CDC ervoor dat deze overeenkomsten veel waarschijnlijker behouden blijven na bewerkingen.

Chunkgrootte en datatransformatie bepalen de grens tussen rekenwerk en besparing

Kleinere gemiddelde chunks isoleren wijzigingen nauwkeuriger, maar verhogen het aantal vingerafdrukken, indexvermeldingen, opzoekingen, metadataobjecten en opslagverwijzingen. Grotere chunks verlagen de indexeringskosten, maar zorgen ervoor dat een kleine bewerking een groter herbruikbaar gegevenseenheid ongeldig kan maken.

FastCDC richt zich op het verlagen van de CPU-overhead van de rollende hash terwijl sterke redundantiedetectie behouden blijft. Dit laat zien dat chunking zelf al aanzienlijke kosten kan veroorzaken voordat dubbele bytes worden geëlimineerd. De beste parameters brengen de chunkingbelasting, indexgrootte en het overeenkomstpatroon van de back-upset met elkaar in balans.

Transformatie vóór het chunken kan ook de byte-overeenkomst verwijderen waarvan CDC afhankelijk is. Versleuteling met verschillende nonces, indelingen die na een kleine logische wijziging het grootste deel van een bestand herschrijven, of bepaalde compressie-indelingen kunnen ervoor zorgen dat twee logisch vergelijkbare versies op byteniveau niet aan elkaar verwant lijken.

De analyse van ZimaSpace over de overhead van deduplicatie-indexen behandelt de andere kant van deze afweging: fijner hergebruik vereist meer metadata en geheugen om bij te houden wat al bestaat. CDC is waardevol wanneer de teruggewonnen opslagruimte groter is dan die extra kosten voor chunking en indexering, niet alleen omdat chunks met variabele grootte geavanceerder klinken.