ZFS AnyRaid: Endlich Pools aus gemischten Plattengrößen

In OpenZFS hat über zwei Jahrzehnte eine harte Regel gegolten: Innerhalb eines VDEVs zählt nur die kleinste Disk. Wer ein RAIDZ2 aus 4× 12 TB und 2× 18 TB gebaut hat, hatte 6 Disks à 12 TB nutzbare Kapazität — die 12 TB Verschnitt auf den großen Disks waren weg. Diese Regel hat ZFS-Anwender im Mittelstand und im Homelab seit Jahren zu Workarounds gezwungen: separate VDEVs für unterschiedliche Disk-Größen, oder einfach das schlechte Gefühl, viel Platz zu verschenken.

Mit AnyRaid in OpenZFS 2.4 — und damit in TrueNAS 26 “Halfmoon” — ist diese Beschränkung erstmals aufgehoben. Pools können aus Disks unterschiedlicher Größe gebaut werden, und jede Disk gibt ihre gesamte Kapazität in den Pool.

Dieser Artikel erklärt, was AnyRaid technisch ist, wann es passt — und welche Limitierungen man kennen sollte, bevor man eine alte Verschnitt-Topologie damit ersetzen will.

Wie das alte Verhalten aussah

Klassisches ZFS-RAIDZ2-Beispiel: 6 Disks, gemischt aus 12 TB und 18 TB:

Disk 1: 12 TB ━━━━━━━━━━ (volle Nutzung)
Disk 2: 12 TB ━━━━━━━━━━ (volle Nutzung)
Disk 3: 18 TB ━━━━━━━━━━░░░░░ (nur 12 TB, 6 TB Verschnitt)
Disk 4: 18 TB ━━━━━━━━━━░░░░░ (nur 12 TB, 6 TB Verschnitt)
Disk 5: 12 TB ━━━━━━━━━━ (volle Nutzung)
Disk 6: 12 TB ━━━━━━━━━━ (volle Nutzung)

Verschnitt:        12 TB total (zwei Disks à 6 TB)
Nutzbarer Pool:    ~48 TB raw (RAIDZ2: ca. 48 TB nutzbar nach Parity-Abzug bei 6×12 TB)

Der Verschnitt ist nicht trivial — bei wachsenden Disk-Generationen verstärkt sich das Problem. Wer einen 8-Bay-NAS hat und in Jahren von 4 TB über 8 TB auf 16 TB Disks migriert, kann am Ende ein VDEV mit erheblicher “unbenutzter” Kapazität haben — weil die ersten 4-TB-Disks die Obergrenze festsetzten.

Was AnyRaid technisch macht

AnyRaid ändert die Daten-Layout-Logik in ZFS so, dass Parität und Daten nicht mehr starr auf gleicher Disk-Position liegen müssen. Stattdessen werden:

• Daten und Parität in Stripe-Gruppen organisiert, die nicht zwingend alle Disks gleichzeitig nutzen
• Größere Disks halten mehr Stripe-Gruppen als kleinere
• Die Parity-Garantien (RAIDZ1/Z2/Z3) bleiben pro Stripe-Gruppe erhalten

Vereinfacht dargestellt:

AnyRaid mit RAIDZ2 auf 6 Disks (4× 12 TB + 2× 18 TB):

Stripe-Group A (12 TB-Schicht): nutzt alle 6 Disks
Stripe-Group B (6 TB-Schicht):  nutzt nur Disk 3 und 4 (die großen)

  Disk 1: 12 TB ━━━━━━━━━━ (Group A)
  Disk 2: 12 TB ━━━━━━━━━━ (Group A)
  Disk 3: 18 TB ━━━━━━━━━━ ━━━━━ (Group A + Group B)
  Disk 4: 18 TB ━━━━━━━━━━ ━━━━━ (Group A + Group B)
  Disk 5: 12 TB ━━━━━━━━━━ (Group A)
  Disk 6: 12 TB ━━━━━━━━━━ (Group A)

Die zusätzliche 12 TB (2× 6 TB auf Disk 3 und 4) bleiben in Group B nutzbar — allerdings mit anderer Parity-Topologie. Group B ist ein Mirror der beiden großen Disks, weil nur diese zwei Disks Kapazität in dieser Schicht haben.

Wichtige Konsequenz: Das Parity-Verhalten ist über die Stripe-Groups hinweg nicht uniform. Auf den großen Disks gibt es eine Schicht, die nur Mirror-Schutz hat (nicht RAIDZ2). Bei zwei gleichzeitigen Ausfällen genau der beiden großen Disks ist die Group-B-Schicht weg. Die Group-A-Schicht (RAIDZ2 über alle Disks) bleibt aber durch die Z2-Parität geschützt.

Was das in der Praxis bedeutet

Anwendungsfall 1: Homelab mit gemischten Disks

Klassisches Homelab-Szenario: 8-Bay-NAS, über die Jahre mit Disks aus drei Beschaffungs-Runden bestückt. 2× 4 TB, 2× 8 TB, 4× 12 TB. Vor AnyRaid: Wenn alle in einem VDEV stecken, nutzbar sind nur 8× 4 TB = 32 TB raw. Mit AnyRaid: die volle Kapazität jeder Disk wird genutzt — der Pool ist deutlich größer, mit geschichteter Parity-Garantie.

Anwendungsfall 2: Schrittweise Migration auf größere Disks

Klassischer Migrations-Workflow in TrueNAS: Disks einzeln durch größere ersetzen, jeweils einen Resilver laufen lassen. Vor AnyRaid: das VDEV wuchs erst, wenn alle Disks die neue Größe hatten — und der Pool musste explizit “auto-expand” aktiviert haben. Mit AnyRaid: Schon nach der ersten getauschten Disk steht deren zusätzliche Kapazität teilweise zur Verfügung. Die Migration wird linearer.

Anwendungsfall 3: Resilver mit größerer Disk

Vor AnyRaid: Ersatz einer 12-TB-Disk durch eine 16-TB-Disk — die zusätzlichen 4 TB lagen brach, bis alle Disks ausgetauscht waren. Mit AnyRaid: Die größere Disk gibt einen Teil ihrer Kapazität sofort an den Pool, auch wenn die anderen Disks noch klein sind.

Anwendungsfall 4: Hardware-Konsolidierung

Wer zwei alte NAS in einen neuen TrueNAS-Pool konsolidiert, hat oft heterogene Disk-Bestände. AnyRaid macht es realistisch, das ohne Verschnitt zu vereinen — statt nach Disk-Größen-Klassen zu sortieren.

Limitierungen — was AnyRaid nicht löst

Ehrliche Liste:

1. Parity-Asymmetrie über Stripe-Groups Wie oben erläutert: Auf den größeren Disks gibt es Schichten mit anderer Parity-Topologie. Wenn die “größeren” Disks gleichzeitig ausfallen, ist deren exklusive Schicht stärker betroffen. Bei Pools mit nur zwei großen Disks und dem Rest klein ist die obere Schicht effektiv ein Mirror der beiden — also Z1-Schutz-Niveau, nicht Z2.

Empfehlung: Bei AnyRaid-Pools sollten Disks nicht in zu extremen Größenverhältnissen kombiniert werden. Eine Mischung 12 TB / 14 TB ist sauber; 4 TB / 24 TB ist topologisch ungünstig.

2. Performance-Charakteristik Stripe-Groups mit unterschiedlicher Disk-Anzahl haben unterschiedliche I/O-Charakteristika. Schreib-Workloads, die in die “kleinere” Schicht fallen, verhalten sich anders als Workloads in der “größeren” Schicht. Für die meisten KMU-Workloads (Files, Backups, gemischte VM-Last) ist das irrelevant; bei latenz-kritischen Datenbank-Workloads sollte man weiterhin homogene Pool-Topologien bevorzugen.

3. Online-Topology-Change zwischen RAIDZ-Level bleibt offen AnyRaid löst Disk-Größen-Heterogenität. Es löst nicht den Wunsch, von RAIDZ1 auf RAIDZ2 online umzuschalten oder die VDEV-Topologie nach dem Erstellen grundlegend zu ändern. Dieses Feature ist nach wie vor nicht in Sicht.

4. Pool muss mit OpenZFS 2.4 angelegt oder upgegraded werden AnyRaid setzt OpenZFS 2.4 voraus (siehe unseren OpenZFS-2.4-Artikel). Ein klassischer ZFS-Pool, der mit 2.2 oder 2.3 erstellt wurde, kann nicht “halb-AnyRaid” sein — entweder Feature aktiviert oder nicht. Nach Aktivierung kein Rollback auf alte ZFS-Version möglich.

5. Empfehlung bleibt: gleiche Disk-Modelle für Production Trotz AnyRaid: in Produktivumgebungen empfehlen wir weiterhin, gleiche Disk-Modelle einer Charge zu verwenden. Vibrationen, Firmware-Verhalten und Ausfallraten-Statistiken sind in homogenen Pools planbarer. AnyRaid ist ein Werkzeug, kein Aufruf zum Vermischen.

Wann AnyRaid Sinn macht

Szenario	AnyRaid passt
Homelab, gewachsener Disk-Bestand	Ja — sofort spürbarer Kapazitätsgewinn
KMU-NAS, schrittweise Disk-Erneuerung	Ja — Migration wird einfacher
Resilver mit größerer Disk	Ja — kein Warten auf vollständigen Austausch
Backup-Pool aus gespendeten oder aus dem Lager gefischten Disks	Ja — pragmatischer Capacity-Gewinn
Produktive Datenbank-VMs mit höchster Latenz-Anforderung	Eher nein — homogene Pools bleiben sicherer
Compliance-Workload mit dokumentierter Disk-Charge	Eher nein — Audit-Trail klarer mit homogen

Praktisches Beispiel: Migration eines alten Pools auf AnyRaid

Schritt-für-Schritt für einen typischen Mittelstands-NAS-Pool:

1. Pool-Health prüfen: zpool status -v, keine offenen Resilvers oder CKSUM-Fehler
2. Vollbackup verifizieren (siehe 3-2-1-Backup)
3. TrueNAS auf 26 (oder höher) updaten — sobald Halfmoon-Enterprise verfügbar ist
4. Pool importiert sich automatisch, Feature-Flags noch nicht aktiviert
5. Bewusste Entscheidung: AnyRaid-Feature-Flag aktivieren via zpool upgrade <pool> — nach diesem Schritt ist der Pool nicht mehr auf älteren ZFS-Versionen importierbar
6. Neue, größere Disks im Hot-Swap-fähigen Slot einsetzen
7. Resilver-Job starten: Bei AnyRaid wird die zusätzliche Kapazität automatisch in den Pool aufgenommen
8. Scrub nach Resilver abwarten, Pool-Konsistenz bestätigen

Wichtig: Auch mit AnyRaid bleibt mehrtägiger Resilver-Vorgang bei großen HDDs Realität. Wer kürzere Resilver-Zeiten will, sollte parallel über dRAID nachdenken — das ist allerdings eine andere Topologie-Entscheidung.

Zusammenspiel mit anderen ZFS-Features

AnyRaid kombiniert sich mit:

• RAIDZ-Expansion: Erweiterung des VDEVs um zusätzliche Disks geht weiterhin — auch mit unterschiedlicher Größe der neuen Disk
• Special-VDEV (Metadata-Cache auf SSD): bleibt orthogonal — Special-VDEV-Konfiguration ist unabhängig von Daten-VDEV-Heterogenität
• Snapshots und Replikation: vollständig kompatibel — Sender und Empfänger müssen AnyRaid-Feature-Flag verstehen, das setzt 2.4 voraus
• BRT (Block Reference Table): schnelle Klone wirken auch in AnyRaid-Pools — siehe OpenZFS 2.4 Artikel

DATAZONE-Empfehlung

AnyRaid ist eine der unaufgeregtesten und praxisnahesten ZFS-Neuerungen der letzten Jahre. Für unsere Kunden sehen wir drei klare Anwendungsfälle:

• Schrittweise Hardware-Modernisierung: Disk-Erneuerung wird linearer und wirtschaftlicher. Gerade Mittelständler, die nicht alle 24+ Disks gleichzeitig austauschen können, profitieren.
• Homelabs und Test-Pools: gewachsene Disk-Bestände lassen sich endlich sinnvoll konsolidieren
• Backup- und Archiv-Pools: dort wo Performance-Homogenität weniger zählt, ist AnyRaid ein einfacher Kapazitäts-Gewinn

Aber nicht überall: Production-Datenbank-Pools, Mission-Critical-Storage und Setups mit harten SLA-Anforderungen bauen wir weiterhin homogen auf. AnyRaid macht heterogene Pools möglich — es macht sie nicht zur ersten Wahl für jede Topologie.

Wer ein konkretes Pool-Design — neuer Aufbau, Migration, Hardware-Refresh — durchsprechen will, kann uns über Kontakt erreichen. Wir beraten herstellerneutral, auch wenn die richtige Antwort “nichts ändern” ist.

Quellen und weiterführende Artikel

• OpenZFS Release-Notes auf GitHub — offizielle Quelle für AnyRaid-Spezifikation
• OpenZFS-Wiki — AnyRaid Design Document (Stand 2026, siehe ZFS-Dokumentation)
• Unser OpenZFS-2.4-Anwender-Update — Kontext der 2.4-Features
• TrueNAS 26 Halfmoon-Beta — Trägerplattform
• ZFS RAID-Level erklärt — Grundlagen der ZFS-Topologien
• ZFS Komprimierung — weitere Kapazitäts-Hebel
• TrueNAS Hybrid-Storage mit SSD und HDD — kombiniert mit Special-VDEV
• 3-2-1-Backup-Regel — Voraussetzung für jeden Pool-Umbau