Mon MS-01 tourne sur un seul NVMe : le Kingston OEM de 1 To livré avec le bundle. Un seul disque, ça veut dire un seul point de défaillance – si ce NVMe meurt, tout part avec lui : VMs, containers, snapshots. Les snapshots ZFS vivent sur le même pool que les données qu’ils protègent ; contre une panne disque, ils ne valent rien.
Ce qui me protège vraiment aujourd’hui, ce sont les backups PBS quotidiens vers le Synology (article 7 de la série). Mais la réponse structurelle, c’est de la redondance locale – et le MS-01 a trois slots NVMe dont deux encore libres. Ce guide couvre les options de stockage sous Proxmox, ma configuration actuelle, et le miroir ZFS prévu pour ces slots libres.
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 (1 disque) | ❌ (détecte sans corriger) | ✅ | Compression, snapshots, intégrité |
| 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 actuelle :
- Slot 1 (M.2 2280) : Kingston OEM 1 To (livré avec le bundle) – Proxmox OS + pool ZFS
rpoolpour toutes les VMs et données - Slots 2 + 3 (M.2 22110) : libres – réservés au futur miroir ZFS dédié aux 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 (disque unique)
└── nvme0n1 (Kingston OEM 1TB, slot 1)Sur un vdev à disque unique, ZFS checksumme tout : il détecte la corruption silencieuse, mais n’a aucune copie saine pour la corriger. C’est déjà mieux qu’ext4 – on sait qu’un fichier est corrompu au lieu de le découvrir six mois plus tard – mais ça ne remplace pas la redondance.
Ce qu’apporterait un 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. Le prix : la moitié de la capacité totale, 2× 1 TB → 1 TB utilisable.
L’état actuel du pool
Identifier les disques :
lsblk -d -o NAME,SIZE,MODEL,SERIAL
# NAME SIZE MODEL SERIAL
# nvme0n1 953.9G KINGSTON OM8TAP41024K1-A00 50026B7383BC8DAFL’installeur Proxmox en mode ZFS a créé rpool sur la troisième partition du disque :
zpool status rpool
# pool: rpool
# state: ONLINE
# config:
# NAME STATE READ WRITE CKSUM
# rpool ONLINE 0 0 0
# nvme0n1p3 ONLINE 0 0 0Le futur miroir ZFS
Le jour où les slots 2 et 3 recevront leurs deux NVMe 1 To, le pool de données se créera comme ça (en gardant rpool pour l’OS) :
zpool create -f \
-o ashift=12 \
-O compression=lz4 \
-O atime=off \
-O xattr=sa \
-O dnodesize=auto \
tank mirror /dev/nvme1n1 /dev/nvme2n1Explication 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.
Ajouter le pool dans Proxmox
Depuis l’interface web : Datacenter > Storage > Add > ZFS.
ID : tank
Pool : tank
Thin provision : Oui (recommandé pour les snapshots VM)
Content : Disk image, ContainerOu en CLI :
pvesm add zfspool tank --pool tank --sparse 1 --content images,rootdirLe 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 :
arc_summary | grep -E "ARC size|Maximum"
# ARC size (current) : 14.2 GiB
# Maximum size : 16.0 GiBL’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 zfs_arc_max=4294967296" > /etc/modprobe.d/zfs.conf
update-initramfs -uRedé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|^c_max"
# Ou avec arc_summary (paquet zfsutils-linux)
arc_summaryNFS : 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 : 3NFS 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 accueilleront le miroir ZFS.
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-scrubPlanifier 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-150La limite de ma config actuelle
Sur un pool à disque unique, un scrub qui trouve des blocs corrompus ne peut rien réparer : ZFS voit l’erreur grâce aux checksums, la signale, mais n’a aucune copie saine où lire.
zpool status -v rpool
# errors: Permanent errors have been detected in the following files:
# (liste des fichiers touchés)Dans ce scénario, la seule issue est la restauration depuis backup – d’où le PBS quotidien vers le DS414, qui est aujourd’hui ma vraie ligne de défense.
Sur un miroir, le même scénario se répare tout seul : ZFS lit la copie saine sur l’autre disque et réécrit le bloc corrompu, sans interruption ni perte. C’est exactement ce que les slots 2 et 3 attendent. D’ici là : scrub hebdomadaire pour détecter tôt, backups quotidiens pour pouvoir restaurer.
Série « Homelab Proxmox MS-01 » – Article 6/10
