Data Domain: Vanliga frågor om komprimering

Summary: I den här artikeln får du svar på de vanligaste frågorna om komprimering. Data Domains är oberoende av datatyp. Data Domain använder komprimeringsalgoritmer som endast säkerhetskopierar unika data – duplicerade mönster eller flera säkerhetskopior lagras bara en gång. ...

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

Innehållsförteckning

|
 
Typiska komprimeringshastigheter är 20:1 under många veckor med dagliga och inkrementella säkerhetskopieringar. Datatypen påverkar komprimeringsförhållandet – komprimerade bildfiler, databaser och komprimerade arkiv (t.ex. .zip filer) komprimeras inte på ett bra sätt.
 

Använder inkrementella och fullständiga säkerhetskopieringar samma diskutrymme?

Helst skulle detta vara sant. I praktiken använder den fullständiga säkerhetskopieringen lite mer utrymme än den inkrementella av följande skäl. Dessa orsaker förklarar också varför en fullständig säkerhetskopiering utan dataändringar fortfarande förbrukar en positiv mängd utrymme.
  • Metadata tar cirka 0,5 % av säkerhetskopians logiska storlek. Anta att:
    • Den logiska storleken på den fullständiga är 100 GB
    • Den logiska storleken på inkrementell är 2 GB
    • Den inkrementella komprimeringen till 1 GB
    • ... då tar den fulla minst 1,5 GB
  • DD-komprimeringsmotorn skriver om vissa duplicerade datasegment för prestanda. Ju sämre dataplatsen för ändringarna är, desto mer skrivs dubbletterna. Dubbletterna frigörs senare av filsystemets skräpinsamling (GC). I vissa fall skrivs cirka 2 % av den logiska storleken om som dubblett. Om vi antar den här nivån av dubbletter kan det ta 1 GB (komprimerat) + 0,5 GB (metadata) + 2 GB (dubbletter) = 3,5 GB. Mängden dubbletter som skrivs kan styras via en systemparameter, men vi justerar vanligtvis inte den här parametern i fältet.
  • Datasegmenteringen kan variera lite från säkerhetskopia till säkerhetskopiering beroende på i vilken ordning NFS-klienten skickar data. Den här ordningen är inte deterministisk. I allmänhet tolererar segmenteringsalgoritmen förskjutningar och omordning. Men det skapar också vissa "tvingade" segment, som är benägna att flyttas och omordnas. Vanligtvis är cirka 0,2 % av segmenten tvingade, så att mycket mer utrymmesanvändning kan förväntas.
 

Varför gör ?filesys show space" och "filesys show compression' visa olika nummer?

  • 'filesys show space' ger komprimeringsförhållandet baserat på den logiska storleken på de data som lagras och det diskutrymme som används vid den tidpunkt då kommandot körs.
  • 'filesys show compression' ger komprimeringsförhållandet baserat på hur varje fil komprimerades vid den tidpunkt då den skapades.
  • 'filesys show compression' används mest för support och felsökning. I närvaro av fil raderar, "filesys show compression' överskattar kompressionsförhållandet.
 
Anta till exempel att:
  • Den första fullständiga säkerhetskopieringen får 2x komprimering
  • En efterföljande fullständig säkerhetskopiering utan några dataändringar får 200x komprimering
  • Den första fullständiga säkerhetskopian tas bort
Resultatet av "filesys show space" skulle visa ett kompressionsförhållande på 2x, medan "filesys show compression' skulle visa ett komprimeringsförhållande på 200x, eftersom den enda fil som finns nu fick ett komprimeringsförhållande på 200x när den skapades.
 
I exemplet ovan, efter den andra säkerhetskopian, 'filesys show space' skulle visa ett kumulativt förhållande på cirka 4x. Det kumulativa förhållandet skulle förbättras asymptotiskt mot 200x om du fortsätter med fler säkerhetskopieringar utan borttagning.
 
Det finns några andra mindre skillnader. Metoden "filesys show compression' kommandot:
  • Tar inte hänsyn till slöseri på behållarnivå, vilket gör att kompressionsförhållandet överskattas ytterligare
  • Tar inte hänsyn till duplicerad eliminering genom global komprimering, vilket underskattar kompressionsförhållandet
  • Kan tillhandahålla information per fil eller per katalog, medan "filesys show space" är begränsad till hela systemet
  • Ger uppdelningen mellan global och lokal komprimering, medan 'filesys show space" inte
 

Varför gör "filesys show compression last 24 hours' inte motsvara förväntningarna på VTL?

För VTL kan utdata från kommandon som 'filesys show compression last 24 hours" uppfyller ofta inte förväntningarna på grundval av andra källor, t.ex. "system show performance'.
 
Problemet uppstår på grund av en egenhet i 'filesys show compression'. I allmänhet visar den kumulativ statistik i valda filer. Kvalificeraren "senaste 24 timmarna" väljer filer som har uppdaterats under de senaste 24 timmarna. Statistiken är fortfarande kumulativ sedan filen skapades eller senast trunkerades till nollstorlek. Således, om en fil har lagts till under de senaste 24 timmarna, 'filesys show compression last 24 hours' visar dess kumulativa statistik före de senaste 24 timmarna.
 
Säkerhetskopior i icke-VTL-miljöer skrivs bara en gång, så det är liten skillnad mellan filer som uppdateras och filer som skapas. Med VTL kan säkerhetskopior läggas till befintliga bandfiler. Tänk dig till exempel ett band på 100 GB som fylls upp till 50 GB. Om 10 GB data har lagts till på detta band under de senaste 24 timmarna, 'filesys show compression last 24 hours' skulle visa filens "Originalbyte" skrivna på 60 GB.
 

Hur beräknas det kumulativa kompressionsförhållandet?

Individuella kompressionsförhållanden går inte ihop linjärt.
 
Anta att komprimeringen vid den första fullständiga säkerhetskopian är 2x och att komprimeringen vid den andra fullständiga säkerhetskopian är 20x. Den kumulativa komprimeringen är inte (2 + 20) / 2 = 11xMen 2 / (1/2 + 1/20) = 3.64x.
 
I allmänhet har lägre kompressionsförhållanden större inverkan än högre på det kumulativa kompressionsförhållandet.
 
Antag att ith Säkerhetskopian har logisk storlek si och kompressionsförhållande ci. Sedan ska det kumulativa kompressionsförhållandet för k Säkerhetskopior kan beräknas på följande sätt: 
C = (total logical size)/(total space used)
total logical size = s1 + s2 + .. + sk
total space used = s1/c1 + s2/c2 + ... + sk/ck
 
Ofta är de logiska storlekarna ungefär desamma. I så fall förenklas ovanstående beräkning till följande:
C = k / (1/c1 + 1/c2 + ... + 1/ck)
 
Till exempel om:
  • Den första fullständiga säkerhetskopieringen får 3x komprimering
  • Varje efterföljande full får 30x komprimering
  • Kvarhållningsperioden är 30 dagar

Användaren ser en kumulativ komprimering av 30 / (1/3 + 29/30)eller 23x.

 

Hur fungerar Data Domain-komprimering?

Denna fråga besvaras i detalj i en separat artikel: Förstå komprimering i Data Domain
 

Har Data Domain stöd för multiplexering?

Multiplexerade data från säkerhetskopieringsprogrammet resulterar i mycket dålig global deduplicering. Mer information finns i den här artikeln: Data Domain: Multiplexering i säkerhetskopieringsprogram
 

Varför visar repliken bättre global komprimering med 1-till-1-katalogreplikering?

Detta beror vanligtvis på variationer i nivån på dubbletter av segment som skrivs i systemet:
  • De data som lagras vid källan har deduplicerats en gång – mot de tidigare data som lagrats vid källan.
  • De data som skickas via kabeln har deduplicerats en gång – mot de data som lagras på repliken.
  • Data som lagras på repliken har deduplicerats två gånger, en gång när data skickades via kabeln och igen när mottagna data skrivs på repliken.
Eftersom dedupliceringsprocessen lämnar vissa dubbletter har data som har deduplicerats flera gånger färre dubbletter. De data som lagras vid källan och skickas via kabeln dedupliceras en gång, så de är ungefär desamma, förutsatt att de data som lagras vid källan och repliken är liknande. Data som lagras på repliken dedupliceras två gånger, så det är bättre komprimerat.
 
Rensning av filsystemet tar bort de flesta dubbletterna. När rensningen har körts på källan och repliken bör därför mängden data som lagras där vara ungefär densamma.
 

Vad är förändringen i komprimering när du använder lz, gzfastoch gz Lokala komprimeringsinställningar?

Använd följande kommando om du vill ändra den lokala komprimeringsalgoritmen som används i en Data Domain:
filesys option set compression {none | lz | gzfast | gz}
 
Obs! Filsystemet måste stängas av innan du ändrar den lokala komprimeringstypen. Den kan sedan startas om omedelbart efter att komprimeringsalternativet har ställts in.
 
I allmänhet är komprimeringsordningen följande:
lz < gzfast < gz
 
Typ Förväntad komp. CPU-belastning
ingen 1x 0x
Lz 2x 1x
gzfast gzfast 2,5 ggr 2x
Gz 3x 5x
 
Den grova skillnaden är:
  • lz to gzfast ger ~15 % bättre komprimering och förbrukar 2x CPU
  • lz to gz ger ~30 % bättre komprimering och förbrukar 5x CPU
  • gzfast to gz ger ~10-15% bättre kompression
Observera att om du ändrar den lokala komprimeringen påverkas nya data som skrivs till Data Domain efter att ändringen har gjorts. De gamla uppgifterna behåller sitt tidigare komprimeringsformat till nästa rensningscykel. Nästa rensningscykel kopierar vidarebefordra alla gamla data till det nya komprimeringsformatet. Detta gör att rensningen körs mycket längre och tar mer CPU.
 
Om systemet redan har ont om processor, särskilt om säkerhetskopiering och replikering körs samtidigt, kan detta göra säkerhetskopieringarna långsammare. Kunden kanske uttryckligen vill schemalägga en tid för att göra den här konverteringen.

Additional Information

Kunskapsreferenser:

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.