ZFS: Mirror oder RAID-Z? Den Pool planen

Ein ZFS-Layout zu wählen ist wie die Sitzplatzwahl im Langstreckenflug: Wechseln geht später noch, macht aber keinem Spaß. Zehn Minuten Planung jetzt sparen dir ein Wochenende Wiederaufbau.

Kurz gesagt

ZFS Mirror oder RAID-Z bei einem Pool aus 2 bis 6 Platten? Bei zwei Platten nimmst du einen Mirror. Bei mehr Platten kommt es auf die Last an. Nimm Mirrors, wenn zufällige Lese- und Schreibzugriffe überwiegen (virtuelle Maschinen, Datenbanken) oder wenn du den Pool jeweils um zwei Platten erweitern willst. Nimm RAID-Z2, wenn der Pool vor allem große Dateien wie Medien und Backups hält und beliebige zwei Platten ausfallen dürfen sollen. RAID-Z1 ist die Sparvariante für Daten, die du ersetzen kannst oder die schon ein zweites Mal vorliegen. Egal, was du wählst: RAID ist kein Backup.

So funktioniert’s

1. Die Begriffe, auf die es ankommt: Pool, Vdev, Redundanz. Ein ZFS-Pool besteht aus Top-Level-Vdevs (virtuellen Geräten). Ein Vdev ist eine einzelne Platte, ein Mirror (Spiegel) oder eine RAID-Z-Gruppe [2]. Der Pool verteilt die Daten über alle seine Top-Level-Vdevs [2][4]. Redundanz steckt innerhalb eines Vdevs, nicht zwischen Vdevs: Verlierst du ein Top-Level-Vdev, ist der Pool weg [2]. „Zwei Mirrors“ heißt also ein Pool mit zwei Vdevs, „ein RAID-Z2 aus sechs Platten“ ein Pool mit einem.
2. Mirror-Rechnung. Ein Mirror aus N Platten der Größe X fasst X Byte und übersteht den Ausfall von N-1 Platten [4]. Ein Zweifach-Mirror gibt dir die Hälfte der Rohkapazität und übersteht einen Ausfall.
3. RAID-Z-Rechnung. Eine RAID-Z-Gruppe aus N Platten der Größe X mit P Paritätsplatten fasst ungefähr (N-P) x X Byte und übersteht P Ausfälle [3][4]. RAID-Z1, Z2 und Z3 stehen für eine, zwei oder drei Paritätsplatten [3]. Das Minimum ist ein Gerät mehr als Paritätsplatten, und OpenZFS empfiehlt 3 bis 9 Geräte je Gruppe [3]. Die Seite zu VDEVs nennt mindestens 2, 3 und 4 Platten für Z1, Z2 und Z3, empfohlen sind 3, 5 und 7 oder mehr [2]. „Ungefähr“ ist hier ernst gemeint: Bei kleinen Records verliert RAID-Z Platz an Padding und Parität, und bei Records, die nicht größer als die Sektorgröße sind, entspricht der Paritätsaufwand dem eines Mirrors [3]. Die Pool-Werte, die zpool ausgibt, gehen von festen 128-KiB-Records aus und sind eine Faustformel, kein exaktes Maß [13]. Die Tabelle weiter unten ist unsere eigene Rechnung nach diesen Formeln, vor Padding und Metadaten, für gleich große Platten.
4. Tempo: was das Layout ändert. In einem RAID-Z-Vdev berührt jeder Schreibzugriff alle Platten des Stripes, im schlechtesten Fall bestimmt also die Platte mit den wenigsten Schreib-IOPS (Operationen pro Sekunde) das Tempo [3]. Bei den üblichen 128-KiB-Records erstreckt sich ein Block meist über alle Datenplatten. Jeder Lesezugriff kostet dann eine I/O auf jeder davon, und die Zufallslese-IOPS liegen grob bei einer Platte je Vdev. Die Streaming-Bandbreite wächst trotzdem mit der Zahl der Datenplatten [3]. Die OpenZFS-Seite sagt, dass Mirrors die bessere Wahl bleiben, wenn die Zufallslese-IOPS der Engpass sind [3]. Kleine Blöcke sind auf RAID-Z außerdem teuer: Bei Zvols (Blockgeräte, die ZFS bereitstellt, etwa als Platten für virtuelle Maschinen) lässt eine kleine volblocksize die Platzeffizienz von RAID-Z in Richtung Mirror-Aufwand einbrechen [15]. Unsere Lesart: Für große Mediendateien passt RAID-Z gut, für Platten virtueller Maschinen sind Mirrors die einfachere Antwort.
5. Ausfall und Wiederaufbau. Fällt eine Platte aus, liefert ZFS die Daten weiter aus den übrigen Platten desselben Vdevs, und nach dem Austausch baut es die neue Platte per Resilver wieder auf [2]. Bis das fertig ist, hat das Vdev weniger Redundanz: Ein degradiertes RAID-Z1 oder ein Zweifach-Mirror hat keine mehr. Kann ZFS einen Block nicht rekonstruieren, listet zpool status -v die beschädigte Datei, und du stellst sie aus einem Backup oder Snapshot wieder her [10][11]. zpool replace -s und zpool attach -s bauen sequenziell auf und stellen die Redundanz schneller wieder her. Danach läuft automatisch ein Scrub, weil beim Aufbau keine Prüfsummen geprüft werden. Sequenzielle Rekonstruktion wird für RAID-Z nicht unterstützt [10]. Ein Guide von 2026 beschreibt den praktischen Unterschied so: Ein Mirror-Aufbau liest eine überlebende Platte, ein RAID-Z-Aufbau liest alle Überlebenden [17]. Größere Platten verlängern das Zeitfenster. Deshalb raten beide Guides, die wir gelesen haben, bei großen Platten von RAID-Z1 für unersetzliche Daten ab [16][17]. Wir sehen das genauso, aber das ist eine Risikoeinschätzung und kein Naturgesetz.

Die Zahlen für 2 bis 6 Platten

Die Mirror-Zeilen verstecken eine Falle. Ein Pool aus zwei Mirrors übersteht zwei Ausfälle nur, wenn sie verschiedene Mirrors treffen [16]. Von den 6 möglichen Paaren ausgefallener Platten in einem Vier-Platten-Pool aus 2 x 2 sind 2 tödlich [16]. Bei drei Mirrors aus je zwei Platten sind 3 von 15 Paaren tödlich (unsere Zählung). RAID-Z2 hat kein tödliches Paar, weil beliebige zwei Platten ausfallen dürfen.

Den Pool später erweitern

Es gibt drei Wege, und sie unterscheiden sich stark.

• Größere Platten. Tausche die Platten eines Vdevs nacheinander gegen größere und warte jeweils den Resilver ab. Der neue Platz erscheint erst, wenn jede Platte dieser Mirror- oder RAID-Z-Gruppe ersetzt ist. Setze autoexpand=on oder führe zpool online -e aus [1][13].
• Ein weiteres Vdev. zpool add hängt ein neues Top-Level-Vdev an. Es bekommt sofort neue Schreibzugriffe, vorhandene Daten werden aber nicht umverteilt. Gib ihm dieselbe Redundanz wie den anderen, sieh dir das Ergebnis mit zpool add -n vorab an und überlege zweimal, bevor du mit -f erzwingst, denn das kann den ganzen Pool von einer einzigen Platte abhängig machen [1]. Enthält ein Pool irgendein RAID-Z- oder dRAID-Top-Level-Vdev, lässt sich nie wieder ein Top-Level-Vdev entfernen; die einzige Lösung ist, den Pool neu anzulegen und die Daten zurückzuspielen [1].
• RAID-Z-Erweiterung. zpool attach pool raidz2-0 neueplatte macht ein bestehendes RAID-Z-Vdev um eine Platte breiter [1][5]. Die Funktion kam mit OpenZFS 2.3.0, veröffentlicht am 14. Jan. 2025 [8]. Versionsbeleg: In der Feature-Flag-Tabelle von OpenZFS, abgerufen am 25. Okt. 2026, steht raidz_expansion für 2.3.9, 2.4.4 und master, nicht aber für 2.2.11 [7]. Das Pool-Feature ist nicht schreibgeschützt kompatibel [6], und laut dem Pull Request, der es eingeführt hat, bleibt das Feature für die Lebenszeit des Pools aktiv, sodass ältere Versionen einen Pool mit erweitertem Vdev nicht importieren können [9]. Bei der Erweiterung liest ZFS alle belegten Daten und schreibt sie über die breitere Gruppe neu. Der Pool bleibt online, die Erweiterung pausiert bei einem Plattenausfall, und am Ende startet ein Scrub [5][9]. Die Ausfallsicherheit ändert sich nicht: Ein RAID-Z2 bleibt ein RAID-Z2. Alte Blöcke behalten ihr altes Verhältnis von Daten zu Parität, deshalb kann der gemeldete freie Platz etwas zu knapp wirken [5]. Die aktuelle Manpage verweist für das Neuschreiben alter Blöcke auf zfs-rewrite(8); prüfe, ob deine Version das mitbringt [5]. Die neue Platte muss mindestens so groß sein wie die kleinste vorhandene [5]. Manche Guides von 2026 nennen die Erweiterung noch „very limited“ [17]. Die OpenZFS-Seiten beschreiben Ablauf und Grenzen, ohne sie als experimentell zu bezeichnen. Läuft auf deinem System ein älteres ZFS, geh davon aus, dass du nicht erweitern kannst, und prüfe das mit zpool version [18].

Was das Layout nicht löst

• Backups. Redundanz deckt eine kaputte Platte ab. Sie deckt keinen gelöschten Ordner, keine Ransomware, kein versehentliches zpool destroy und keinen Brand ab. Snapshots liegen im selben Pool und teilen sein Schicksal. Unsere Artikel zum 3-2-1-Backup und zu restic und Borg findest du unter „Passt dazu“.
• Controller. OpenZFS rät von Hardware-RAID-Controllern ab, auch von einzelnen Platten als RAID 0. Nimm einen HBA (Host-Bus-Adapter), der die rohen Platten an ZFS durchreicht [11].
• Arbeitsspeicher. OpenZFS empfiehlt ECC-Speicher für den Unternehmenseinsatz ausdrücklich und sagt, dass Heimanwender Kosten und Schutz selbst abwägen müssen [12].
• Sektorgröße. ashift legt beim Anlegen die Sektorgröße fest. Der Standardwert 0 erkennt sie automatisch, ein üblicher manueller Wert ist ashift=12 für 4-KiB-Sektoren, und eine spätere Änderung der Pool-Eigenschaft ändert ein bestehendes Vdev nicht [13]. Bei RAID-Z kann ashift=12 die Kapazität senken [12].
• Plattengrößen. zpool create meldet unterschiedlich große Platten in einer Mirror- oder RAID-Z-Gruppe als Fehler, solange du es nicht erzwingst [14]. Die kleinste Platte bestimmt die Größe [16]. Welche Platten du kaufst, ist eine eigene Frage, die unser Artikel zur NAS-Festplattenwahl behandelt.
• Scrubs. Ein Scrub liest jeden Block und repariert Schäden, wo die Redundanz es erlaubt. Monatlich ist ein gängiger Ausgangswert für Consumer-Platten [10].

Auswahl nach Plattenzahl

Dieser Teil ist unsere Einschätzung, gestützt auf die Dokumentation oben und die beiden Guides von 2026 [16][17].

• 2 Platten: ein Mirror. RAID-Z1 ginge mit zwei Platten auch, bringt aber nur die Kapazität eines Mirrors und keinen Vorteil [2].
• 3 Platten: RAID-Z1, wenn die Daten ersetzbar oder gesichert sind, oder ein Dreifach-Mirror, wenn du lieber zwei überstehbare Ausfälle bei einem Drittel der Kapazität willst.
• 4 Platten: die klassische Weggabelung. Zwei Mirrors für gemischte oder zufällige Last und Wachstum in Paaren. RAID-Z2 für Medien, Backups und große Dateien, bei denen „beliebige zwei Platten“ wichtiger ist als Tempo.
• 5 Platten: RAID-Z2 (60 %). Mirrors brauchen eine gerade Zahl an Platten, eine fünfte würde als Ersatz brachliegen.
• 6 Platten: RAID-Z2 (rund 67 %) für Massendaten, drei Mirrors für zufällige I/O.
• Mehr als 6 Platten: überlege zwei Gruppen statt einer breiten. OpenZFS empfiehlt 3 bis 9 Geräte je RAID-Z-Gruppe [3].

Ein Planungsbeispiel

Das ist ein Rahmen für deine eigene Entscheidung, kein Bericht über unsere Systeme. Zu unserem Homelab ist für diesen Artikel nur dokumentiert: Es gibt ein QNAP-NAS (Stand 14. bis 18. Okt. 2026). Zu seinem Dateisystem und seinem Pool-Layout machen wir keine Aussage.

Nimm vier gleich große Platten für einen Pool mit Medien und Backups. Erkenne die Platten zuerst an stabilen Namen statt an sda, sdb:

ls -l /dev/disk/by-id/ | grep -v part

Sieh dir dann beide Layouts vorab an. Die Option -n zeigt das Layout und legt nichts an [14]. Setze ashift=12 nur, wenn deine Platten wirklich 4-KiB-Sektoren nutzen; sonst lass den Standard [13].

sudo zpool create -n -o ashift=12 tank \
  mirror /dev/disk/by-id/DISK_A /dev/disk/by-id/DISK_B \
  mirror /dev/disk/by-id/DISK_C /dev/disk/by-id/DISK_D

sudo zpool create -n -o ashift=12 tank raidz2 \
  /dev/disk/by-id/DISK_A /dev/disk/by-id/DISK_B \
  /dev/disk/by-id/DISK_C /dev/disk/by-id/DISK_D

Prüfe nach dem echten Anlegen den Pool und starte einen ersten Scrub. Hast du RAID-Z gewählt und willst später verbreitern, prüfe Version und Feature, bevor du damit planst, hänge dann die neue Platte an und beobachte den Fortschritt [5]:

zpool status tank
sudo zpool scrub tank
zpool version
zpool get feature@raidz_expansion tank
sudo zpool attach tank raidz2-0 /dev/disk/by-id/DISK_E
zpool status tank

Ein neuer Pool aktiviert standardmäßig alle unterstützten Features. Musst du ihn auf älteren Versionen importieren können, schränke die Features beim Anlegen mit -o compatibility= ein [14]. Eine ausgefallene Platte tauschst du später so: sudo zpool replace tank /dev/disk/by-id/DISK_ALT /dev/disk/by-id/DISK_NEU [1]. Probiere das einmal an einem Pool aus, auf dem noch nichts Wichtiges liegt.

Prüfliste

• Notiere, ob dieser Pool die einzige Kopie deiner Daten hält, und plane das Backup vor dem Layout.
• Lege zuerst die Last fest: Zufalls-I/O und virtuelle Maschinen sprechen für Mirrors, große Dateien und Backups für RAID-Z2.
• Prüfe deine ZFS-Version mit zpool version, bevor du auf die RAID-Z-Erweiterung baust.
• Liste die Platten über /dev/disk/by-id auf und sieh dir das Layout mit zpool create -n an, bevor du den echten Befehl absetzt.
• Vergleiche die genaue Kapazität jeder Platte einer Gruppe, denn die kleinste bestimmt die Größe.
• Wähle einen HBA oder die SATA-Ports des Mainboards und vermeide einen RAID-Controller vor den Platten.
• Plane den nächsten Wachstumsschritt jetzt: Plattenpaare, größere Platten oder eine breitere RAID-Z-Gruppe.
• Prüfe, ob dein System schon einen Scrub-Timer hat, und rufe nach dem ersten Scrub zpool status auf.
• Übe einen Plattentausch an einem Testpool und stelle eine Datei aus deinem Backup wieder her.