Vor zwei Jahren hat mir ein Bekannter stolz sein neues NAS gezeigt: 4 NVMe-Platten in einem RAID-Z1, 4 Terabyte, alles auf den schnellsten Platten, die der Markt hergibt. Ich habe gefragt, was darauf liegt. Antwort: „Fotos, Filme, die Backups der Familie, und ab und zu eine VM." Ich habe nicht gelacht — ich habe mitgerechnet. Vier NVMe für Daten, die zu 95 Prozent einmal geschrieben und nie wieder gelesen werden. Das ist, als würdest du für den wöchentlichen Einkauf einen Formel-1-Wagen kaufen.

Storage-Tiering bedeutet: Daten dort lagern, wo sie hinpassen. Heiße Daten — Datenbanken, VMs, aktive Projekte — auf NVMe. Warme Daten — Mediathek, Docker-Volumes — auf SSD. Kalte Daten — Backups, Archiv, ungenutzte Dateien — auf HDD oder in die Cloud. Dieser Artikel zeigt die Tier-Pyramide mit echten Zahlen, wie du deine Workloads einordnest, und wie die ZFS-Pool-Architektur aussieht, die ich seit der Migration betreibe.

Warum Tiering? Die nackten Zahlen

Die Entscheidung fällt über zwei Kennzahlen: IOPS und Kosten pro Gigabyte. Wer den Unterschied nicht im Gefühl hat, sollte zuerst den IOPS-Artikel lesen — dort habe ich erklärt, warum Datenblatt-IOPS und Praxis-IOPS weit auseinanderliegen. Hier die Kurzfassung in Zahlen, wie ich sie auf meinem Server gemessen habe:

Tier-Tabelle: HOT NVMe, WARM SATA-SSD, COLD HDD, ARCHIV Cloud — mit IOPS, Latenz, Kosten pro GB und typischem Einsatz

Die Größenordnungen sind das Entscheidende: Eine NVMe leistet 2.500-mal so viele IOPS wie eine HDD, kostet aber das Sieben- bis Achtfache pro Gigabyte. Eine Datenbank, die 5.000 IOPS braucht, ist auf einer HDD hoffnungslos überfordert (die schafft 200) und auf einer NVMe ein Kinderspiel. Eine Mediathek, die sequenziell gelesen wird, kommt mit einer HDD perfekt klar — 200 MB/s reichen für Full-HD-Filme mehrfach. Wer alles auf NVMe legt, bezahlt für 99 Prozent der Daten eine Leistung, die nie abgerufen wird.

Die drei Temperatur-Zonen

Die einfachste Denkweise ist die Temperatur-Metapher:

  • HOT (NVMe): Alles, was bei jedem Zugriff sofort da sein muss. Datenbanken, VM-Disks, Container-Volumes mit aktiven Diensten, laufende Projekte. Zugriffsmuster: random, viele kleine IOs. Diese Daten sind typischerweise klein — 5 bis 20 Prozent deiner Gesamtmenge.
  • WARM (SATA-SSD): Alles, was regelmäßig, aber nicht sekündlich gebraucht wird. Mediathek, Docker-Registry, Snapshots, Home-Verzeichnisse. Zugriffsmuster: gemischt, mittlere Blockgrößen. Meist 20 bis 40 Prozent.
  • COLD (HDD): Alles, was geschrieben und selten gelesen wird. Backups, Archiv, alte Projekte, Original-Fotoarchive. Zugriffsmuster: sequenziell, große Blöcke. Oft die Hälfte deiner Daten oder mehr.

Die Grenzen sind fließend, und das ist gut so: Tiering ist keine Wissenschaft, sondern eine bewusste Entscheidung darüber, wie viel Geld du für wie viel Leistung ausgeben willst.

Die ehrliche Rechnung: All-SSD vs. Tiering

Nehmen wir einen typischen Homeserver: 8 Terabyte Nutzdaten, davon 1 Terabyte aktiv (Datenbank, zwei VMs, laufende Container) und 7 Terabyte kalt (Backups, Fotos, Archiv). Zwei Szenarien:

Szenario A — alles auf SATA-SSD:
2 × 4 TB SATA-SSD  ≈ 440 €
IOPS für die DB:   ~80.000 (mehr als genug)
Ergebnis:          bequem, aber teuer pro TB

Szenario B — Tiering:
1 × 1 TB NVMe      ≈ 110 €   (DB + VMs, hot)
2 × 4 TB HDD       ≈ 240 €   (Archiv, cold)
IOPS für die DB:   ~500.000 (zehnmal mehr als A)
Ergebnis:          günstiger UND schneller für die heißen Daten

Das ist kein Taschenspielertrick, sondern die Logik der Tier-Pyramide: Die NVMe kostet weniger als eine 4-TB-SSD, weil sie kleiner ist. Die HDDs kosten weniger pro Terabyte. Zusammen decken sie beide Welten ab — und die Datenbank, der einzige Teil, der wirklich Performance braucht, bekommt mehr als im All-SSD-Szenario. Genau diese Rechnung habe ich gemacht, bevor ich mein NAS umgebaut habe. Vorher lief die Datenbank auf zwei HDDs und jeder Query dauerte gefühlt eine Ewigkeit. Nachher lag sie auf einer 1-TB-NVMe — und die Migration hat mir den Unterschied zwischen 5.000 und 500.000 IOPS direkt gezeigt.

Wer vorher wissen will, wie viel IOPS ein Workload wirklich braucht, rechnet mit dem bitcalc IOPS-Rechner: Lastprofil eintragen (IOPS, Blockgröße, Lese/Schreib-Verhältnis), und du siehst, ob eine HDD, eine SSD oder eine NVMe reicht. Das hat mir schon mehr als einmal die Entscheidung zwischen „SSD kaufen" und „alles beim Alten lassen" abgenommen.

Die ZFS-Architektur: drei Pools statt einem

Auf meinem Server läuft ZFS — die Grundlagen dazu habe ich im ZFS-Artikel beschrieben. Für Tiering nutze ich drei getrennte Pools, weil ZFS-Pools unterschiedliche Platten nicht mischen sollten (der Pool ist immer so langsam wie die langsamste VDev):

ZFS-Tiering-Architektur: hotpool auf NVMe, warmpool auf SATA-SSD, coldpool auf HDD — mit L2ARC- und SLOG-Hinweisen

Die Verteilung sieht bei mir so aus:

  • hotpool (NVMe): Datenbank, VM-Disks, Container-Volumes. Zwei NVMe im Mirror — die Daten sind klein genug, dass Spiegelung bezahlbar bleibt. ARC (der RAM-Cache von ZFS) fängt zusätzlich die heißen Blöcke ab.
  • warmpool (SATA-SSD): Mediathek, Docker, Snapshots. Zwei SSDs im Mirror, für 5 bis 10 Prozent der Zugriffe mehr als ausreichend.
  • coldpool (HDD): Backups, Fotos, Archiv. Zwei HDDs im RAID-Z1 — Kapazität zählt, Redundanz gegen Einzelausfall reicht.

Die Pool-Layouts habe ich mit dem bitcalc RAID-Rechner durchgerechnet: Nutzkapazität, Rebuild-Zeit und die Frage, ob Mirror oder RAID-Z bei der Plattenzahl die richtige Wahl ist. Gerade bei großen HDDs lohnt sich die Rechnung, bevor man einen Pool baut, der später nicht mehr wächst.

L2ARC und SLOG: die zwei Verstärker mit Warnhinweis

Zwei ZFS-Features werden gern überbewertet — hier die ehrliche Einordnung:

L2ARC ist ein Cache auf schneller Platte (z. B. einer NVMe), der dem kalten Pool heiße Blöcke vorgaukelt. Klingt verlockend, hat aber eine harte Regel: Erst RAM aufstocken, dann L2ARC. L2ARC braucht RAM für seine Index-Strukturen — grob 1/8 bis 1/10 der Cache-Größe — und frisst den ARC an, wenn du nicht genug RAM hast. Auf meinem Server mit 32 GB RAM ist der ARC für den coldpool ausreichend; L2ARC habe ich weggelassen. Wer einen alten Server mit 8 GB RAM hat und über L2ARC nachdenkt: erst auf 16 oder 32 GB RAM gehen, das bringt mehr.

SLOG beschleunigt synchrone Schreibvorgänge (z. B. NFS-Datenbanken, VM-Sync-Writes) durch eine kleine, sehr schnelle Platte mit Power-Loss-Schutz. Wichtig: SLOG ist kein Cache, sondern ein Journal — es hilft nur bei sync writes, und ohne USV oder BBU ist der Gewinn fragwürdig, weil die Platte bei Stromausfall lügen könnte. Wer keine NFS-Sync-Workloads hat, braucht keinen SLOG. Ich habe keinen.

Die Migration: heiß, warm, kalt umziehen

Der Umzug selbst ist unspektakulär, wenn man ihn in Etappen macht. Mein Ablauf:

  1. Inventar: Welche Daten sind wirklich aktiv? Ich habe die Zugriffszeiten der letzten 90 Tage ausgewertet — die Überraschung: 70 Prozent der Dateien wurden in drei Monaten kein einziges Mal angefasst.
  2. Etappe 1 — heiß: Datenbank-Stop, Dump, auf den hotpool legen, Start. Die DB war nach 20 Minuten Ausfallzeit wieder da — und von einer Sekunde auf die andere zehnmal schneller.
  3. Etappe 2 — warm: Docker-Volumes und Mediathek auf den warmpool, per rsync mit --remove-source-files. Kein Ausfall nötig, die Dienste liefen weiter.
  4. Etappe 3 — kalt: Alte Projekte und Backups auf den coldpool. Das ist der größte Haufen, aber auch der unkritischste.
  5. Verifikation: Nach jedem rsync habe ich die Daten mit SHA-256 verglichen — der bitcalc Hash-Generator liefert den Hash, und der Vergleich zwischen Quelle und Ziel hat mir zwei Übertragungsfehler gezeigt, die rsync selbst verschluckt hätte.

Die Verifikation ist der Schritt, den fast alle überspringen — und genau der, der eine Migration von „läuft schon" zu „bewiesen korrekt" macht. Bei 8 Terabyte dauert das Hashing seine Zeit, aber die Gewissheit ist es wert.

Was die Umstellung gebracht hat

Die Zahlen nach drei Monaten Betrieb: Die Datenbank-Abfragen, die vorher 200 bis 800 Millisekunden brauchten, liegen jetzt bei 5 bis 40 Millisekunden. Die VM-Starts dauern statt 90 Sekunden noch 15. Die Mediathek läuft unverändert flüssig — die HDDs waren nie das Problem. Und das Beste: Die Gesamtkosten waren niedriger als das All-SSD-Szenario, das ich vorher geplant hatte. Dafür habe ich eine NVMe, die ich als SLOG hätte verkaufen können — aber nicht brauchte.

Der Bekannte mit dem 4-NVMe-NAS hat übrigens inzwischen umgebaut. Zwei der NVMe sind raus, zwei HDDs drin, und die verbleibenden NVMe beherbergen die VMs. Er hat mir nicht gesagt, dass ich recht hatte. Die Zahlen haben es getan.

Fazit

Storage-Tiering ist keine Enterprise-Komplexität, sondern schlichte Ökonomie: Heiße Daten auf schnelle, teure Platten, kalte Daten auf langsame, günstige Platten. Die Tier-Pyramide mit NVMe, SSD und HDD deckt 95 Prozent der Homeserver ab, ZFS macht die Trennung mit drei Pools sauber, und die Rechnung mit dem bitcalc IOPS-Rechner verhindert, dass du für 99 Prozent deiner Daten Leistung kaufst, die du nie abrufst. Bevor du das nächste Mal „mehr SSD" in den Warenkorb legst: Frag dich zuerst, wie heiß deine Daten wirklich sind.