Zum Inhalt
Bytearium

Keine Werbung und keine Partnerlinks aktiv

Homelab & Storage

RAID-Z

RAID-Z ist das Paritätsverfahren von ZFS in drei Stufen (raidz1 bis raidz3); es übersteht ein bis drei ausgefallene Platten je vdev.

Dieser Eintrag liegt noch unter unserer Mindestlatte für den Suchindex (Umfang und Zahl der Quellen) und wird überarbeitet. Er ist deshalb nicht in Suchmaschinen gelistet.

RAID 5 hat einen berühmten schlechten Morgen: den Stromausfall mitten im Schreibvorgang. RAID-Z wurde gebaut, damit dieser Morgen ausfällt.

Kurz gesagt

RAID-Z ist die Paritätsanordnung von ZFS. Es gibt drei Stufen, raidz1, raidz2 und raidz3, die pro vdev den Ausfall von einer, zwei oder drei Platten überstehen [1][2]. Anders als RAID 5 und 6 vermeidet es das „Write Hole“, bei dem Daten und Parität nach einem Stromausfall nicht mehr zusammenpassen [1][2][5]. Unsere Einschätzung: Für ein NAS mit mehreren großen Platten ist RAID-Z2 der vernünftige Standard. Zählen Zufallslesezugriffe mehr als Kapazität, passen Spiegel besser. Ein Backup ersetzt keines von beiden.

So funktioniert’s

  1. Stufen und Kapazität. Eine Gruppe aus N Platten der Größe X mit P Paritätsplatten fasst rund (N-P)×X Byte und übersteht P Ausfälle. Das Minimum ist eine Platte mehr als Paritätsplatten; die Dokumentation empfiehlt 3 bis 9 Platten je Gruppe [1][2]. Der vdev-Leitfaden nennt für raidz1 mindestens 2 Platten (ab 3 empfohlen), für raidz2 mindestens 3 (ab 5) und für raidz3 mindestens 4 (ab 7) [3].
  2. Kein Write Hole. Daten und Parität werden über die Gruppe verteilt, aber nicht immer in fester Streifenbreite [1]. Da ZFS Copy-on-Write nutzt, wechselt der Pool in einem atomaren Schritt in einen neuen, konsistenten Zustand. Deshalb gibt es kein Gegenstück zum RAID-5-Write-Hole [5].
  3. Platzbedarf hängt von der Blockgröße ab. Die OpenZFS-Seite zu RAIDZ rechnet ein Beispiel vor: Ein raidz1 mit drei Platten, ashift=12 und 4K-Record nutzt 50 Prozent des Platzes für Daten, mit 128K-Record etwa 66 Prozent. Eine breitere Gruppe ist effizienter [2].
  4. Tempo. Im ungünstigsten Fall schreibt ein RAID-Z-vdev mit den IOPS seiner langsamsten Platte, weil jeder Streifenteil auf jeder Platte ankommen muss. Beim Standard-Record von 128 KiB berührt jeder Lesezugriff alle Datenplatten, die Zufalls-IOPS beim Lesen liegen also etwa auf dem Niveau einer einzelnen Platte. Die Dokumentation ergänzt, dass Spiegel die bessere Wahl bleiben, wenn Zufallslese-IOPS der Engpass sind [2].
  5. Den Pool vergrößern. zpool add hängt ein neues oberstes vdev an, vorhandene Daten werden aber nicht umverteilt [4]. Seit OpenZFS 2.3.0 (veröffentlicht am 14. Jan. 2025) lässt sich ein RAID-Z-vdev auch verbreitern, indem du eine Platte anhängst [6]. Die Erweiterung liest und schreibt alle Daten neu, behält die Redundanz und ändert die Ausfalltoleranz nicht: Ein RAID-Z2 bleibt ein RAID-Z2. Alte Blöcke behalten ihr altes Verhältnis von Daten zu Parität. Der Pool trägt danach das Feature-Flag raidz_expansion, ältere Softwarestände können ihn nicht mehr importieren [4][7].
  6. Kein Zurück. Ein Pool mit irgendeinem obersten RAID-Z-vdev kann nicht schrumpfen. Kein oberstes vdev lässt sich je wieder entfernen, auch nicht eine versehentlich hinzugefügte Platte [4].

Ein Homelab-Beispiel

RAID-Z ist auf keinem Bytearium-System erfasst (Inventar Stand 14. bis 16. Okt. 2026), also rechnen wir allgemein. Sechs 8-TB-Platten im raidz2 fassen grob (6-2)×8 = 32 TB der 48 TB Rohkapazität, vor Abzug des Overheads, und überstehen jeden Ausfall von zwei Platten [1]:

sudo zpool create tank raidz2 /dev/disk/by-id/DISK_1 /dev/disk/by-id/DISK_2 \
  /dev/disk/by-id/DISK_3 /dev/disk/by-id/DISK_4 /dev/disk/by-id/DISK_5 /dev/disk/by-id/DISK_6
sudo zpool attach tank raidz2-0 /dev/disk/by-id/DISK_7   # vdev später verbreitern

Der Typ raidz2 und die Form zpool attach sind die dokumentierte Syntax [1][4]. Beobachte zpool status, solange die Erweiterung läuft [4]. Fällt dabei eine Platte aus, pausiert die Erweiterung, bis das vdev wieder gesund ist [7].

Prüfliste

  • Wähle die Paritätsstufe nach dem Ausfall, den du verkraften kannst: eine, zwei oder drei Platten je vdev.
  • Halte die Gruppe in der empfohlenen Breite von 3 bis 9 Platten [1].
  • Vergleiche Spiegel und RAID-Z für deine Last, bevor du Platten kaufst [2].
  • Führe zpool add -n aus, bevor du etwas zu einem Pool mit RAID-Z-vdev hinzufügst [4].
  • Prüfe, ob deine ZFS-Version raidz_expansion kann, bevor du ein vdev verbreitern willst [6][7].
  • Tausche eine ausgefallene Platte sofort und beobachte, bis der Resilver fertig ist.
  • Lege ein Backup außerhalb des Pools an.

Primärquellen

Diese Quellen sind die Grundlage der Seite. Das heißt nicht, dass jede Aussage einzeln nachgeprüft wurde; ob ein Prüfbeleg vorliegt, steht oben unter „Stand“. Einordnung und Prüfliste sind unsere eigene Arbeit.

Für diese Fassung liegt noch kein dokumentierter Prüfbeleg vor. Der Text stützt sich auf die genannten Quellen.

Entstehung: Bytearium erstellt diese Seiten mit Unterstützung von KI und verantwortet die Veröffentlichung. KI kann sich irren, deshalb nennen wir Quellen und Prüfstand offen.

  1. OpenZFS projectzpoolconcepts.7
  2. OpenZFS projectRAIDZ
  3. OpenZFS projectVDEVs
  4. OpenZFS projectChanging Pool Layout
  5. OpenZFS projectCopy-on-Write
  6. OpenZFS projectzfs-2.3.0
  7. OpenZFS projectraidz expansion feature

Auf dieser Seite gibt es keine Werbung und keine Partnerlinks.