Waarom lijken ontdubbelde back-ups kleiner dan hun herstelomvang?

Deduplicated back-ups lijken kleiner omdat herhaalde chunks één keer worden opgeslagen, terwijl een herstelbewerking elk logisch bestand en elke onafhankelijke kopie reconstrueert.

Tien virtuele-machineschijven kunnen in een back-uprepository gigabytes aan identieke blokken van het besturingssysteem delen. Bij het herstellen naar een gewoon bestandssysteem worden tien adresruimten opnieuw aangemaakt, tenzij de bestemming ook compatibel delen, sparse bestanden of compressie ondersteunt. De repositorygrootte en herstelcapaciteit beschrijven daarom verschillende representaties met verschillende toewijzingsregels en overhead op het geselecteerde doelbestandssysteem.

Deduplicatie slaat identiteit één keer op en verwijst er meerdere keren naar

Back-upsoftware verdeelt gegevens in chunks, berekent er vingerafdrukken van en slaat alleen chunks op die nog niet aanwezig zijn. Manifesten leggen vast welke chunks bij elk bestand en herstelpunt horen. De repository kan veel logische kopieën weergeven met één fysieke gegevenslading plus verwijzingen.

Een overzicht van back-updeduplicatie legt uit hoe redundante kopieën uit back-upopslag worden verwijderd. De besparing hangt af van herhaalde inhoud, niet simpelweg van het aantal bestanden.

Herstel draait die toewijzing om. Elk bestand krijgt zijn geordende bytes op de aangevraagde bestemming. Als het doel geen blokdeling ondersteunt, nemen herhaalde chunks opnieuw afzonderlijke extents in beslag. Gegevensreductie was een eigenschap van de repository en geen belofte dat elke herstelde bestemming even compact blijft.

Compressie, sparsity en metagegevens vergroten het verschil

Compressie vermindert het aantal opgeslagen bytes afhankelijk van de entropie van de inhoud. Sparse bestanden slaan lange reeksen nullen over, maar een hersteloptie kan deze gaten materialiseren. Toewijzingseenheden, checksums, uitgebreide kenmerken en bestandssysteemmetagegevens voegen overhead op de bestemming toe die samenvattingen van de repository mogelijk niet bevatten.

Een uitleg over opslag maakt onderscheid tussen sparse bestanden en toegewezen grootte: een bestand kan een grote logische lengte rapporteren terwijl het minder fysieke blokken gebruikt. Hersteltools moeten gaten expliciet behouden om die besparing te handhaven.

Het omgekeerde kan ook gebeuren. Een gecomprimeerde bestemming of een copy-on-write-kloon kan herstelde gegevens kleiner houden dan hun logische grootte. Er bestaat geen universele vermenigvuldigingsfactor voor de omzetting van repositorybytes naar herstelde bytes, omdat representatie, bewaarset en doelbestandssysteem allemaal van belang zijn.

Wanneer deduplicatie niet de belangrijkste oorzaak is

De verklaring gaat niet op wanneer één niet-gededupliceerd bestand onverwacht groter wordt. Versleuteling, vooraf gecomprimeerde media, database-exportindelingen of een wijziging in thin provisioning kunnen dan de belangrijkste oorzaak zijn. Een back-upcatalogus kan ook alleen unieke gegevens voor één bereik weergeven, terwijl het herstel meerdere geselecteerde snapshots bevat.

Een technische bespreking van de deduplicatieverhouding benadrukt dat er onderscheid moet worden gemaakt tussen logische en fysieke grootten bij het rapporteren van deduplicatieverhoudingen. Verhoudingen zonder bereik kunnen capaciteitsplanning misleiden.

Het mechanisme is ook niet langer van toepassing als de hashes of aantallen van de herstelde bestanden verschillen van de geselecteerde back-up. Dan gaat het om selectie of integriteit, niet om verwachte groei. Kleinere back-upbytes rechtvaardigen niet dat er vóór verificatie te weinig tijdelijke ruimte wordt gereserveerd.

Featured

ZimaCube 2 Persoonlijke Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Meet een herstelbewerking in plaats van op de verhouding te vertrouwen

Kies een representatieve herstelset en registreer de logische bronbytes, unieke repositorybytes, gecomprimeerde bytes, sparse extents, het aantal bestanden en de toewijzingseenheid van de bestemming. Herstel naar een geïsoleerde bestemming met zowel opties die sparse bestanden behouden als standaardopties, en verifieer daarna de hashes en de toegewezen ruimte.

Gebruik een opslagplan voor gedeelde modelopslag, zodat de testbestemming actieve services niet kan verdringen. Houd de bewaartermijn van de repository en de compressie-instellingen van de bestemming gelijk tijdens het vergelijken van uitvoeringen.

Baseer de herstelcapaciteit op de grootste van de gemeten toegewezen uitvoer en de logische gegevensset plus werkbuffer, niet op het gededupliceerde repositorygetal. Als het behouden van sparse bestanden het resultaat verandert, leg die afhankelijkheid dan vast. Als de bestandsidentiteit of het aantal bestanden verandert, stop dan en los de correctheid van het herstel op voordat je de capaciteit afstemt.