Un soir de janvier, j’ai perdu une VM Gitea. Pas de corruption dramatique, juste un NVMe Kingston NV3 qui a commencé à remonter des erreurs SMART, puis s’est mis en read-only, puis plus rien. Tout était sur le disque en question – données, snapshots, tout. Récupération : zéro. Temps de reconstruction depuis les configs Git sur mon poste local : cinq heures.
C’est à ce moment-là que j’ai commandé un deuxième Kingston NV3 1TB et configuré ZFS en miroir. Ce guide couvre ce choix et les autres options de stockage disponibles sous Proxmox.
Les options de stockage Proxmox
Proxmox supporte plusieurs backends de stockage. Voilà comment je les catégorise sur un nœud unique :
| Solution | Redondance | Snapshot VM | Idéal pour |
|---|---|---|---|
local-lvm (LVM-thin) |
❌ | ✅ | OS Proxmox, démarrage rapide |
| ZFS mirror | ✅ (2 disques) | ✅ | VMs et LXC sur nœud solo |
| NFS | ❌ (dépend du NAS) | ✅ | ISO, backups, stockage partagé |
| Ceph | ✅ (3+ nœuds) | ✅ | Cluster multi-nœuds |
| iSCSI | ❌ (dépend cible) | ✅ | NAS enterprise |
Ma configuration MS-01 utilise trois slots NVMe :
- Slot 1 (M.2 2280) : WD Blue 500 GB – Proxmox OS +
local-lvmpour les containers légers - Slots 2 + 3 (M.2 22110) : 2× Kingston NV3 1 TB en miroir ZFS – toutes les VMs et données
ZFS en deux mots
ZFS est un filesystem + volume manager qui gère lui-même la redondance, l’intégrité et les snapshots. Pas besoin de RAID matériel, pas besoin de LVM par-dessus.
Pool ZFS (rpool)
└── vdev mirror
├── nvme1n1 (Kingston NV3 1TB, slot 2)
└── nvme2n1 (Kingston NV3 1TB, slot 3)
Ce qu’on gagne avec le miroir : si un disque lâche, le pool reste lisible et fonctionnel. On remplace le disque mort, ZFS resynchronise. Aucun arrêt de service, aucune perte de données.
Ce qu’on perd : la moitié de la capacité totale. 2× 1 TB → 1 TB utilisable. C’est le prix de la redondance.
Créer le pool ZFS miroir
Identifier les disques avant de créer le pool :
lsblk -d -o NAME,SIZE,MODEL,SERIAL
# NAME SIZE MODEL SERIAL
# nvme0n1 500G WD Blue SN570 WD-...
# nvme1n1 1T KINGSTON SNV2S1000 50026B...
# nvme2n1 1T KINGSTON SNV2S1000 50026B...
Les deux Kingston sont sur nvme1n1 et nvme2n1. Créer le pool :
zpool create -f
-o ashift=12
-O compression=lz4
-O atime=off
-O xattr=sa
-O dnodesize=auto
rpool mirror /dev/nvme1n1 /dev/nvme2n1
Explication des options importantes :
ashift=12 – taille de secteur 4096 octets (4K), alignée sur les NVMe modernes. Un ashift trop bas dégrade les performances de manière permanente et non corrigeable ; le mettre à 12 dès la création est impératif.
compression=lz4 – compression transparente activée. LZ4 est quasi sans overhead CPU sur des NVMe modernes et économise 10–30% d’espace selon les données. À toujours activer.
atime=off – désactiver la mise à jour du timestamp d’accès. Réduit les écritures inutiles sur le pool.
xattr=sa – stocke les attributs étendus dans les inodes plutôt qu’en sous-répertoires. Nécessaire pour les performances Nextcloud et certains workloads Linux.
Vérifier l’état du pool :
zpool status rpool
# pool: rpool
# state: ONLINE
# config:
# NAME STATE READ WRITE CKSUM
# rpool ONLINE 0 0 0
# mirror-0 ONLINE 0 0 0
# nvme1n1 ONLINE 0 0 0
# nvme2n1 ONLINE 0 0 0
Ajouter rpool dans Proxmox
Depuis l’interface web : Datacenter > Storage > Add > ZFS.
ID : rpool
Pool : rpool
Thin provision : Oui (recommandé pour les snapshots VM)
Content : Disk image, Container
Ou en CLI :
pvesm add zfspool rpool --pool rpool --sparse 1 --content images,rootdir
Le stockage apparaît désormais dans la liste déroulante à la création de VM et LXC.
ZFS et la RAM : le point critique
ZFS maintient un cache mémoire appelé ARC (Adaptive Replacement Cache). Par défaut, il peut consommer jusqu’à 50% de la RAM disponible. Sur 32 Go de RAM, ça fait 16 Go potentiellement réservés au cache – c’est trop pour un homelab avec des VMs actives.
Mesure réelle après 72h de fonctionnement sans limite :
arcsummary | grep -E "ARC size|Maximum"
# ARC size (current) : 14.2 GiB
# Maximum size : 16.0 GiB
L’ARC avait pris 14 Go. Les VMs se disputaient les 18 Go restants avec Proxmox. Limiter à 4 Go est un compromis raisonnable sur 32 Go de RAM totale :
echo "options zfs zfsarcmax=4294967296" > /etc/modprobe.d/zfs.conf
update-initramfs -u
Redémarrer pour que la limite soit prise en compte. Après redémarrage, l’ARC reste sous 4 Go et les VMs ont leur marge.
Pour surveiller l’ARC en temps réel :
# Surveillance simple
cat /proc/spl/kstat/zfs/arcstats | grep -E "^size|^cmax"
# Ou avec arcsummary (paquet zfsutils-linux)
arcsummary
NFS : intégrer le Synology DS414
Le DS414 tourne avec Synology DSM, connecté au switch stockage via SFP+ 10GbE. Il contient 4× WD Red Pro 4 TB en SHR (RAID Synology) – 8 To utilisables. Je l’utilise pour les backups PBS et les ISO, pas pour les VMs chaudes.
Configurer le partage NFS sur le DS414 :
Dans DSM : Panneau de configuration > Services de fichiers > NFS. Activer NFS, protocole NFS 4.1. Créer le dossier partagé proxmox-iso avec accès NFS pour 10.10.0.1/24 (réseau stockage), droits Read/Write, squash No mapping.
Côté Proxmox :
Datacenter > Storage > Add > NFS
ID : synology-ds414
Server : 10.10.0.100 ← IP DS414 sur le réseau stockage
Export : /volume1/proxmox-iso
Content : ISO image, VZDump backup file
Max Backups : 3
NFS n’est pas adapté pour stocker des images de VM actives – la latence réseau est perceptible et les snapshots ZFS ne sont pas disponibles sur un volume NFS dans Proxmox. Réserver au stockage froid : ISO, backups PBS, archives.
La connexion passe par le bridge vmbr1 sur 10.10.0.0/24, pas par le LAN principal. Le traffic de stockage ne pollue pas le LAN 2.5GbE des VMs.
Ceph : non, pas pour un nœud unique
Ceph est un système de stockage distribué qui réplique chaque bloc de données sur trois nœuds minimum. Il est spectaculaire en cluster : migration live de VMs sans interruption, tolérance à la panne d’un nœud entier, scaling horizontal.
En mono-nœud, il n’a pas de sens. Ceph a besoin de 3 monitor nodes pour le quorum, consomme ~2 Go de RAM par OSD (disque), et nécessite des disques dédiés séparés des disques OS. Sur le MS-01, avec 3 slots NVMe dont un pour l’OS, les deux restants en miroir ZFS sont déjà optimisés.
Si tu envisages un cluster Proxmox à 3 nœuds, Ceph devient intéressant. Pour un homelab solo, ZFS + NFS couvre tous les besoins.
Scrub ZFS et maintenance
Un scrub ZFS vérifie l’intégrité de toutes les données sur le pool, bloc par bloc, en comparant les checksums. C’est ce qui détecte les corruptions silencieuses avant qu’elles deviennent un problème.
# Lancer un scrub manuellement
zpool scrub rpool
# Voir l'avancement
zpool status rpool
# scan: scrub in progress since Fri May 29 03:00:01 2026
# ~892.84M scanned at 148.81M/s, ~79.15M issued at 13.19M/s, 892.84M total
# ...
# Automatiser en cron (Proxmox a un scheduler intégré)
# Datacenter > Nodes > pve > Task scheduler
# Ou en crontab :
echo "0 3 0 zpool scrub rpool" >> /etc/cron.d/zfs-scrub
Planifier un scrub hebdomadaire, de nuit. Sur des NVMe de 1 To, ça prend 30 à 60 minutes selon la charge.
Snapshots manuels avant toute mise à jour :
# Snapshot d'un zvol LXC (CT 150 = Pi-hole)
zfs snapshot rpool/data/subvol-150-disk-0@avant-maj-$(date +%Y%m%d)
# Rollback si problème
zfs rollback rpool/data/subvol-150-disk-0@avant-maj-20260529
# Lister les snapshots
zfs list -t snapshot -o name,creation,used | grep subvol-150
Ce qui a coincé
Le premier incident avec ZFS, trois semaines après l’installation du miroir : un scrub a détecté 4 blocs corrompus sur nvme2n1. L’état du pool était DEGRADED.
zpool status rpool
# state: DEGRADED
# errors: 4 data errors, use '-v' for a list
Panique immédiate. Heureusement le miroir a absorbé la corruption – les données ont été lues depuis nvme1n1 et réécrites correctement sur nvme2n1. ZFS a auto-réparé les 4 blocs. Aucune perte de données.
zpool clear rpool
zpool scrub rpool
# Résultat : ONLINE, 0 errors
Le disque n’était pas défaillant – c’était une erreur de transmission fugace pendant un transfert intense. Mais cet incident m’a confirmé que l’architecture miroir fonctionne exactement comme prévu : on voit l’erreur, ZFS la corrige, et on continue.
Sans miroir, ces 4 blocs auraient été silencieusement corrompus dans les données. ZFS sans redondance détecte la corruption mais ne peut pas la corriger.
Série « Homelab Proxmox MS-01 » – Article 6/10