Btrfs ou ZFS — vos données survivront à un crash disque, mais seulement avec le bon filesystem

22 avril 2026. Le kernel Linux 7.1 est sorti il y a trois semaines. OpenZFS 2.4.2 est la version stable la plus récente, et la série 2.4.0 (mars 2025) a apporté les plus grosses évolutions de la décennie. Et la question que tout administrateur finit par se poser n’a pas changé depuis dix ans : Btrfs ou ZFS ?

La réponse n’est pas une question de préférence. Elle dépend de ce que vous protégez, et de ce que vous êtes prêt à perdre.

Deux philosophies, un même objectif

Btrfs et ZFS sont tous deux des filesystems copy-on-write (COW) avec snapshots, compression, checksumming et RAID logiciel intégré. Leur promesse est identique : vos données ne seront jamais corrompues silencieusement.

Mais ils arrivent à ce résultat par deux chemins radicalement différents.

Btrfs vit dans le kernel Linux depuis 2009. Il est maintenu par les développeurs du kernel, évolue avec chaque release, et ne nécessite aucun module externe. C’est le filesystem par défaut de Fedora depuis la version 33 et de SUSE Linux Enterprise depuis la 15. Il est supporté nativement par systemd, les bootloaders modernes et l’écosystème Linux dans son ensemble.

OpenZFS, lui, est un projet séparé né du portage de ZFS — le filesystem historique de Sun Solaris — vers Linux et FreeBSD. Sa licence CDDL est incompatible avec la GPL du kernel Linux : OpenZFS ne sera jamais intégré à mainline. Il doit être compilé en module externe (DKMS) et suit les versions du kernel avec un délai de quelques semaines. La version 2.4.2 supporte les kernels 4.18 à 7.0, et la 2.4.0 (mars 2025) a apporté trois fonctionnalités majeures : Fast Dedup, Direct I/O et l’expansion RAID-Z en ligne — ajouter un disque à un vdev RAID-Z existant sans le recréer.

La différence qui tue : la maturité du RAID

C’est ici que tout se joue.

Btrfs RAID1, RAID1C3, RAID1C4 et RAID10 sont stables et annotés OK dans la matrice officielle de maturité (kernel 7.1). Le scrub, le remplacement de disque et le montage dégradé fonctionnent.

Btrfs RAID5/RAID6 reste instable. La documentation officielle le classe toujours unstable en avril 2026 — le write hole (corruption silencieuse après une coupure de courant sur de la parité) n’est pas résolu. Le man 5 btrfs le dit sans ambigüité : « RAID56 provides no safeguards against the RAID5 write hole. You should not use RAID56 for anything but testing with throw-away data. »

Ce n’est pas un bug en cours de correction. C’est un problème architectural identifié depuis 2016.

ZFS RAID-Z (RAID-Z1, Z2, Z3) est mature depuis plus de quinze ans. Pas de write hole. Pas de corruption silencieuse sur coupure de courant. Les données et la parité sont toujours cohérentes grâce au modèle transactionnel COW de ZFS. Et depuis OpenZFS 2.4.0, vous pouvez ajouter un disque à un vdev RAID-Z existant — une fonctionnalité que même le ZFS d’Oracle n’a jamais eue.

Pour un NAS ou un serveur de stockage, c’est sans appel : ZFS est le seul choix fiable si vous utilisez de la parité.

RAM, cache et performance

ZFS a besoin de RAM. Son ARC (Adaptive Replacement Cache) est le cœur de ses performances : il met en cache les blocs les plus lus et les plus récents en mémoire. La recommandation officielle est 8 Go minimum, et bien davantage si vous activez la déduplication — chaque bloc dédupliqué consomme environ 320 octets de RAM dans la table DDT (Dedup Table). La nouvelle fonctionnalité Fast Dedup (2.4.0) réduit cette empreinte en journalisant les entrées, mais ne l’élimine pas.

Btrfs utilise le page cache standard de Linux. Pas de cache dédié, pas de consommation mémoire disproportionnée. Un desktop avec 4 Go de RAM fait tourner Btrfs sans sourciller. La compression zstd (niveau 3 par défaut) est rapide et efficace — souvent plus rapide que l’écriture non compressée sur SSD.

Sur un desktop, Btrfs est clairement le bon choix : léger, intégré, sans surprise au prochain apt upgrade. Sur un serveur avec 32 Go de RAM, l’ARC de ZFS exploite cette mémoire pour des performances de lecture exceptionnelles — c’est un avantage, pas un gaspillage.

Chiffrement natif

ZFS embarque le chiffrement natif (AES-256-GCM) au niveau du dataset. Vous pouvez chiffrer tank/documents sans toucher à tank/media. Les snapshots chiffrés restent chiffrés, même envoyés via zfs send. C’est intégré, testé, et ça ne dépend pas de LUKS.

Btrfs n’a pas de chiffrement. Vous devez utiliser LUKS/dm-crypt en dessous. Ça fonctionne, mais vous chiffrez le bloc device entier — pas de granularité par subvolume. Si vous voulez déverrouiller un subvolume spécifique au démarrage sans exposer les autres, vous ne pouvez pas.

Pour un laptop ou un serveur contenant des données sensibles, ZFS marque un point net.

Snapshots et rollback : l’avantage Btrfs

Btrfs a une ergonomie de snapshot que ZFS envie. Avec des outils comme Snapper, Timeshift ou btrbk, vous configurez des snapshots horaires automatiques, vous pouvez booter sur un snapshot précédent directement depuis GRUB, et le rollback est trivial :

# Snapshot avant une mise à jour
btrfs subvolume snapshot /mnt/@root /mnt/@root-pre-upgrade

# Rollback si ça casse
btrfs subvolume delete /mnt/@root
mv /mnt/@root-pre-upgrade /mnt/@root

Sur openSUSE et Fedora, cette intégration est native : chaque transaction zypper ou dnf déclenche un snapshot automatique. Si la mise à jour casse le système, vous rebootez sur le snapshot précédent. C’est la raison numéro un d’utiliser Btrfs sur un desktop.

ZFS sait faire la même chose (zfs snapshot, zfs rollback), mais l’intégration avec le bootloader est plus complexe et moins répandue. Sur Ubuntu, le support ZFS root a reculé — Canonical a discrètement retiré l’option ZFS on root de l’installateur en 2024.

Send/Receive : match nul

Les deux filesystems excellent dans la réplication incrémentale :

# Btrfs
btrfs send -p @snap1 @snap2 | ssh backup btrfs receive /backup/

# ZFS
zfs send -i tank@snap1 tank@snap2 | ssh backup zfs recv backup/tank

Dans les deux cas, seules les différences entre snapshots sont transférées. La réplication distante est efficace, vérifiée, et utilisable en production. C’est un socle commun solide pour les stratégies de sauvegarde.

Le tableau comparatif

Le verdict

Utilisez Btrfs si :

• Vous êtes sur un desktop ou un laptop Linux (Fedora, openSUSE, Arch)
• Vous voulez des snapshots automatiques avant chaque mise à jour système
• Vous n’avez pas besoin de RAID5/6 — vous utilisez un seul disque, du RAID1 ou du RAID10
• Vous chiffrez déjà avec LUKS et la granularité par dataset ne vous manque pas
• Vous voulez un filesystem qui survit à un apt upgrade sans recompilation DKMS

Utilisez ZFS si :

• Vous montez un NAS ou un serveur de stockage avec 3 disques ou plus
• Vous avez besoin de RAID-Z (parité avec intégrité garantie)
• Vous voulez du chiffrement natif par dataset
• Vous avez 32 Go de RAM ou plus et voulez que le cache serve à quelque chose
• Vous acceptez le délai de compatibilité kernel et la recompilation DKMS

N’utilisez pas Btrfs RAID5/6 en production. En avril 2026, ce mode est toujours instable. Si vous avez besoin de parité, passez sur ZFS. Si vous voulez rester sur Btrfs, utilisez RAID1 ou RAID10 — ou empilez Btrfs sur du mdadm RAID6, mais vous perdez alors l’auto-réparation par checksum.

La question n’est pas « lequel est le meilleur ». C’est « lequel protège vos données dans votre cas d’usage ». Et la réponse change tout.

Références

• OpenZFS 2.4.2 Release Notes
• Btrfs Status — kernel 7.1 — avril 2026
• btrfs(5) — RAID56 status and recommended practices — kernel 7.1
• OpenZFS 2.4.0 Release Notes — mars 2025
• ArchWiki — Btrfs
• ArchWiki — ZFS
• OpenZFS FAQ