ZFS : Comparatif RAIDZ1, RAIDZ2, RAIDZ3, dRAID et Mirror — Choisir selon votre usage

Vous avez des disques. Vous devez créer un pool ZFS. Et vous lisez des forums depuis deux heures sans être plus proche d'une décision qu'au départ.

Le problème, c'est que la plupart des guides vous donnent une liste de pros/cons sans vous dire pourquoi ça dépend de votre situation. Un pool pour des VM sur un hyperviseur n'est pas configuré comme un pool d'archivage vidéo. Un pool de 4 disques n'est pas configuré comme un pool de 24 disques.

Ce guide met les chiffres sur la table. Capacité, performance, résilver, coût réel — et vous dit quoi choisir selon ce que vous faites vraiment.

• Linux avec OpenZFS >= 2.1 (obligatoire pour dRAID)
• apt install zfsutils-linux sur Debian/Ubuntu, ou dnf install zfs sur RHEL/Rocky (via le repo ZFS on Linux)
• Connaître les bases : pool, vdev, dataset
• Consulter notre guide d'installation ZFS sous Linux si vous débutez

Avant de comparer les layouts, il y a un concept que la majorité des guides passent sous silence et qui explique 90% des malentendus sur les performances ZFS.

ZFS distribue les écritures entre les vdevs du pool. Le pool n'est pas l'unité de performance — le vdev l'est. Si vous avez un seul vdev RAIDZ2 de 8 disques, vos IOPS aléatoires sont limités par ce seul vdev. Si vous avez 4 vdevs mirror de 2 disques, vous avez 4 fois plus d'IOPS en écriture aléatoire.

Tout le reste découle de ça.

Comment ça marche

Chaque bloc existe en plusieurs copies sur des disques séparés. En lecture, ZFS peut utiliser n'importe quel membre du mirror et répartit la charge entre eux. Chaque mirror est un vdev indépendant — plus vous en avez, plus vous avez d'IOPS.

# 6 disques en 3 mirrors — la config classique pour des VM
zpool create tank mirror sda sdb mirror sdc sdd mirror sde sdf

zpool status tank
# pool: tank
# state: ONLINE
#  scan:  none requested
# config:
#         NAME        STATE     READ WRITE CKSUM
#         tank        ONLINE       0     0     0
#           mirror-0  ONLINE       0     0     0
#             sda     ONLINE       0     0     0
#             sdb     ONLINE       0     0     0
#           mirror-1  ONLINE       0     0     0
#             sdc     ONLINE       0     0     0
#             sdd     ONLINE       0     0     0
#           mirror-2  ONLINE       0     0     0
#             sde     ONLINE       0     0     0
#             sdf     ONLINE       0     0     0

Performances

Les mirrors sont clairement les meilleurs pour du trafic aléatoire. Les lectures se distribuent sur tous les membres, les écritures sont parallélisées sur les paires. Sur un pool de 3 mirrors vous obtenez 3 fois les IOPS d'un disque seul en lecture.

# Benchmark — écriture séquentielle (désactiver le cache ZFS pour mesurer le disque)
zfs set primarycache=none tank
dd if=/dev/zero of=/tank/test bs=1M count=10000 conv=fdatasync
zfs set primarycache=all tank

# Benchmark — lecture aléatoire (plus représentatif des VM et des DB)
fio --name=randread --rw=randread --bs=4k --size=4G --iodepth=32 \
    --filename=/tank/test --runtime=30 --group_reporting

Capacité et coût

Vous perdez exactement 50% de l'espace brut. 6 disques de 4TB = 12TB utilisable. C'est le prix des IOPS.

Résilver

C'est l'autre atout massif du mirror. Quand un disque casse, seul le mirror concerné est touché. Les autres vdevs continuent normalement, sans charge supplémentaire. Le résilver lit depuis le disque survivant et écrit sur le nouveau — simple et rapide. Pas de calcul de parité, pas de lecture sur tous les disques du vdev.

Quand choisir mirror

VM, bases de données, applications nécessitant de bons IOPS en lecture aléatoire. Partout où vous pouvez vous permettre de perdre 50% de capacité brute.

Comment ça marche

Les données et une parité sont distribuées sur tous les disques du vdev. Un disque peut casser sans perte. Deux disques cassent simultanément — tout est perdu.

Pour des stratégies avancées de résilience et de sauvegarde, découvrez notre article sur le tuning ZFS avancé.

# RAIDZ1 avec 4 disques
zpool create tank raidz sda sdb sdc sdd

Capacité

Vous perdez l'équivalent d'un disque. 4 disques de 4TB = 12TB utilisable sur 16TB brut.

Performances

RAIDZ1 excelle en trafic séquentiel — lecture et écriture de gros fichiers. En revanche, pour du trafic aléatoire (petits fichiers, VM), il est nettement plus faible que les mirrors. Un vdev RAIDZ traite les I/O aléatoires moins efficacement car chaque opération implique plusieurs disques du vdev pour les calculs de parité, alors qu'un mirror peut répartir les lectures sur ses membres indépendamment.

La recommandation classique est de limiter les vdevs RAIDZ1 à 3-5 disques si vous avez besoin de bonnes performances en IOPS. Si vous avez 12 disques, faites plusieurs vdevs RAIDZ1 plutôt qu'un seul :

# 12 disques : 4 vdevs RAIDZ1 de 3 disques — bien meilleure performance
zpool create tank \
    raidz sda sdb sdc \
    raidz sdd sde sdf \
    raidz sdg sdh sdi \
    raidz sdj sdk sdl

Le risque

Un seul disque de tolérance. Si un deuxième disque casse pendant le résilver du premier — et sur des disques de grande capacité le résilver peut prendre des jours — vous perdez tout le pool. Dell a officiellement déconseillé RAID5 pour les données critiques pour cette raison exacte. RAIDZ1 a le même problème fondamental.

Comment ça marche

Deux disques de parité. Deux disques peuvent casser simultanément sans perte. Le coût : plus de calcul de parité, un peu plus lent en écriture.

# RAIDZ2 avec 6 disques — config classique
zpool create tank raidz2 sda sdb sdc sdd sde sdf

# 12 disques : 2 vdevs RAIDZ2 de 6 disques pour plus d'IOPS
zpool create tank \
    raidz2 sda sdb sdc sdd sde sdf \
    raidz2 sdg sdh sdi sdj sdk sdl

Capacité

Vous perdez 2 disques en capacité. 6 disques de 4TB = 16TB utilisable sur 24TB brut.

Performances

Les écritures sont plus lentes que RAIDZ1 — la double parité coûte du CPU. Les lectures séquentielles restent correctes. Pour du trafic aléatoire, la même logique s'applique : plus de vdevs, plus d'IOPS.

Résilver

Plus lourd que RAIDZ1. Pendant la reconstruction, chaque stripe à reconstruire nécessite de lire les données depuis les disques survivants. Plus le vdev est large, plus la reconstruction est lente et stressante pour les disques. La taille du vdev est critique — ne dépassez pas 8-10 disques par vdev RAIDZ2.

Quand choisir RAIDZ2

Le bon choix par défaut pour de la production avec des disques HDD. Vous tolèrez 2 pannes, vous gardez une capacité correcte, et avec plusieurs vdevs vous gardez des IOPS acceptables.

Comment ça marche

Trois disques de parité. Trois pannes simultanées tolérées.

# RAIDZ3 — minimum 4 disques (3 parité + 1 donnée), recommandé 7+
zpool create tank raidz3 sda sdb sdc sdd sde sdf sdg sdh sdi

Capacité et performances

Vous perdez 3 disques en capacité. Les écritures sont les plus lentes du lot — le calcul de triple parité est coûteux. Sur 9 disques de 4TB vous avez 24TB utilisable.

Quand choisir RAIDZ3

Les usages sont limités : archivage froid, données réglementaires à conserver longtemps, pools avec beaucoup de disques où vous vous permettez la perte de capacité en échange de la sécurité maximale.

Comment ça marche

dRAID (Distributed RAID) est une variante de RAIDZ introduite dans OpenZFS 2.1, conçue pour les pools de grande taille. La différence fondamentale avec RAIDZ : l'espace de spare est distribué sur tous les disques au lieu d'avoir des disques hot spare dédiés qui restent idle.

Dans un pool RAIDZ classique avec un hot spare, quand un disque casse :

1. Le spare prend le relais
2. Le résilver lit depuis les N-1 disques survivants du vdev
3. Le résilver écrit sur le spare — limité par la vitesse d'un seul disque

Dans dRAID, quand un disque casse :

1. L'espace spare distribué sur tous les disques est utilisé
2. Le résilver lit ET écrit sur tous les disques survivants en parallèle
3. Le temps de résilver est divisé par le nombre de disques

Syntaxe et calcul de capacité

# Format : draid<parité>:<données>d:<spares>s
# Le nombre de disques (children) est déduit automatiquement

# Exemple : 24 disques de 4 TB, dRAID2 avec 8 colonnes de données, 1 spare logique
zpool create tank draid2:8d:1s \
    sda sdb sdc sdd sde sdf sdg sdh sdi sdj sdk sdl \
    sdm sdn sdo sdp sdq sdr sds sdt sdu sdv sdw sdx

Calcul de capacité :

Capacité = (disques - spares) × taille_disque × (données / (données + parité))

Pour l'exemple ci-dessus :

• Brut : 24 × 4 TB = 96 TB
• Espace réservé aux spares : 1 × 4 TB = 4 TB
• Espace données + parité : 92 TB
• Ratio données : 8 / (8 + 2) = 80%
• Capacité utilisable : 92 × 0.8 ≈ 73 TB

Le grand avantage : temps de résilver

Sur un pool RAIDZ2 de 24 disques (4 vdevs de 6), le résilver d'un disque de 4 TB à 100 Mo/s prend environ 11 heures — et pendant ce temps, vous êtes vulnérable à une deuxième panne.

Sur un pool dRAID2 de 24 disques, le résilver distribue la charge sur 23 disques. Le temps est divisé par ~20, soit environ 30 minutes. C'est le cas d'usage principal de dRAID : réduire la fenêtre de vulnérabilité sur les gros pools.

Les inconvénients — et ils comptent

Allocation fixe (fixed stripe width) : dRAID utilise une largeur de stripe fixe définie par le paramètre data. Chaque écriture alloue au minimum un stripe complet. Avec 8d et un recordsize de 128K, l'allocation minimale est de 128K même pour un fichier de 1K. Pour des workloads avec beaucoup de petits fichiers, l'overhead peut être significatif.

Compression moins efficace : la compression s'applique avant la distribution sur le stripe. Avec une largeur fixe, les blocs compressés sont paddés pour remplir le stripe, ce qui réduit le gain réel de compression.

Complexité : dRAID est plus difficile à comprendre, à monitorer et à dépanner que RAIDZ.

# Vérifier l'état d'un pool dRAID
zpool status tank
zpool list -v tank

Quand choisir dRAID

dRAID est pertinent quand :

• Vous avez 20+ disques dans le pool
• Vous utilisez des disques de grande capacité (4 TB+) où le résilver RAIDZ prendrait des heures
• Votre workload est séquentiel (archivage, backup, vidéo) — pas des petits fichiers ou des VM
• Le temps de résilver est critique pour votre SLA

Pour tout le reste, RAIDZ classique reste plus simple et plus efficace.

Consultez aussi notre guide complet sur btrfs vs ZFS pour comparer avec d'autres systèmes de fichiers modernes.

Pour 12 disques de 4 TB (48 TB brut)

Pour 24 disques de 4 TB (96 TB brut)

Note sur les temps de résilver : estimations pour un disque de 4 TB à 100 Mo/s (HDD typique). Le résilver RAIDZ/mirror est limité par la vitesse d'écriture du nouveau disque (~11h pour 4 TB). dRAID distribue les écritures sur tous les disques, réduisant drastiquement ce temps. Les SSD sont 5-10× plus rapides. Le temps réel dépend aussi du taux de remplissage du pool.

ashift : alignement des secteurs

Configurez ashift à la création du pool — c'est irréversible. Les disques modernes (HDD et SSD) utilisent des secteurs de 4K (ashift=12), même s'ils annoncent 512 octets pour compatibilité.

# Forcer ashift=12 (4K) — recommandé pour tout disque récent
zpool create -o ashift=12 tank mirror sda sdb

Un mauvais ashift (9 au lieu de 12) peut diviser vos performances d'écriture aléatoire par 2-4×. Vérifiez après création :

zpool get ashift tank
# ou pour voir tous les vdevs
zdb -C tank | grep ashift

Compression

Activez LZ4 systématiquement. Le coût CPU est négligeable et le gain d'espace est souvent de 20-50% :

zfs set compression=lz4 tank

Scrubs réguliers

C'est le seul moyen de détecter la corruption silencieuse avant qu'elle ne vous coûte :

# Manuellement
zpool scrub tank

# Vérifier si un timer systemd existe (varie selon la distribution)
systemctl list-timers | grep zfs

# Sinon, créer une entrée cron — scrub mensuel le 1er dimanche à 2h
echo "0 2 1-7 * 0 root /sbin/zpool scrub tank" | sudo tee /etc/cron.d/zfs-scrub

RAM pour l'ARC

ZFS utilise la RAM disponible pour le cache ARC. Plus vous en avez, mieux c'est — mais il n'y a pas de minimum strict. ZFS s'adapte à la RAM disponible. La règle "1 Go par To" souvent citée date de l'époque de la déduplication (qui elle, exige beaucoup de RAM). Pour un usage sans dédup, 8-16 Go suffisent pour la plupart des pools.

# État du cache ARC (méthode recommandée)
arc_summary

# Ou lecture directe des stats
awk '/^size |^c_max |^hits |^misses / {print $1, $3}' /proc/spl/kstat/zfs/arcstats

Diversifiez les lots de disques

Les disques d'un même lot (même fabricant, même date de production) ont tendance à tomber en panne en même temps. Mélangez les fabricants et les dates d'achat.

Le layout est permanent

ZFS ne permet pas de changer le type de vdev après création (mirror → RAIDZ, etc.). Vous pouvez ajouter des vdevs au pool, mais pas les modifier. Prenez le temps de bien choisir selon votre cas réel.

Vous avez besoin d'IOPS (VM, bases de données, applications) → Mirror. Vous perdez 50% d'espace, mais vous gagnez en performances et en simplicité de résilver.

Vous avez besoin de capacité avec une bonne fiabilité (NAS, fichiers, production générale) → RAIDZ2. Le meilleur compromis capacité/sécurité pour la plupart des usages.

Vous avez 20+ disques et le temps de résilver est critique → dRAID. Mais seulement pour du stockage séquentiel (archivage, backup). Pour des VM ou des bases de données, restez sur des mirrors.

Vous archivez des données froides avec un maximum de protection → RAIDZ3. Trois pannes tolérées, mais performances limitées.

Le choix n'est jamais universel. Il dépend de votre workload, de votre budget disques, et de votre tolérance au risque pendant un résilver.