Data Domain: Veelgestelde vragen over compressie
Summary: Dit artikel beantwoordt de meest gestelde vragen over compressie. Data Domains zijn onafhankelijk van het datatype. Data Domain maakt gebruik van compressiealgoritmen die alleen een back-up maken van unieke data. Gedupliceerde patronen of meerdere back-ups worden slechts één keer opgeslagen. ...
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.
Instructions
Inhoudsopgave
- Gebruiken incrementele en volledige back-ups dezelfde schijfruimte?
- Waarom '
filesys show space' en 'filesys show compression' verschillende getallen laten zien? - Waarom doet '
filesys show compression last 24 hours' niet voldoen aan de verwachtingen voor VTL? - Hoe wordt de cumulatieve compressieverhouding berekend?
- Hoe werkt Data Domain-compressie?
- Ondersteunt Data Domain multiplexing?
- Waarom geeft de replica bij 1-op-1 directoryreplicatie een betere algehele compressie weer?
- Wat is de verandering in compressie bij het gebruik van lokale compressie-instellingen voor lz, gzfast en gz?
Standaardcompressiesnelheden zijn 20:1 gedurende vele weken van dagelijkse en incrementele back-ups. Het gegevenstype heeft invloed op de compressieverhouding - gecomprimeerde afbeeldingsbestanden, databases en gecomprimeerde archieven (zoals .zip-bestanden) worden niet goed gecomprimeerd.
Gebruiken incrementele en volledige back-ups dezelfde schijfruimte?
In het ideale geval zou dit waar zijn. In de praktijk neemt de volledige back-up iets meer ruimte in beslag dan de incrementele back-up, en wel om de volgende redenen. Deze redenen verklaren ook waarom een volledige back-up zonder wijzigingen in data nog steeds een positieve hoeveelheid ruimte in beslag neemt.
- De metadata nemen ongeveer 0,5% van de logische grootte van de back-up in beslag. Stel dat:
- De logische grootte van het volledige is 100 GB
- De logische grootte van de incrementele is 2 GB
- De incrementele comprimeert tot 1 GB
- ... dan neemt de volledige minimaal 1,5 GB in beslag
- De DD-compressie-engine herschrijft enkele dubbele datasegmenten voor prestaties. Hoe slechter de gegevenslocatie van de wijzigingen, hoe meer de duplicaten worden geschreven. De duplicaten worden later teruggevorderd door garbage collection (GC) van het bestandssysteem. In sommige gevallen wordt ongeveer 2% van de logische grootte herschreven als duplicaat. Uitgaande van dit niveau van duplicaten, kan de volledige versie 1 GB (gecomprimeerd) + 0,5 GB (metadata) + 2 GB (duplicaten) = 3,5 GB in beslag nemen. Het aantal geschreven duplicaten kan worden geregeld via een systeemparameter, maar we stemmen deze parameter over het algemeen niet af in het veld.
- De datasegmentatie kan enigszins variëren van back-up tot back-up, afhankelijk van de volgorde waarin de NFS-client de data verzendt. Deze volgorde is niet deterministisch. Over het algemeen tolereert het segmentatie-algoritme verschuivingen en herschikkingen. Het creëert echter ook enkele "geforceerde" segmenten, die gevoelig zijn voor verschuivingen en herschikken. Doorgaans wordt ongeveer 0,2% van de segmenten geforceerd, zodat veel meer ruimtegebruik kan worden verwacht.
Waarom 'filesys show space' en 'filesys show compression' verschillende getallen laten zien?
- '
filesys show space' biedt de compressieverhouding op basis van de logische grootte van de opgeslagen gegevens en de schijfruimte die wordt gebruikt op het moment dat de opdracht wordt uitgevoerd. - '
filesys show compression' biedt de compressieverhouding op basis van hoe elk bestand is gecomprimeerd op het moment dat het werd gemaakt. - '
filesys show compression' wordt meestal gebruikt voor ondersteuning en foutopsporing. In het geval van bestandsverwijderingen, 'filesys show compression' overschat de compressieverhouding.
Stel bijvoorbeeld dat:
- De eerste volledige back-up wordt 2x gecomprimeerd
- Een daaropvolgende volledige back-up zonder datawijzigingen krijgt een compressie van 200x
- De eerste volledige back-up wordt verwijderd
De output van '
filesys show space' zou een compressieverhouding van 2x weergeven, terwijl 'filesys show compression' zou een compressieverhouding van 200x laten zien, omdat het enige bestand dat nu bestaat een compressieverhouding van 200x kreeg toen het werd gemaakt.
In het bovenstaande voorbeeld, na de tweede back-up, '
filesys show space' zou een cumulatieve verhouding van ongeveer 4x laten zien. De cumulatieve verhouding zou asymptotisch verbeteren in de richting van 200x als u doorgaat met meer back-ups zonder te verwijderen.
Er zijn nog enkele andere kleine verschillen. Het '
filesys show compression' commando:
- Houdt geen rekening met verspilling op containerniveau, waardoor de compressieverhouding nog verder wordt overschat
- Houdt geen rekening met dubbele eliminatie door globale compressie, waardoor de compressieverhouding wordt onderschat
- Kan informatie per bestand of per map verstrekken, terwijl '
filesys show space" is beperkt tot het gehele systeem - Biedt de uitsplitsing tussen globale en lokale compressie, terwijl '
filesys show space" niet
Waarom doet 'filesys show compression last 24 hours' niet voldoen aan de verwachtingen voor VTL?
Voor VTL is de uitvoer van commando's zoals '
filesys show compression last 24 hours' voldoet vaak niet aan de verwachtingen op basis van andere bronnen zoals 'system show performance'.
Het probleem doet zich voor als gevolg van een eigenaardigheid in '
filesys show compression'. Over het algemeen toont het cumulatieve statistieken in geselecteerde bestanden. De kwalificatie "last 24 hours" selecteert bestanden die in de afgelopen 24 uur zijn bijgewerkt. De statistieken zijn nog steeds cumulatief sinds het bestand is gemaakt of voor het laatst is afgekapt tot nulgrootte. Als er in de afgelopen 24 uur dus een bestand is toegevoegd, 'filesys show compression last 24 hours' toont de cumulatieve statistieken van vóór de laatste 24 uur.
Back-upbestanden in niet-VTL-omgevingen worden slechts één keer geschreven, dus er is weinig verschil tussen bijgewerkte bestanden en gemaakte bestanden. Met VTL kunnen back-ups worden toegevoegd aan bestaande tapebestanden. Denk bijvoorbeeld aan een tape van 100 GB die tot 50 GB gevuld is. Als er in de afgelopen 24 uur 10 GB aan gegevens aan deze tape is toegevoegd, '
filesys show compression last 24 hours' zou de "Original bytes" van het bestand laten zien die op 60 GB zijn geschreven.
Hoe wordt de cumulatieve compressieverhouding berekend?
Individuele compressieverhoudingen tellen niet lineair op.
Stel dat de compressie op de eerste volledige back-up 2x is en die op de tweede volledige back-up 20x. De cumulatieve compressie is niet
(2 + 20) / 2 = 11xMaar 2 / (1/2 + 1/20) = 3.64x.
Over het algemeen hebben lagere compressieverhoudingen meer invloed dan hogere op de cumulatieve compressieverhouding.
Stel dat de
ith Back-up heeft logische grootte si en compressieverhouding ci. Vervolgens wordt de cumulatieve compressieverhouding voor k Back-ups kunnen als volgt worden berekend:
C = (total logical size)/(total space used)
total logical size = s1 + s2 + .. + sk
total space used = s1/c1 + s2/c2 + ... + sk/ck
Vaak zijn de logische maten ongeveer hetzelfde. In dat geval vereenvoudigt de bovenstaande berekening het volgende:
C = k / (1/c1 + 1/c2 + ... + 1/ck)
Bijvoorbeeld als:
- De eerste volledige back-up krijgt 3x compressie
- Elke volgende volledige krijgt 30x compressie
- De bewaartermijn is 30 dagen
De gebruiker ziet een cumulatieve compressie van 30 / (1/3 + 29/30), oftewel 23x.
Hoe werkt Data Domain-compressie?
Deze vraag wordt in detail beantwoord in een apart artikel: Data Domain compressie begrijpen
Ondersteunt Data Domain multiplexing?
Meervoudige data van de back-upapplicatie resulteert in zeer slechte globale deduplicatie. Zie dit artikel voor meer informatie: Data Domain: Multiplexing in back-upsoftware
Waarom geeft de replica bij 1-op-1 directoryreplicatie een betere algehele compressie weer?
Dit komt meestal door variaties in het niveau van dubbele segmenten die op het systeem zijn geschreven:
- De gegevens die bij de bron zijn opgeslagen, zijn eenmaal gededupliceerd - ten opzichte van de eerdere gegevens die bij de bron zijn opgeslagen.
- De data die via de kabel zijn verzonden, zijn één keer gededupliceerd - ten opzichte van de data die zijn opgeslagen bij de replica.
- De data die zijn opgeslagen op de replica zijn twee keer gededupliceerd, één keer wanneer de data via de kabel werden verzonden en opnieuw wanneer de ontvangen data naar de replica worden geschreven.
Aangezien het deduplicatieproces enkele duplicaten achterlaat, hebben data die meerdere keren zijn gededupliceerd minder duplicaten. De gegevens die bij de bron zijn opgeslagen en via de kabel worden verzonden, worden één keer gededupliceerd, dus ze zijn ongeveer hetzelfde, ervan uitgaande dat de gegevens die bij de bron zijn opgeslagen en de replica vergelijkbaar zijn. De data die op de replica zijn opgeslagen, worden twee keer gededupliceerd, zodat ze beter worden gecomprimeerd.
Bij het opschonen van het bestandssysteem worden de meeste duplicaten verwijderd. Daarom moet de hoeveelheid opgeslagen gegevens die daar is opgeslagen ongeveer hetzelfde zijn nadat de bron en de replica zijn opgeschoond.
Wat is de verandering in compressie bij gebruik lz, gzfasten gz lokale compressie-instellingen?
Gebruik de volgende opdracht om het lokale compressiealgoritme te wijzigen dat in een Data Domain wordt gebruikt:
filesys option set compression {none | lz | gzfast | gz}
Opmerking: Het bestandssysteem moet worden afgesloten voordat het lokale compressietype wordt gewijzigd. Het kan dan direct opnieuw worden gestart nadat de compressieoptie is ingesteld.
Over het algemeen is de volgorde van compressie als volgt:
lz < gzfast < gz
| Typ | Verwachte comp. | CPU-belasting |
|---|---|---|
| geen | 1x | 0x |
| Lz | 2x | 1x |
| GZFAST | 2,5x | 2x |
| Gz | 3 x | 5x |
Het ruwe verschil is:
lz to gzfastgeeft ~15% betere compressie en verbruikt 2x CPUlz to gzgeeft ~30% betere compressie en verbruikt 5x CPUgzfast to gzgeeft ~10-15% betere compressie
Houd er rekening mee dat het wijzigen van de lokale compressie eerst van invloed is op nieuwe data die naar het Data Domain worden geschreven nadat de wijziging is aangebracht. De oude data behouden hun vorige compressie-indeling tot de volgende opschooncyclus. De volgende opschooncyclus kopieert alle oude gegevens naar het nieuwe compressieformaat. Dit zorgt ervoor dat het opschonen veel langer duurt en meer CPU in beslag neemt.
Als het systeem al weinig CPU heeft, met name als back-ups en replicatie tegelijkertijd worden uitgevoerd, kan dit de back-ups vertragen en. Het kan zijn dat de klant expliciet wat tijd wil plannen om deze conversie uit te voeren.
Additional Information
Knowledge References:
Affected Products
Data DomainProducts
Data DomainArticle 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.