Data Domain: Ofte stillede spørgsmål om komprimering

Summary: Denne artikel besvarer de hyppigste spørgsmål vedrørende komprimering. Data Domains er uafhængige af datatypen. Data Domain bruger komprimeringsalgoritmer, der kun sikkerhedskopierer unikke data – duplikerede mønstre eller flere sikkerhedskopier gemmes kun én gang. ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.
Check out other resources

Instructions

Indholdsfortegnelse

|
 
Typiske komprimeringshastigheder er 20:1 over mange ugers daglige og trinvise sikkerhedskopieringer. Datatypen påvirker komprimeringsforholdet – komprimerede billedfiler, databaser og komprimerede arkiver (f.eks. .zip filer) komprimeres ikke godt.
 

Bruger trinvise og fulde sikkerhedskopier den samme diskplads?

Ideelt set ville dette være sandt. I praksis bruger den fulde sikkerhedskopi lidt mere plads end den inkrementelle af følgende årsager. Disse årsager forklarer også, hvorfor en fuld sikkerhedskopi uden ændringer i data stadig bruger en positiv mængde plads.
  • Metadataene tager ca. 0.5% af sikkerhedskopiens logiske størrelse. Antag, at:
    • Den logiske størrelse af den fulde er 100 GB
    • Den logiske størrelse af trinnet er 2 GB
    • Den trinvise komprimering til 1 GB
    • ... så tager den fulde mindst 1.5 GB
  • DD-komprimeringsprogrammet omskriver nogle identiske datasegmenter af hensyn til ydeevnen. Jo dårligere datalokaliteten af ændringerne er, desto mere skrives dubletterne. Duplikaterne genvindes senere af File System Garbage Collection (GC). I nogle tilfælde omskrives ca. 2% af den logiske størrelse som duplikat. Hvis vi antager dette niveau af dubletter, kan det fulde tage 1 GB (komprimeret) + 0,5 GB (metadata) +2 GB (dubletter) = 3,5 GB. Mængden af skrevne dubletter kan styres via en systemparameter, men vi justerer generelt ikke denne parameter i feltet.
  • Datasegmenteringen kan variere lidt fra sikkerhedskopiering til sikkerhedskopiering afhængigt af den rækkefølge, NFS-klienten sender dataene i. Denne rækkefølge er ikke deterministisk. Generelt tolererer segmenteringsalgoritmen skift og omarrangering. Det skaber dog også nogle "tvungne" segmenter, som er tilbøjelige til skift og omarrangering. Typisk er omkring 0,2% af segmenterne tvunget, så der kan forventes meget mere pladsforbrug.
 

Hvorfor gøre det?filesys show space« og «filesys show compression' viser forskellige tal?

  • 'filesys show space' giver komprimeringsforholdet baseret på den logiske størrelse af de lagrede data og den diskplads, der bruges på det tidspunkt, hvor kommandoen køres.
  • 'filesys show compression' giver komprimeringsforholdet baseret på, hvordan hver fil blev komprimeret på det tidspunkt, den blev oprettet.
  • 'filesys show compression' bruges mest til support og fejlfinding. I nærværelse af fil sletter, 'filesys show compression') overvurderer kompressionsforholdet.
 
Antag f.eks., at:
  • Den første fulde sikkerhedskopi får 2x komprimering
  • En efterfølgende fuld sikkerhedskopi uden dataændringer får 200x komprimering
  • Den første fulde sikkerhedskopi slettes
Produktionen af 'filesys show space' ville vise et kompressionsforhold på 2x, mens 'filesys show compression' ville vise et komprimeringsforhold på 200x, fordi den eneste fil, der findes nu, fik et komprimeringsforhold på 200x, da den blev oprettet.
 
I eksemplet ovenfor, efter den anden backup, 'filesys show space' ville vise et kumulativt forhold på ca. 4x. Det kumulative forhold forbedres asymptotisk mod 200x, hvis man fortsætter med flere sikkerhedskopier uden sletning.
 
Der er nogle andre mindre forskelle. Den 'filesys show compression' kommando:
  • Tager ikke højde for spild på containerniveau, hvilket overvurderer kompressionsforholdet yderligere
  • Tager ikke højde for dobbelteliminering ved global komprimering, hvilket undervurderer kompressionsforholdet
  • Kan give oplysninger pr. fil eller pr. mappe, mens 'filesys show space' er begrænset til hele systemet
  • Viser fordelingen mellem global og lokal komprimering, mens 'filesys show space') ikke
 

Hvorfor gør 'filesys show compression last 24 hours' ikke matche forventningerne til VTL?

For VTL er outputtet af kommandoer som 'filesys show compression last 24 hours' ofte ikke opfylder forventningerne baseret på andre kilder som 'system show performance'.
 
Problemet opstår på grund af en ejendommelighed i 'filesys show compression'. Generelt viser den kumulativ statistik i udvalgte filer. Kvalifikatoren "seneste 24 timer" vælger filer, der er blevet opdateret inden for de seneste 24 timer. Statistikken er stadig kumulativ, da filen blev oprettet eller sidst afkortet til nulstørrelse. Hvis der således er blevet tilføjet en fil inden for de sidste 24 timer, ')filesys show compression last 24 hours' viser dens kumulative statistik før de sidste 24 timer.
 
Sikkerhedskopieringsfiler i ikke-VTL-miljøer skrives kun én gang, så der er lidt uoverensstemmelse mellem opdaterede filer og oprettede filer. Med VTL kan sikkerhedskopier føjes til eksisterende båndfiler. Overvej for eksempel et 100 GB bånd, der er fyldt op til 50 GB. Hvis der inden for de sidste 24 timer er blevet vedlagt 10 GB data ')filesys show compression last 24 hours' ville vise filens "Original bytes" skrevet ved 60 GB.
 

Hvordan beregnes det kumulative kompressionsforhold?

Individuelle kompressionsforhold tilføjer ikke lineært.
 
Antag, at komprimeringen på den første fulde sikkerhedskopi er 2x, og at den på den anden fulde backup er 20x. Den kumulative komprimering er ikke (2 + 20) / 2 = 11xMen 2 / (1/2 + 1/20) = 3.64x.
 
Generelt har lavere kompressionsforhold større indflydelse end højere på det kumulative kompressionsforhold.
 
Antag, at ith Backup har logisk størrelse si og kompressionsforhold ci. Derefter bliver det kumulative kompressionsforhold for k Sikkerhedskopier kan beregnes på følgende måde: 
C = (total logical size)/(total space used)
total logical size = s1 + s2 + .. + sk
total space used = s1/c1 + s2/c2 + ... + sk/ck
 
Ofte er de logiske størrelser nogenlunde de samme. I så fald forenkler ovenstående beregning følgende:
C = k / (1/c1 + 1/c2 + ... + 1/ck)
 
For eksempel, hvis:
  • Den første fulde sikkerhedskopi får 3x komprimering
  • Hver efterfølgende fuld får 30x komprimering
  • Opbevaringsperioden er 30 dage

Brugeren ser en kumulativ komprimering af 30 / (1/3 + 29/30)eller 23x.

 

Hvordan fungerer Data Domain-komprimering?

Dette spørgsmål besvares detaljeret i en separat artikel: Om Data Domain-komprimering
 

Understøtter Data Domain multiplexing?

Multiplekserede data fra sikkerhedskopieringsprogrammet resulterer i meget dårlig global deduplikering. Du kan finde flere oplysninger i denne artikel: Data Domain: Multiplexing i sikkerhedskopieringssoftware
 

Hvorfor viser replikaen bedre global komprimering med 1-til-1-biblioteksreplikering?

Dette skyldes normalt variationer i niveauet af duplikatsegmenter, der er skrevet på systemet:
  • De data, der er gemt ved kilden, er blevet deduplikeret én gang - mod de tidligere data, der er gemt ved kilden.
  • De data, der sendes over ledningen, er blevet deduplikeret én gang - mod de data, der er gemt på replikaen.
  • De data, der er gemt på replikaen, er blevet deduplikeret to gange, én gang, når dataene blev sendt over ledningen, og igen, når de modtagne data skrives på replikaen.
Da deduplikeringsprocessen efterlader nogle dubletter, har data, der er blevet deduplikeret flere gange, færre dubletter. De data, der er gemt ved kilden og sendt over ledningen, deduplikeres én gang, så de er stort set de samme, forudsat at de data, der er gemt ved kilden og replikaen, er ens. De data, der er gemt på replikaen, deduplikeres to gange, så de komprimeres bedre.
 
Oprydning af filsystemet fjerner de fleste dubletter. Når rensningen er kørt på kilden og replikaen, bør mængden af data, der er gemt der, derfor være omtrent den samme.
 

Hvad er ændringen i komprimering ved brug lz, gzfastog gz Lokale komprimeringsindstillinger?

Brug følgende kommando til at ændre den lokale komprimeringsalgoritme, der bruges i et Data Domain:
filesys option set compression {none | lz | gzfast | gz}
 
Bemærk: Filsystemet skal lukkes ned, før den lokale komprimeringstype ændres. Den kan derefter genstartes umiddelbart efter, at komprimeringsindstillingen er blevet indstillet.
 
Generelt er kompressionsrækkefølgen som følger:
lz < gzfast < gz
 
Skriv Forventet comp. CPU-belastning
ingen 1x 0x
Lz 2x 1x
GZFAST 2,5x 2x
Gz 3x 5x
 
Den grove forskel er:
  • lz to gzfast giver ~ 15% bedre komprimering og bruger 2x CPU
  • lz to gz giver ~ 30% bedre komprimering og bruger 5x CPU
  • gzfast to gz giver ~10-15% bedre kompression
Bemærk, at ændring af den lokale komprimering først påvirker nye data, der skrives til Data Domain, efter ændringen blev foretaget. De gamle data bevarer deres tidligere komprimeringsformat indtil næste rensningscyklus. Den næste oprydningscyklus kopierer alle de gamle data videre til det nye komprimeringsformat. Dette får rengøringen til at køre meget længere og tage mere CPU.
 
Hvis systemet allerede er ved at løbe tør for CPU, især hvis sikkerhedskopier og replikering kører samtidigt, kan dette gøre sikkerhedskopieringerne langsommere. Kunden ønsker måske eksplicit at planlægge noget tid til at udføre denne konvertering.

Additional Information

Videnreferencer:

Affected Products

Data Domain

Products

Data Domain
Article Properties
Article Number: 000022100
Article Type: How To
Last Modified: 24 Apr 2026
Version:  12
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.