Automatisches Storage-Tiering mit ZFS: Hot/Cold, Special VDEV und was in der Praxis wirklich funktioniert

“Automatisches Storage-Tiering” steht auf jedem Datenblatt von NetApp, Dell und HPE: Daten wandern selbständig zwischen schnellem Flash und günstigem HDD, der Admin schaut zu. Wer dieselbe Erwartung an TrueNAS oder einen ZFS-Pool unter Proxmox hat, wird enttäuscht. ZFS kennt kein echtes automatisches Tiering im Sinne eines Policy-Engines, der Blöcke zwischen Tiers verschiebt. Was es stattdessen gibt — und was davon im Mittelstandsalltag tatsächlich etwas bringt — klären wir in diesem Beitrag ehrlich.

Der Mythos vom automatischen ZFS-Tiering

Die Vorstellung ist charmant: Ein Pool, drei Tiers (NVMe, SSD, HDD), ZFS verschiebt Blöcke anhand ihrer Zugriffsfrequenz zwischen den Ebenen. In der Realität gibt es diese Funktion in OpenZFS nicht und sie ist auch nicht geplant. Der Grund liegt in der Architektur: ZFS verteilt Writes gleichmäßig über alle VDEVs eines Pools. Ein Mix aus NVMe- und HDD-VDEVs im selben Pool würde Daten zufällig auf beide Typen schreiben — ohne Policy, ohne Rebalancing, mit der Performance des langsamsten VDEVs. Genau das will man nicht.

Was ZFS stattdessen bietet, sind Caching-Schichten (ARC, L2ARC) und spezialisierte VDEVs (Special, SLOG, Dedup) innerhalb eines Pools. Das sind keine Tiers im klassischen Sinn — sie beschleunigen Zugriffe auf heiße Daten oder verlagern spezielle Blocktypen gezielt auf schnelleren Speicher. Für echtes Hot/Cold-Tiering zwischen schnellem und langsamem Pool bleibt nur manuelles Dataset-Tiering mit zfs send | zfs receive.

Diese ehrliche Einordnung ist uns wichtig, bevor wir in die technischen Details gehen. Wer TrueNAS oder Proxmox mit ZFS einsetzt, bekommt kein FabricPool und kein PowerStore AITR — er bekommt etwas Besseres, nur anders.

Was ZFS stattdessen bietet: Caching statt Tiering

ARC: Der RAM-Cache als heimlicher Hot-Tier

Der Adaptive Replacement Cache (ARC) ist auf jedem ZFS-System aktiv und beansprucht standardmäßig bis zu 50 Prozent des RAM. Er cached Metadaten und Datenblöcke in einem Two-List-Algorithmus (MRU + MFU) und liefert auf typischen Mittelstands-Workloads Hit-Ratios zwischen 95 und 99 Prozent. In diesem Sinn ist der RAM der eigentliche Hot-Tier eines ZFS-Pools — und zwar der schnellste, den man überhaupt haben kann. Details zur Dimensionierung behandeln wir im Beitrag ZFS-ARC und L2ARC sauber tunen auf Proxmox-Hosts.

L2ARC: Die Lese-SSD vor den HDDs

L2ARC ist eine SSD als zweite Cache-Stufe. Sie puffert Blöcke, die aus dem ARC gefallen sind, bevor sie wieder von HDD gelesen werden müssten. Für reine HDD-Pools mit großem Working-Set und Read-heavy-Workload kann das viel bringen. Wichtig ist die ehrliche Erwartung: L2ARC ist Read-Only, hilft nicht bei Writes, kostet zusätzlich RAM für die Header-Tabellen (grob 70 bis 90 Byte pro Block) und bringt nichts, wenn der Pool ohnehin schon aus SSDs besteht.

Eine L2ARC-Hit-Ratio unter 20 Prozent ist in der Praxis ein deutliches Signal, die SSD-Slots besser für ein Special VDEV oder einen Mirror zu verwenden. Mehr Hintergrund dazu in unserem Artikel ZFS-ARC und L2ARC Cache-Tuning.

SLOG: Oft verwechselt, keine Tiering-Lösung

Das SLOG (Separate Intent Log) wird regelmäßig mit Tiering verwechselt. Es ist aber kein Cache und auch kein Tier — es beschleunigt ausschließlich synchrone Writes, indem es das ZIL auf eine schnelle, powerloss-protected SSD auslagert. Für den normalen Dateizugriff bringt ein SLOG nichts. Wer das Thema sauber trennen will, findet im Beitrag ZFS SLOG, Special VDEV und Write-Cache in der Praxis die saubere Abgrenzung.

Special VDEV: Metadaten und kleine Blöcke auf SSD

Das Special VDEV ist das, was dem Begriff “automatisches Tiering” bei ZFS am nächsten kommt — und zwar für zwei Blocktypen:

1. Metadaten (Verzeichnisstrukturen, inodes, Checksummen) landen automatisch auf dem Special VDEV, nicht mehr auf den HDDs.
2. Kleine Blöcke bis zu einem konfigurierbaren Schwellwert (special_small_blocks) wandern ebenfalls auf das Special VDEV.

In einem HDD-Pool mit Special-VDEV-Mirror aus zwei Enterprise-SSDs merkt der Nutzer das direkt: ls, find, rsync --dry-run oder SMB-Browsing in großen Verzeichnissen laufen plötzlich spürbar flüssiger, weil Metadaten-Reads nicht mehr auf die HDD-Köpfe warten müssen.

# HDD-Pool mit Special-VDEV-Mirror anlegen
zpool create tank \
  raidz2 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf \
  special mirror /dev/nvme0n1 /dev/nvme1n1

# Kleine Blöcke bis 128K auf Special VDEV ablegen
zfs set special_small_blocks=128K tank/dataset

Vorsicht: Fällt das Special VDEV aus und ist nicht als Mirror ausgelegt, ist der ganze Pool verloren. Special VDEV also immer als Mirror aufsetzen — besser dreifach gespiegelt bei kritischen Daten. Und: Ist das Special VDEV voll, laufen die kleinen Blöcke still und leise wieder auf die HDDs. Monitoring der VDEV-Belegung gehört deshalb zur Grundhygiene.

Praktische Erfahrungen und die Hybrid-Pool-Strategie beschreiben wir ausführlicher im Beitrag TrueNAS Hybrid Storage mit SSD und HDD.

Manuelles Dataset-Tiering: zfs send und receive als Hot/Cold-Workflow

Wer echtes Hot/Cold-Tiering zwischen zwei physisch getrennten Pools braucht, kommt bei ZFS nicht um einen scriptbasierten Workflow herum. Das klingt nach Rückschritt, hat aber einen Vorteil: Es ist transparent, nachvollziehbar und arbeitet mit den gleichen Werkzeugen, die auch für Replikation und Backup verwendet werden. Der Grundgedanke:

• Hot-Pool: NVMe- oder SSD-RAIDZ für aktive Projekte, Datenbanken, laufende VMs.
• Cold-Pool: HDD-RAIDZ2 oder RAIDZ3 für abgeschlossene Projekte, Archive, Backup-Historien.
• Policy: Datasets, deren Inhalt eine definierte Zeit lang nicht mehr verändert wurde, werden per zfs send -R | zfs receive -F auf den Cold-Pool verschoben; danach wird das Quell-Dataset gelöscht und optional ein Symlink gesetzt.

Den kompletten Policy-Rahmen, Beispiel-Scripts und einen cron-basierten Nightly-Job haben wir im Beitrag ZFS Dataset Tiering: Storage automatisch zwischen SSD und HDD verschieben ausführlich dokumentiert. Für die meisten Mittelständler reicht ein Policy-Set für zwei bis vier Datenklassen (aktive Projekte, abgeschlossene Projekte, Backup-Rotation, Archiv) — mehr wird eher Komplexitätskiller als Hilfe.

Wichtig ist die ehrliche Einordnung: Dieser Workflow verschiebt ganze Datasets oder — in granulareren Varianten — ganze Dateien. Er arbeitet nicht block-weise wie ein Enterprise-SAN. Für die typischen Mittelstands-Workloads (Fileserver, Projektlaufwerke, Backup-Repositories) ist das völlig ausreichend; für Hochfrequenz-OLTP-Datenbanken ist es die falsche Lösung — die gehören auf einen reinen SSD-Pool, Punkt.

Wann sich getrennte Pools lohnen — und wann nicht

In Kundenprojekten begegnen uns zwei Grundkonstellationen:

Konstellation A: Ein Hybrid-Pool mit Special VDEV und optional L2ARC Für Fileserver mit gemischten Dateigrößen, SMB/NFS-Workloads und mittlerer Nutzerzahl ist ein einzelner HDD-Pool mit Special-VDEV-Mirror oft die beste Lösung. Keine Datasets verschieben, kein Scripting, einfache Snapshot- und Replikationslogik. Das deckt den Löwenanteil der Mittelständler ab, mit denen wir arbeiten.

Konstellation B: Zwei getrennte Pools (Hot + Cold) mit Dataset-Tiering Für größere TrueNAS-Umgebungen mit klarer Trennung zwischen aktiven und archivierten Daten — etwa in Medienproduktion, Konstruktionsbüros oder bei langen gesetzlichen Aufbewahrungsfristen — rechnet sich der Aufwand. Die aktiven Daten liegen auf dem schnellen Pool, der günstige HDD-Pool nimmt den Großteil der Kapazität auf. Ein TrueNAS-M30- oder M40-System als Hot-Tier und eine zweite TrueNAS-Mini-R oder ein Mini-X+ als Cold-Target ist ein typischer Zuschnitt. Die EOL-Modelle M50 und M60 ersetzen wir im Rahmen eines Upgrades durch die aktuellen M30- bzw. M40-Nachfolger.

Wer sich unsicher ist, welche Konstellation passt, bekommt bei uns im Rahmen des TrueNAS-Konfigurators eine Hardware-Empfehlung inklusive Pool-Layout — und bei komplexen Fällen eine persönliche Beratung über den TrueNAS-Support.

Alternative: Hybrid-Pool mit Special VDEV und L2ARC

Für viele Umgebungen ist der Hybrid-Pool die goldene Mitte. Er kombiniert das, was ZFS wirklich gut automatisch kann:

• HDD-RAIDZ2 als Kapazitätsgrundlage, günstig pro Terabyte.
• Special-VDEV-Mirror aus zwei Enterprise-SSDs für Metadaten und kleine Blöcke.
• L2ARC optional, aber nur wenn ARC-Dimensionierung und Workload-Analyse das rechtfertigen.
• ARC-RAM großzügig dimensioniert, mindestens 1 GB RAM je Terabyte HDD-Netto-Kapazität als Daumenregel.

Diese Kombination verhält sich im Alltag sehr tier-ähnlich: Verzeichnislistings, kleine Dateien, Datenbank-Indizes landen auf SSD-Geschwindigkeit, große Streaming-Workloads laufen über HDDs — ohne dass ein Script jemals Daten verschieben müsste.

Vergleich: ZFS vs. NetApp FabricPool vs. Dell PowerStore AITR

ZFS ersetzt im klassischen Sinn kein Enterprise-SAN mit vollautomatischem Tiering. Es bietet aber mit Special VDEV, Caching-Schichten und einem sauberen Dataset-Tiering-Workflow genug, um in 90 Prozent der Mittelstands-Workloads mit deutlich günstigerer Hardware vergleichbare oder bessere Ergebnisse zu liefern.

Was wir in TrueNAS-Projekten tatsächlich einsetzen

In unseren laufenden TrueNAS-Projekten sieht ein typisches Tiering-Setup so aus:

• Hot-Pool auf TrueNAS M30/M40: NVMe-RAIDZ oder SSD-Mirror für VM-Backing-Store, Datenbanken, aktive Projekte.
• Cold-Pool auf TrueNAS Mini-R oder zweiter M30: HDD-RAIDZ2 mit Special-VDEV-Mirror für Archive, Backup-Historien, abgeschlossene Projekte.
• Replikation: Beide Pools sind über ZFS-Replikation gekoppelt, so dass der Cold-Pool gleichzeitig als DR-Ziel dient.
• Dataset-Tiering: Scripted Nightly Job verschiebt Projekt-Datasets älter als 180 Tage vom Hot- auf den Cold-Pool.
• Monitoring: ARC-Hit-Ratio, Special-VDEV-Belegung und Pool-Fragmentierung werden mit Checkmk überwacht; das Setup ist Teil unseres IT-Service.

Die Hardware-Preisrahmen sind je nach Konfiguration unterschiedlich; aktuelle Konfigurationen kalkulieren wir individuell über den TrueNAS-Konfigurator oder auf Anfrage.

Fazit

ZFS bietet kein automatisches Tiering wie NetApp FabricPool. Es bietet etwas Pragmatischeres: einen sehr guten RAM-Cache, ein Metadaten-Tier über Special VDEV, einen optionalen Lese-Cache über L2ARC und ein manuelles, scriptbasiertes Dataset-Tiering für echtes Hot/Cold. In der Praxis liefert ein sauber ausgelegter Hybrid-Pool mit Special VDEV für den größten Teil der Mittelständler mehr als genug. Erst bei großen, klar separierten Datenlebenszyklen rechnen sich zwei getrennte Pools und ein Tiering-Workflow.

Wer sein ZFS-Setup auf diese Realität statt auf Marketing-Erwartungen auslegt, bekommt stabilen, nachvollziehbaren und ehrlich günstigen Storage. Alles andere ist Wunschdenken.

Häufig gestellte Fragen

Kann ich ZFS so konfigurieren, dass Daten automatisch von SSD auf HDD wandern, ohne Script?

Nein. OpenZFS kennt keine Policy-Engine für blockweises Tiering zwischen Pools. Was innerhalb eines Pools automatisch läuft, ist das Special VDEV (Metadaten, kleine Blöcke) und der ARC/L2ARC-Cache. Für echtes Dataset-Tiering zwischen zwei Pools brauchen Sie einen cron-gesteuerten zfs send-Workflow.

Lohnt sich ein L2ARC zusätzlich zum Special VDEV?

Nicht pauschal. Das Special VDEV hält Metadaten und kleine Blöcke auf SSD-Geschwindigkeit — das deckt bereits einen Großteil der latenzkritischen Zugriffe ab. Ein zusätzlicher L2ARC lohnt sich nur, wenn das Working-Set deutlich größer als der RAM ist, die Workload read-heavy ist und die L2ARC-Hit-Ratio über 30 Prozent liegt. In vielen Mittelstands-Setups ist mehr RAM die bessere Investition als eine L2ARC-SSD.

Was passiert, wenn das Special VDEV voll läuft?

ZFS schreibt neue Metadaten und kleine Blöcke dann wieder auf die HDDs. Es gibt keinen Fehler, aber die gefühlte Performance fällt zurück auf HDD-Niveau. Deshalb Special-VDEV-Belegung aktiv monitoren und bei 70 bis 80 Prozent Füllstand eine Erweiterung oder einen Austausch planen.

Welche TrueNAS-Modelle eignen sich als Hot- und Cold-Pool?

Als aktueller Hot-Tier empfehlen wir TrueNAS M30 oder M40, je nach Kapazitäts- und Performance-Anforderung. Als Cold-Tier eignet sich eine TrueNAS Mini-R oder ein zweites M30-System mit großen HDDs und Special-VDEV-Mirror. Die früheren Modelle M50 und M60 sind End-of-Life und werden im Rahmen von Upgrades durch die aktuellen Modelle abgelöst.

Welche TrueNAS-Version sollte ich für ein Tiering-Setup einsetzen?

Produktiv setzen wir aktuell auf TrueNAS 25.10 Goldeye, das die derzeit stabile Linie ist. TrueNAS 27 erreicht nach aktueller Planung Anfang Dezember 2026 GA; wir empfehlen, Produktivsysteme erst nach einer eigenen Validierungsphase umzustellen und nicht direkt auf die GA-Woche. Details zur Namensänderung und Roadmap haben wir im Beitrag zu TrueNAS 27 zusammengefasst.

Was kostet eine Hot/Cold-Konfiguration bei DATAZONE?

Preise für TrueNAS-Hardware schwanken aktuell stark (Flash-Markt, HDD-Kapazitäten, DRAM-Preise). Wir kalkulieren jede Konfiguration individuell im TrueNAS-Konfigurator oder auf Anfrage. Als Richtwert: Ein Hybrid-Pool mit Special VDEV ist deutlich günstiger als zwei getrennte Pools mit Replikation und Dataset-Tiering — und reicht für die meisten Mittelständler aus.

Sie planen ein Hot/Cold-Setup oder sind unsicher, ob Special VDEV, L2ARC oder getrennte Pools für Sie die richtige Wahl sind? Sprechen Sie uns an — der TrueNAS-Support von DATAZONE begleitet Sie als autorisierter iXsystems-Partner von der Planung bis zum laufenden Betrieb.