# Deduplication Storage Pools: Architektur für hocheffiziente Backups

TL;DR / Management Summary Ein Deduplication Storage Pool ist ein spezialisiertes Speicher-Backend, das für die Verwaltung von Milliarden kleiner Datenblöcke (Chunks) optimiert ist. Während Standard-Dateisysteme bei hohen Deduplikationsraten oft einbrechen, nutzen wir für Backup-Pools gezielte Hardware-Architekturen: SSDs für Metadaten (Hash-Tabellen) und kapazitätsstarke HDDs für die eigentlichen Daten. Ein Senior Admin nutzt ZFS oder spezialisierte Backup-Appliances (wie PBS), um Speicherersparnisse von bis zu 95% zu realisieren, ohne die Lese-Performance (Restore) zu opfern.

# 1. Einführung & Architektur

Metadaten sind alles.

In einem Deduplikations-Pool ist die Suche nach dem Block (“Habe ich diesen Hash schon?”) die kritischste Operation.

# 2. Hardware-Design eines Backup-Pools

Die ‘Must-Have’ Komponenten.

# 1. Capacity Tier (HDDs)

Große SAS oder SATA Platten im RAIDZ2 (ZFS) für die eigentlichen Chunks.

# 2. Metadata Tier (SSD / NVMe) - Kritisch!

Ein dediziertes, schnelles Laufwerk (Special Device in ZFS), das ausschließlich die Hash-Tabellen und Dateisystem-Metadaten speichert.

# 3. RAM (Memory)

Die Hash-Tabelle sollte im Idealfall komplett im Arbeitsspeicher liegen.

# 3. Deep Dive: ZFS Special Devices

Der Turbo für Backup-Server.

Seit ZFS 0.8 / OpenZFS 2.0 können wir SSDs als “Special Allocation Classes” hinzufügen.

# Einen Pool erstellen mit HDDs für Daten und SSDs für Metadaten
zpool create backup_pool \
    raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd \
    special mirror /dev/nvme0n1 /dev/nvme1n1

# 4. Day-2 Operations: Fragmentierungs-Management

Die Schattenseite der Deduplikation.

Deduplikation führt zwangsläufig zu Block-Fragmentierung. Ein Restore muss Blöcke von überall auf der Disk zusammensuchen.

# 5. Troubleshooting & “War Stories”

Wenn der Pool in die Knie geht.

# Top 3 Fehlerbilder

  1. Symptom: Schreibgeschwindigkeit sinkt nach 50% Pool-Füllung auf 10 MB/s.

    • Ursache: Die DDT (Hash-Tabelle) passt nicht mehr in den RAM und muss von der Disk geladen werden.
    • Lösung: Mehr RAM hinzufügen oder L2ARC auf NVMe-Basis nachrüsten.

  2. Symptom: “Out of Memory” Panics des Kernels.

    • Lösung: RAM-Limit für den ARC Cache explizit setzen, damit das OS noch atmen kann.

  3. Symptom: Pool lässt sich nicht mehr importieren.

    • Lösung: Nutzen Sie zpool import -F (Recovery), aber seien Sie sich bewusst, dass Datenverlust möglich ist.

# “War Story”: Der “Billig-SSD” Fail

Ein Admin baute einen Backup-Pool mit 20 TB HDDs und einer billigen Consumer-SATA-SSD als Metadata-VDev. Das Ergebnis: Nach 3 Monaten intensiver Backups gab die SSD auf (Write Endurance überschritten). Da das Special-Device nicht gespiegelt war, war der gesamte 20 TB Pool schlagartig Elektroschrott. Lehre: Nutzen Sie für Metadata-Devices immer Enterprise-SSDs mit hohem DWPD-Wert (Drive Writes Per Day) und betreiben Sie diese immer im Mirror.

# 6. Monitoring & Reporting

Die Pool-Statistik.

# ZFS Statistics (CLI)

# Zeigt die Ausnutzung der DDT (Hash Tabelle)
zpool status -D backup_pool

Achten Sie auf die DDT size. Wenn diese den verfügbaren RAM übersteigt, müssen Sie handeln.

# 7. Fazit & Empfehlung

Ein Deduplication Pool ist eine hochspezialisierte Maschine.

# Anhang: Cheatsheet

Aufgabe Befehl
Pool Status zpool status -v
I/O pro VDev zpool iostat -v 5
Metadaten Quote zfs set special_small_blocks=64K pool/dataset
DDT Histogram zdb -D poolname

# Referenzen