Data Domain – vanlige spørsmål om komprimering

GJELDER FOR

• Alle DDR-er
• Alle utgivelser

Komprimering: Vanlige spørsmål:

Ideelt sett ville dette være sant. I praksis bruker full sikkerhetskopi litt mer plass enn den inkrementelle på grunn av følgende årsaker. Disse årsakene forklarer også hvorfor en full sikkerhetskopi etter ingen endringer i data fortsatt vil forbruke 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, og den inkrementelle er 2 GB. Anta at de trinnvise komprimerer til 1 GB. Da vil hele ta minst 1,5 GB.
• DD-komprimeringsmotoren skriver om noen dupliserte datasegmenter for ytelse. Jo dårligere datalokaliteten til endringene, jo mer blir duplikatene skrevet. Duplikatene blir senere gjenvunnet ved "filesys cleaning". Jeg har sett ca 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 ombestilling. Det skaper imidlertid også noen "tvungne" segmenter, som er utsatt for skift og ombestilling. Vanligvis er omtrent 0,2% av segmentene tvunget, så man kan forvente at mye mer plass brukes.

"filesys show space" gir kompresjonsforholdet basert på den logiske størrelsen på dataene som er lagret og diskplassen som brukes når kommandoen kjøres.

"filesys show compression" gir komprimeringsforholdet basert på hvordan hver fil ble komprimert da den ble opprettet.

"filesys show compression" brukes mest til støtte og feilsøking. I nærvær av filslettinger overvurderer "filesys show compression" kompresjonsforholdet.

For eksempel er antagelsen 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. "filesys show space" viser et kompresjonsforhold på 2x. "filesys show compression" vil nå vise et kompresjonsforhold på 200x, fordi den eneste filen som eksisterer nå, hadde en komprimering på 200x da den ble opprettet.

I eksemplet nevnt ovenfor, etter den andre sikkerhetskopieringen, viser "filesys show space" det kumulative forholdet på omtrent 4x. Det kumulative forholdet vil forbedre seg asymptotisk mot 200x hvis du fortsetter å gjøre flere sikkerhetskopier uten sletting.

Det er noen andre mindre forskjeller:

•  "filesys show compression" tar ikke hensyn til svinn på beholdernivå, og overestimerer dermed kompresjonsforholdet ytterligere
•  "Filesys show compression" tar ikke hensyn til duplikateliminering ved global komprimering, og undervurderer dermed kompresjonsforholdet
•  "filesys show compression" kan gi informasjon per fil eller per katalog, mens "filesys show space" er begrenset til hele systemet
•  "filesys show compression" gir fordelingen mellom global og lokal komprimering, mens "filesys show space" ikke gjør det

REFERANSER

• Hvorfor er kompresjonsforholdene forskjellige for "filesys show space" og "vtl tape show summary"?

Kompresjonsforholdet som vises i "vtl tape show summary" er ment å samsvare med "filesys show compression /backup/vtc".

Mer generelt kan denne VTL-kommandoen gis et valgfritt filter for å velge et delsett av båndkassetter, og komprimeringen skal samsvare med "filesys show compression" på den delmengden av kassetter.

På grunn av en feil i VTL-UI-koden er komprimeringen som vises i "vtl tape show summary" feil. Dette er et kjent problem som er løst i versjon 4.5.0.0.
 

• Hvorfor samsvarer ikke "filesys show compression last 24 hours" med forventningene for VTL?

For VTL oppfyller utdataene fra kommandoer som "filesys show compression last 24 hours" ofte ikke forventningene basert på andre kilder, for eksempel "system show performance".

Problemet skjer på grunn av en særegenhet i "filesys show compression" (fsc). Generelt viser "filesys show compression" kumulativ statistikk i utvalgte filer. Kvalifikatoren "siste 24 timer" velger filene som ble oppdatert 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, vil "filesys show compression last 24 hours" vise den kumulative statistikken før de siste 24 timene.

I ikke-VTL-miljøer skrives sikkerhetskopifiler bare én gang, så det er ikke mye 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 med kapasitet på 100 GB som er fylt opp til 50 GB. Hvis 10 GB data er lagt til dette båndet i løpet av de siste 24 timene, vil "filesys show compression last 24 hours" vise filens "Original bytes" skrevet til 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 den andre fullstendige sikkerhetskopien er 20x. Den kumulative komprimeringen er ikke (2 + 20) / 2 eller 11x, men 2 / (1 / 2 + 1/20) eller 3,64x.

Generelt har lavere kompresjonsforhold større innvirkning enn høyere på det kumulative kompresjonsforholdet.

Anta at ith sikkerhetskopien har logisk størrelse si og kompresjonsforhold ci. Deretter kan det kumulative kompresjonsforholdet for k-sikkerhetskopier beregnes på følgende måte:

C = (total logisk størrelse) / (total plass brukt)
total logisk størrelse = s1 + s2 + .. + sk
total plass brukt = s1/c1 + s2/c2 + ... + sk/ck

Ofte er de logiske størrelsene omtrent de samme. I så fall forenkler beregningen ovenfor til følgende:

Hvis for eksempel den første fullstendige sikkerhetskopien får 3x komprimering, og hver påfølgende fullstendig får 30x komprimering, og oppbevaringsperioden er 30 dager, ser brukeren en kumulativ komprimering på 30/(1/3+29/30) eller 23x.
 

• Hvordan fungerer Data Domain-komprimering?

Dette spørsmålet er besvart i detalj i en separat KB-artikkel, "Understanding Data Domain Compression" Data Domain: Forstå Data Domain-komprimering
 

• Støtter datadomenet multipleksing? ​​​​​​​

Multipleksede data fra sikkerhetskopieringsapplikasjonen vil føre til svært dårlig global deduplisering. Hvis du vil ha mer informasjon, kan du se den relaterte artikkelen Multipleksing i sikkerhetskopieringsprogramvare støttes ikke Data Domain: Multipleksing i backup-programvare. 
 

• 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 én 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.

Opprydding av filsystemet fjerner de fleste duplikatene. 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, gzfast og gz lokale komprimeringsinnstillinger?

filesys alternativsett komprimering {none | lz | gzfast | gz}
 

Advarsel: Før du endrer den lokale komprimeringstypen, må filsystemet slås av. Den kan deretter startes på nytt umiddelbart etter at komprimeringsalternativet er angitt.

Generelt er rekkefølgen på komprimering som følger:

Den grove forskjellen er:

• lz til gzfast gir ~ 15% bedre komprimering og bruker 2x CPU
• lz til gz gir ~ 30% bedre komprimering og bruker 5x CPU
• gzfast til 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 DataDomain Restorer etter at endringen ble gjort. De gamle dataene beholder sitt tidligere komprimeringsformat til neste rengjøringssyklus. Den neste rengjøringssyklusen vil kopiere videresende alle gamle data til det nye komprimeringsformatet. Dette fører til at rengjøringen kjører mye lenger og tar mer CPU.

Hvis kundesystemet allerede har lite CPU, spesielt hvis kunden sikkerhetskopierer og replikerer samtidig, kan dette redusere sikkerhetskopieringen og/eller replikeringen. Kunden bør kanskje eksplisitt planlegge litt tid for å utføre denne konverteringen.

Kunnskapsreferanser:

• Løse migreringsproblemer
• Data Domain: Forstå Data Domain-komprimering