Data Domain: Komprimering Ofte Stilte Spørsmål

Summary: Denne artikkelen svarer på de vanligste spørsmålene om komprimering. Datadomener er uavhengige av datatype. Data Domain bruker komprimeringsalgoritmer som bare sikkerhetskopierer unike data – dupliserte mønstre eller flere sikkerhetskopier lagres bare é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

Innholdsfortegnelse

|
 
Typiske kompresjonshastigheter er 20:1 over mange uker med daglige og inkrementelle sikkerhetskopier. Datatype påvirker komprimeringsforholdet - komprimerte bildefiler, databaser og komprimerte arkiver (for eksempel .zip filer) komprimeres ikke godt.
 

Bruker inkrementelle og fullstendige sikkerhetskopier samme diskplass?

Ideelt sett ville dette være sant. I praksis bruker full sikkerhetskopi litt mer plass enn den inkrementelle av følgende grunner. Disse årsakene forklarer også hvorfor en full sikkerhetskopi etter ingen endringer i data fortsatt bruker en positiv mengde plass.
  • Metadataene tar omtrent 0,5 % av den logiske størrelsen på sikkerhetskopien. Anta at:
    • Den logiske størrelsen på full er 100 GB
    • Den logiske størrelsen på økningen er 2 GB
    • Den trinnvise komprimeringen til 1 GB
    • ... da tar hele minst 1,5 GB
  • DD-komprimeringsmotoren omskriver noen dupliserte datasegmenter for ytelse. Jo dårligere datalokaliteten til endringene, jo mer blir duplikatene skrevet. Duplikatene blir senere gjenvunnet av filsystemets søppelinnsamling (GC). I noen tilfeller blir omtrent 2% av den logiske størrelsen omskrevet som duplikat. Forutsatt dette nivået av duplikater, kan hele ta 1 GB (komprimert) + 0,5 GB (metadata) + 2 GB (duplikater) = 3,5 GB. Mengden duplikater som skrives kan styres gjennom en systemparameter, men vi justerer vanligvis ikke denne parameteren i feltet.
  • Datasegmenteringen kan variere litt fra backup til backup, avhengig av rekkefølgen NFS-klienten sender dataene i. Denne rekkefølgen er ikke deterministisk. Generelt tolererer segmenteringsalgoritmen skift og omorganisering. Det skaper imidlertid også noen "tvungne" segmenter, som er utsatt for skift og omorganisering. Vanligvis er omtrent 0,2% av segmentene tvunget, slik at mye mer plassbruk kan forventes.
 

Hvorfor gjøre 'filesys show space' og 'filesys show compression'Vis forskjellige tall?

  • 'filesys show space' gir kompresjonsforholdet basert på den logiske størrelsen på dataene som er lagret og diskplassen som brukes på det tidspunktet kommandoen kjøres.
  • 'filesys show compression' gir kompresjonsforholdet basert på hvordan hver fil ble komprimert på det tidspunktet den ble opprettet.
  • 'filesys show compression' brukes mest til støtte og feilsøking. I nærvær av filslettinger, 'filesys show compression' overvurderer kompresjonsforholdet.
 
Anta for eksempel at:
  • Den første fullstendige sikkerhetskopien får 2x komprimering
  • En påfølgende full sikkerhetskopiering uten dataendringer får 200x komprimering
  • Den første fullstendige sikkerhetskopien slettes
Utgangen av 'filesys show space' ville vise et kompresjonsforhold på 2x, mens 'filesys show compression'ville vise et kompresjonsforhold på 200x, fordi den eneste filen som eksisterer nå fikk et kompresjonsforhold på 200x da den ble opprettet.
 
I eksemplet ovenfor, etter den andre sikkerhetskopien, 'filesys show space' ville vise et kumulativt forhold på omtrent 4x. Det kumulative forholdet vil forbedres asymptotisk mot 200x hvis det fortsetter med flere sikkerhetskopier uten sletting.
 
Det er noen andre mindre forskjeller. Den 'filesys show compression'kommando:
  • Tar ikke hensyn til svinn på containernivå, og overestimerer dermed kompresjonsforholdet ytterligere
  • Tar ikke hensyn til duplikateliminering ved global komprimering, og underestimerer dermed kompresjonsforholdet
  • Kan gi informasjon per fil eller per katalog, mens 'filesys show space' er begrenset til hele systemet
  • Gir fordelingen mellom global og lokal komprimering, mens 'filesys show space'gjør ikke
 

Hvorfor 'filesys show compression last 24 hours'ikke matche forventningene til VTL?

For VTL er utdataene fra kommandoer som "filesys show compression last 24 hours'ofte oppfyller ikke forventningene basert på andre kilder som 'system show performance'.
 
Problemet skjer på grunn av en særegenhet i 'filesys show compression'. Generelt viser den kumulativ statistikk i utvalgte filer. Kvalifikatoren "siste 24 timer" velger filer som ble oppdatert i løpet av de siste 24 timene. Statistikken er fortsatt kumulativ siden filen ble opprettet eller sist avkortet til null størrelse. Så hvis en fil ble lagt til i løpet av de siste 24 timene, 'filesys show compression last 24 hours'viser sin kumulative statistikk før de siste 24 timene.
 
Sikkerhetskopifiler i ikke-VTL-miljøer skrives bare én gang, så det er lite avvik mellom filer som oppdateres og filer som opprettes. Med VTL kan sikkerhetskopier legges til eksisterende båndfiler. Tenk deg for eksempel et bånd på 100 GB som er fylt opp til 50 GB. Hvis 10 GB data ble lagt til dette båndet i løpet av de siste 24 timene, 'filesys show compression last 24 hours'ville vise filens "Original bytes" skrevet på 60 GB.
 

Hvordan beregnes det kumulative kompresjonsforholdet?

Individuelle kompresjonsforhold legger ikke opp lineært.
 
Anta at komprimeringen på den første fullstendige sikkerhetskopien er 2x og at på den andre fullstendige sikkerhetskopien er 20x. Den kumulative komprimeringen er ikke (2 + 20) / 2 = 11xmen 2 / (1/2 + 1/20) = 3.64x.
 
Generelt har lavere kompresjonsforhold større innvirkning enn høyere på det kumulative kompresjonsforholdet.
 
Anta at ith Sikkerhetskopiering har logisk størrelse si og kompresjonsforhold ci. Deretter vil det kumulative kompresjonsforholdet for k Sikkerhetskopier kan beregnes på følgende måte: 
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ørrelsene omtrent de samme. I så fall forenkler beregningen ovenfor til følgende:
C = k / (1/c1 + 1/c2 + ... + 1/ck)
 
For eksempel, hvis:
  • Den første fullstendige sikkerhetskopien får 3x komprimering
  • Hver påfølgende full får 30x komprimering
  • Oppbevaringsperioden er 30 dager

brukeren ser en kumulativ komprimering av 30 / (1/3 + 29/30), eller 23x.

 

Hvordan fungerer Data Domain-komprimering?

Dette spørsmålet er besvart i detalj i en egen artikkel: Forstå Data Domain-komprimering
 

Støtter Data Domain multipleksing?

Multipleksede data fra sikkerhetskopieringsapplikasjonen resulterer i svært dårlig global deduplisering. Hvis du vil ha mer informasjon, kan du se denne artikkelen: Data Domain: Multipleksing i programvare for sikkerhetskopiering
 

Hvorfor viser replikaen bedre global komprimering når katalogreplikering 1 til 1-katalogreplikering?

Dette er vanligvis på grunn av variasjoner i nivået av dupliserte segmenter skrevet på systemet:
  • Dataene som er lagret ved kilden, har blitt deduplisert en gang - mot de tidligere dataene som er lagret ved kilden.
  • Dataene som sendes over ledningen har blitt deduplisert én gang - mot dataene som er lagret i replikaen.
  • Dataene som er lagret i replikaen, har blitt deduplisert to ganger, én gang når dataene ble sendt over ledningen, og igjen når de mottatte dataene er skrevet på replikaen.
Siden dedupliseringsprosessen etterlater noen duplikater, har data som har blitt deduplisert flere ganger, færre duplikater. Dataene som er lagret ved kilden og sendes over ledningen, dedupliseres en gang, slik at de er omtrent de samme, forutsatt at dataene som er lagret ved kilden og replikaen er like. Dataene som er lagret på replikaen, dedupliseres to ganger, slik at det blir bedre komprimert.
 
Rensing av filsystem fjerner de fleste duplikater. Derfor, etter at rengjøring har blitt kjørt på kilden og replikaen, bør mengden data som er lagret der, være omtrent det samme.
 

Hva er endringen i komprimering når du bruker lz, gzfastog gz Lokale komprimeringsinnstillinger?

Bruk følgende kommando til å endre den lokale komprimeringsalgoritmen som brukes i et datadomene:
filesys option set compression {none | lz | gzfast | gz}
 
Merk: Filsystemet må slås av før du endrer den lokale komprimeringstypen. Den kan deretter startes på nytt umiddelbart etter at komprimeringsalternativet er angitt.
 
Generelt er rekkefølgen på kompresjon som følger:
lz < gzfast < gz
 
Skriv inn Forventet comp. CPU-belastning
Ingen 1x 0x
Lz 2x 1x
GZFAST 2,5 ganger 2x
Gz 3x 5x
 
Den grove forskjellen er:
  • lz to gzfast gir ~15% bedre komprimering og bruker 2x CPU
  • lz to gz gir ~30% bedre komprimering og bruker 5x CPU
  • gzfast to gz gir ~10-15% bedre komprimering
Vær oppmerksom på at endring av lokal komprimering først påvirker nye data som er skrevet til datadomenet etter at endringen ble gjort. De gamle dataene beholder sitt tidligere komprimeringsformat til neste rengjøringssyklus. Den neste oppryddingssyklusen kopierer videresending av alle gamle data til det nye komprimeringsformatet. Dette fører til at rengjøringen kjører mye lenger og tar mer CPU.
 
Hvis systemet allerede har lite CPU, spesielt hvis sikkerhetskopiering og replikering kjører samtidig, kan dette redusere sikkerhetskopieringene og. Kunden bør kanskje eksplisitt planlegge litt tid for å utføre denne konverteringen.

Additional Information

Kunnskapsreferanser:

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.