ZFS est la raison pour laquelle mon cluster Proxmox est fiable. Snapshots instantanés, réplication entre nœuds, vérification d’intégrité automatique, compression transparente. Mais ZFS a une courbe d’apprentissage — et les erreurs de configuration coûtent cher. Voici ce que j’ai appris après deux ans d’utilisation.
Pourquoi ZFS sur Proxmox
Proxmox supporte plusieurs backends de stockage : LVM, LVM-Thin, Btrfs, ZFS. ZFS est mon choix pour les données des VMs pour plusieurs raisons :
- Réplication native :
zfs send/receiveréplique les pools entre nœuds. Proxmox utilise ça pour la haute disponibilité. - Snapshots instantanés : un snapshot ZFS prend quelques millisecondes. Pas de verrouillage de la VM.
- Compression LZ4 : activée par défaut, transparente, réduit l’espace utilisé de 20-40% sur des données non compressées.
- Checksums : ZFS vérifie l’intégrité de chaque bloc lu. Un fichier corrompu silencieusement est détecté.
- Self-healing : avec des disques en miroir (RAID-Z), ZFS corrige automatiquement les blocs corrompus en lisant depuis le bon disque.
Créer un pool ZFS dans Proxmox
Lors de l’installation de Proxmox, l’installeur propose de créer un pool ZFS sur le disque système. C’est la bonne pratique — fais-le dès l’installation.
Types de pools
- Single disk : un seul disque. Pas de redondance. À éviter pour les données critiques.
- Mirror (RAID-1) : deux disques en miroir. Redondance complète. Mon choix sur le nœud 1.
- RAID-Z1 : minimum 3 disques (équivalent RAID-5 mais sans le write hole), tolère 1 panne. Bon rapport capacité/sécurité.
- RAID-Z2 : tolère 2 pannes simultanées. Pour les données très critiques.
Créer un pool depuis la CLI Proxmox
# Pool miroir sur deux SSD NVMe
zpool create -o ashift=12 tank mirror # ashift=12 = secteurs 4KB, optimal pour SSD NVMe /dev/nvme0n1 /dev/nvme1n1
# Vérifier le pool
zpool status tank
# Activer la compression
zfs set compression=lz4 tank
# Activer les checksums (activés par défaut mais vérifier)
zfs set checksum=on tank
Datasets : organiser le stockage
Un dataset est un sous-ensemble d’un pool ZFS avec ses propres propriétés. Sur chaque nœud, je crée des datasets séparés par usage :
# Dataset pour les VMs Proxmox
zfs create tank/vms
# Dataset pour les backups locaux
zfs create tank/backups
# Dataset pour les données Docker
zfs create tank/docker
# Propriétés spécifiques par dataset
zfs set recordsize=64K tank/vms # optimal pour VMs KVM
zfs set recordsize=1M tank/docker # optimal pour des gros fichiers
Réplication haute disponibilité entre nœuds
Ce que j’utilise sur mon cluster : la réplication ZFS intégrée à Proxmox. Pas de Sanoid, pas d’outils tiers — Proxmox gère la réplication directement depuis l’interface.
Chaque VM critique est répliquée sur un second nœud via zfs send/receive orchestré par Proxmox. En cas de panne du nœud principal, la VM peut être démarrée sur le nœud de secours en quelques minutes.
Configuration : Datacenter → Réplication → Ajouter. Choisir la VM, le nœud cible, et l’intervalle (15 minutes pour les VMs critiques).
Réplication entre nœuds Proxmox
C’est la killer feature de ZFS pour un cluster. Proxmox intègre la réplication ZFS directement dans son interface :
Dans PVE : sélectionne une VM > Replication > Add :
- Target : choisir le nœud de destination (nœud 2 ou 3)
- Schedule : toutes les 15 minutes
- Compression : activée
Proxmox utilise zfs send -i pour envoyer uniquement les blocs modifiés depuis la dernière réplication. Pour une VM qui change peu, la réplication prend quelques secondes toutes les 15 minutes.
Scrub : vérification d’intégrité planifiée
Le scrub ZFS parcourt tous les blocs du pool et vérifie leur intégrité. À planifier régulièrement :
# Scrub manuel
zpool scrub tank
# Status du scrub en cours
zpool status tank
# Planifier automatiquement (cron hebdomadaire)
echo "0 3 * * 0 root zpool scrub tank" >> /etc/cron.d/zfs-scrub
Monitoring ZFS dans Proxmox
Proxmox affiche l’état des pools ZFS dans son interface (Node > ZFS). Pour des alertes email en cas d’erreur :
apt install zfs-zed -y
# ZED (ZFS Event Daemon) envoie des emails sur les événements ZFS
# Configurer l'email dans /etc/zfs/zed.d/zed.rc
Active le L2ARC (Level 2 Adaptive Replacement Cache — cache SSD en lecture) sur les NVMe pour accélérer les lectures fréquentes sur un pool avec des disques rotatifs. Si ton pool principal est sur des HDD mais que tu as un NVMe disponible, zpool add tank cache /dev/nvme0n1p1 crée un cache SSD en lecture. Les blocs fréquemment lus sont cachés sur le NVMe — performances proches d’un NVMe pour les données chaudes, capacité des HDD pour les données froides. Sur mon UNAS Pro avec 4 HDD + 1 NVMe cache, les accès aux VMs les plus actives sont indistinguables d’un NVMe direct.
👉 Pour aller plus loin : créer ses premières VMs sur Proxmox, PBS pour les backups VMs, et le setup homelab complet avec ZFS.
ZFS : le système de fichiers qui pardonne les erreurs
ZFS m’a déjà sauvé une fois — quand un SSD a commencé à avoir des erreurs silencieuses, ZFS les a détectées avant que ça devienne une corruption. ext4 n’aurait rien dit.
Combiné à PBS pour les sauvegardes et à la réplication inter-nœuds, tu as trois couches de protection indépendantes.
FAQ
Combien de RAM faut-il pour ZFS sur Proxmox ?
Minimum 8 Go dédiés à ZFS (ARC cache). La règle empirique est 1 Go de RAM par To de stockage brut. Sur mon cluster, chaque nœud a 64 Go dont ~16 Go utilisés par l’ARC ZFS pour 4 To de stockage.
ZFS ou LVM-Thin sur Proxmox ?
ZFS apporte l’intégrité des données (checksums), la réplication native et la compression. LVM-Thin est plus simple et consomme moins de RAM. Pour un homelab sérieux avec plusieurs nœuds, ZFS vaut l’investissement en RAM.
Peut-on ajouter un disque à un pool ZFS existant ?
On peut ajouter un nouveau vdev (miroir ou raidz) à un pool existant, mais on ne peut pas étendre un vdev existant (ex : passer un miroir 2 disques à 3). Planifie ta topologie de pool dès le départ.
