Stockage local Proxmox VE : comprendre les backends et faire le bon choix

Où stocker vos VM ? Cette question simple cache des choix qui conditionnent tout le reste : snapshots possibles ou non, performances, risque de perte de données, facilité de dépannage. Ce guide vous donne les modèles mentaux pour comprendre comment Proxmox gère le stockage, puis les critères pour choisir le bon backend.

Le modèle mental Proxmox : 3 couches

Avant de choisir quoi que ce soit, vous devez comprendre comment Proxmox organise le stockage. Sans ce modèle mental, vous allez confondre disques, backends et storages — et faire des erreurs.

Couche 1 : les disques physiques

C’est le matériel brut : /dev/sda, /dev/nvme0n1. C’est ce que vous branchez physiquement sur votre serveur.

Point clé : Proxmox ne peut rien faire directement avec un disque physique. Un disque doit être “organisé” par un backend avant d’être utilisable.

Un choix à faire tôt : comment votre contrôleur expose les disques ?

Mode	Ce que voit Proxmox	Conséquence
HBA / JBOD	Chaque disque individuellement	ZFS possible, vous gérez la redondance
RAID matériel	Un seul “disque” virtuel	ZFS déconseillé, LVM-thin recommandé

Si vous avez un contrôleur RAID matériel et voulez utiliser ZFS, reconfigurez-le en mode HBA/JBOD. Sinon, ZFS ne verra pas les vrais disques et ne pourra pas garantir l’intégrité.

Couche 2 : le backend

Le backend est la technologie qui organise les données sur le(s) disque(s). C’est lui qui détermine les fonctionnalités disponibles : snapshots, compression, intégrité…

Proxmox supporte trois backends locaux principaux :

Backend	Comment il stocke les disques VM	Fonctionnalités clés
Directory	Fichiers (qcow2, raw) sur ext4/XFS	Simplicité, transparence
LVM-thin	Volumes logiques bloc	Thin provisioning, snapshots rapides
ZFS	Zvols ou datasets	Intégrité, compression, snapshots

Couche 3 : le storage Proxmox

Un storage Proxmox est un objet logique configuré dans l’interface. C’est ce que vous voyez dans Datacenter → Storage et ce que vous choisissez quand vous créez une VM.

Un storage définit :

Le backend utilisé (Directory, LVM-thin, ZFS…)
Les content types autorisés (disques VM, ISO, backups…)
Le chemin ou pool où les données sont stockées

La phrase clé : Proxmox ne stocke pas “des VM”. Il stocke des contenus (images, backup, iso…) sur un backend, via un storage configuré.

Modèle mental du stockage Proxmox : des disques physiques vers les backends (LVM-thin, ZFS, ext4) puis vers les storages Proxmox

Pourquoi cette distinction compte

Cette architecture en 3 couches a des conséquences pratiques :

Vous pouvez avoir 3 disques mais 1 seul storage (3 disques en ZFS raidz)
Vous pouvez avoir 1 disque avec 2 storages (un pour VM, un pour backups)
Quand vous créez une VM, vous choisissez un storage, pas un disque

Deux décisions fondamentales

Avant de choisir entre LVM-thin, ZFS ou Directory, vous devez comprendre deux concepts qui changent tout.

Fichier vs bloc

Les backends stockent les disques VM de deux façons fondamentalement différentes :

Approche	Backends	Comment ça marche
Fichier	Directory	Le disque VM est un fichier (`.qcow2`, `.raw`) visible dans un répertoire
Bloc	LVM-thin, ZFS (zvol)	Le disque VM est un volume bloc, pas directement visible comme fichier

Ce que ça implique :

Critère	Fichier (Directory)	Bloc (LVM-thin, ZFS)
Debug	Facile : `ls`, `cp`, `mount`	Plus technique : `lvs`, `zfs list`
Backup hors Proxmox	Simple copie de fichier	Nécessite des outils spécifiques
Performance	Correcte (overhead filesystem)	Meilleure (accès direct)
Snapshots	Via qcow2 (overhead cumulatif)	Natifs au backend (plus efficaces)

En résumé : fichier = transparence et simplicité ; bloc = performance et fonctionnalités.

Snapshot vs backup : ce ne sont pas des synonymes

C’est une confusion fréquente qui mène à des pertes de données.

Concept	Ce que c’est	Durée de vie	Protection
Snapshot	Point de restauration sur le même storage	Court terme (heures/jours)	Aucune si le storage meurt
Backup	Copie indépendante sur un autre storage	Long terme	Survit à la perte du storage source

Le snapshot sert à expérimenter : “je fais une mise à jour risquée, si ça casse, je rollback en 2 secondes”. C’est rapide, c’est pratique, mais ce n’est pas une sauvegarde.

Le backup sert à restaurer après un incident : disque mort, erreur humaine, ransomware. Il doit être sur un autre support (autre disque, NAS, cloud).

La règle : les snapshots facilitent les opérations quotidiennes, les backups protègent contre les catastrophes. Vous avez besoin des deux.

Les 4 critères de choix

Pour choisir un backend, vous devez savoir ce qui compte pour vous. Voici les 4 critères qui différencient réellement les options.

1. Intégrité des données

La question : si un bit se corrompt silencieusement sur le disque (“bit rot”), est-ce que je le saurai ?

Backend	Détection corruption	Correction automatique
Directory (ext4/XFS)	❌ Non	❌ Non
LVM-thin	❌ Non	❌ Non
ZFS	✅ Oui (checksums)	✅ Oui (si mirror/raidz)

Si l’intégrité est votre priorité #1 → ZFS est le seul backend local qui la garantit.

2. Performance

La question : quelle latence et quels IOPS pour mes VM ?

Backend	Performance relative	Notes
Directory (ext4)	⭐⭐ Correcte	Overhead du filesystem, snapshots qcow2 peuvent dégrader
LVM-thin	⭐⭐⭐ Bonne	Accès bloc direct, snapshots efficaces
ZFS	⭐⭐⭐ Bonne à excellente	Copy-on-write a un coût, mais le cache ARC compense

Si la performance est votre priorité #1 → LVM-thin ou ZFS sur SSD/NVMe.

3. Opérabilité

La question : est-ce que je peux débugger, migrer, récupérer facilement ?

Backend	Debug	Migration	Récupération après incident
Directory	✅ Fichiers visibles	✅ Copie simple	✅ Outils standards
LVM-thin	⚠️ Commandes LVM	⚠️ Export/import	⚠️ Nécessite expertise
ZFS	⚠️ Commandes ZFS	✅ `zfs send/recv`	✅ Résilience intégrée

Si l’opérabilité est votre priorité #1 → Directory pour la transparence, ZFS pour la résilience.

4. Simplicité

La question : quelle est la probabilité que je fasse une erreur en production ?

Backend	Concepts à maîtriser	Pièges fréquents
Directory	Quasi aucun	Peu de pièges
LVM-thin	Thin provisioning, surveillance	Pool plein = catastrophe
ZFS	ARC, vdevs, datasets, scrub	RAM insuffisante, mauvais design

Si la simplicité est votre priorité #1 → Directory ou LVM-thin avec surveillance.

Tableau de décision

Si votre priorité #1 est…	Choisissez…	Parce que…
Intégrité	ZFS	Seul backend avec checksums
Performance pure	LVM-thin ou ZFS	Accès bloc, pas d’overhead fichier
Transparence / debug	Directory	Fichiers visibles, outils classiques
Simplicité	LVM-thin (défaut)	Déjà configuré, équilibre correct

Les 3 backends comme profils

Chaque backend a un “caractère” distinct. Plutôt que des fiches techniques, voici comment les comprendre.

Directory (ext4/XFS) — Le transparent

Promesse : “Je vois mes données, je copie, je monte, je dépanne avec des outils que je connais.”

Forces :

Aucun concept nouveau à apprendre (c’est du Linux classique)
Les disques VM sont des fichiers : ls, cp, mount -o loop fonctionnent
Tous les content types possibles (VM, ISO, backup, templates)
Pas de prérequis matériel ou RAM

Faiblesses :

Snapshots via qcow2 : fonctionnent, mais créent un overhead cumulatif
Pas de détection de corruption (vous faites confiance au disque)
Performances correctes mais pas optimales

Cas typiques : stocker vos ISO d’installation, vos backups, vos templates de conteneurs. Aussi adapté pour un homelab ultra-simple où vous voulez comprendre ce qui se passe.

LVM-thin — L’efficace (mais à surveiller)

Promesse : “Snapshots instantanés, thin provisioning, bonnes performances — tant que je surveille mon pool.”

Forces :

Snapshots en une fraction de seconde, quelle que soit la taille
Thin provisioning : sur-allouer sans gaspiller d’espace réel
Bonnes performances I/O (accès bloc direct)
Pas de prérequis RAM (contrairement à ZFS)

Faiblesses :

Le piège du pool plein (voir section modes de panne)
Pas de checksums (corruption silencieuse non détectée)
Commandes LVM à connaître pour le debug et la maintenance

Le concept clé : thin provisioning

Le thin provisioning vous permet de promettre plus d’espace qu’il n’en existe. Vous créez 10 VM avec des disques de 100 Go sur un pool de 500 Go. Tant que l’espace réellement écrit ne dépasse pas 500 Go, tout va bien.

C’est comme un hôtel qui accepte 150 réservations pour 100 chambres : ça fonctionne tant que tout le monde ne vient pas en même temps.

Le danger : si vos VM écrivent plus que l’espace disponible, le pool se remplit et tout se fige. C’est le mode de panne #1 avec LVM-thin.

Cas typiques : c’est le défaut de Proxmox pour les VM et conteneurs. Gardez-le si vous débutez, mais apprenez à surveiller.

ZFS — L’intègre (mais exigeant)

Promesse : “Vos données sont protégées contre la corruption, avec snapshots, compression, et redondance — si vous avez les ressources.”

Forces :

Intégrité garantie : chaque bloc a un checksum, la corruption est détectée
En mirror/raidz : correction automatique des erreurs
Compression native (LZ4 quasi gratuit, économise 20-40%)
Snapshots solides et efficaces
zfs send/recv pour les migrations et backups

Faiblesses :

Consommation RAM : ZFS utilise la mémoire pour son cache (ARC)
Incompatible avec les contrôleurs RAID matériels (veut voir les vrais disques)
Plus de concepts à maîtriser (pools, vdevs, datasets, scrub…)
Copy-on-write a un coût sur les écritures aléatoires

Le concept clé : copy-on-write et ARC

ZFS ne modifie jamais les données en place. Quand vous écrivez, il écrit ailleurs puis met à jour les pointeurs. C’est ce qui permet les snapshots instantanés et la protection contre la corruption.

L’ARC (Adaptive Replacement Cache) est le cache de lecture de ZFS. Il utilise la RAM disponible pour accélérer les lectures. Par défaut, ZFS peut prendre jusqu’à 50% de la RAM — ce n’est pas un bug, c’est une optimisation.

Recommandations RAM :

Minimum : 8 Go totaux
Confortable : 16 Go totaux
Règle empirique : ~1 Go par To de stockage (indicatif, pas strict)

Cas typiques : données importantes que vous ne voulez jamais perdre, serveur avec 2 disques identiques pour un mirror, environnement où l’intégrité prime sur la simplicité.

Les modes de panne à anticiper

Chaque backend a ses modes de panne caractéristiques. Connaître ces pièges vous permet de les éviter ou de réagir correctement.

LVM-thin : le pool plein

Le scénario : vos VM écrivent plus que l’espace réel du thin pool. À 100% d’utilisation :

Les écritures échouent
Les VM se figent ou plantent
Vous devez agir en urgence

Prévention :

Surveiller régulièrement : lvs -o lv_name,data_percent
Alerte à 80%, action immédiate à 90%
Ne jamais laisser atteindre 100%

Récupération : agrandir le pool, supprimer des snapshots inutiles, ou supprimer une VM non critique pour libérer de l’espace.

LVM-thin : metadata plein

Moins fréquent mais tout aussi grave. Le thin pool a deux composants : data (vos données) et metadata (l’index). Si les metadata saturent, même avec de l’espace data libre, tout se fige.

Prévention : surveiller aussi metadata_percent avec lvs.

ZFS : pression mémoire

Le scénario : ZFS consomme trop de RAM pour l’ARC, le système swappe, tout devient lent.

Symptômes : système très lent, free -h montre peu de RAM disponible, swap utilisé.

Prévention :

Avoir assez de RAM (8 Go minimum, 16 Go confortable)
Si nécessaire, limiter l’ARC dans /etc/modprobe.d/zfs.conf

Récupération : redémarrer, puis ajuster la limite ARC ou ajouter de la RAM.

ZFS : pool dégradé

Le scénario : un disque du pool tombe en panne.

En single : perte de données
En mirror : le pool continue en mode dégradé, performances réduites
En raidz/raidz2 : idem, avec tolérance à 1 ou 2 pannes

Prévention :

Utiliser mirror ou raidz (jamais single pour des données importantes)
Configurer des alertes sur l’état du pool
Lancer des scrubs mensuels pour détecter les problèmes tôt

Récupération : remplacer le disque défaillant et lancer un resilver.

ZFS : mauvais design de vdevs

Le scénario : vous avez ajouté des disques n’importe comment au pool.

ZFS ne permet pas de retirer un vdev une fois ajouté. Si vous ajoutez un disque seul (single) à un pool mirror, vous créez un point de faiblesse permanent.

Prévention : planifier le design du pool avant de le créer. Un mirror de 2 disques, c’est bien. Ajouter des disques se fait par paires en mirror.

Directory : saturation et fragmentation

Le scénario : le filesystem ext4/XFS se remplit ou se fragmente.

Symptômes : erreurs “no space left on device”, performances dégradées.

Prévention :

Surveiller avec df -h
Ne pas dépasser 80-85% d’utilisation

Récupération : libérer de l’espace, défragmenter si nécessaire (rare avec ext4/XFS).

Directory : snapshots qcow2 empilés

Le scénario : vous gardez beaucoup de snapshots sur des VM en format qcow2.

Chaque snapshot crée une “chaîne” de fichiers. Plus la chaîne est longue, plus les performances se dégradent et plus la récupération devient complexe.

Prévention : supprimer les snapshots obsolètes régulièrement. Un snapshot n’est pas un backup.

Architecture recommandée

Sans entrer dans les procédures de création (qui seront dans les homelabs), voici les patterns d’architecture à retenir.

Séparer runtime et archives

Rôle	Content types	Backend recommandé
Runtime	`images`, `rootdir`	LVM-thin ou ZFS
Archives	`backup`, `iso`, `vztmpl`	Directory (ext4)

Pourquoi séparer ? Les backups peuvent être volumineux et imprévisibles. Si un backup remplit votre storage VM, vos VM se figent. En séparant, un problème sur l’un n’affecte pas l’autre.

Avec 1 seul disque

C’est souvent le cas en homelab. Vous devez accepter un compromis :

LVM-thin (défaut Proxmox) : snapshots rapides, thin provisioning, mais surveillance nécessaire
ZFS single : intégrité des données, mais aucune redondance (risqué pour des données importantes)

Dans les deux cas, vos backups doivent aller ailleurs (NAS, disque USB externe, cloud).

Avec 2 disques identiques

La configuration idéale pour un homelab sérieux :

ZFS mirror : intégrité + redondance, un disque peut tomber sans perte
Ou LVM-thin sur chaque disque : un pour VM, un pour backups

Le mirror est généralement le meilleur choix si vous avez 8 Go+ de RAM.

Avec 3+ disques

Plusieurs options selon vos priorités :

ZFS raidz (3 disques) : équivalent RAID5, 1 disque de parité
ZFS raidz2 (4+ disques) : équivalent RAID6, 2 disques de parité
Séparation par rôle : 2 disques en mirror pour VM, 1 disque en Directory pour backups

Observer vos storages

Sans entrer dans les procédures de création, voici les commandes pour lire l’état de vos storages :

# Vue globale de tous les storages Proxmox
pvesm status

# LVM-thin : utilisation du pool (surveiller data% et meta%)
lvs -o lv_name,data_percent,metadata_percent

# ZFS : état du pool (doit afficher ONLINE)
zpool status

# ZFS : utilisation de l'espace
zpool list

# Directory : espace disque classique
df -h

Ces commandes sont de la lecture, pas de la modification. Utilisez-les pour comprendre l’état de votre système.

À retenir

Storage ≠ Disque : Proxmox organise le stockage en 3 couches (disques → backend → storage). Comprendre cette architecture évite les confusions.
Fichier vs bloc : Directory stocke des fichiers visibles, LVM-thin et ZFS stockent des volumes bloc. Chacun a ses avantages.
Snapshot ≠ Backup : le snapshot est un point de restauration court terme, le backup est une copie indépendante long terme. Vous avez besoin des deux.
LVM-thin : efficace mais à surveiller : thin provisioning est puissant, mais un pool plein = catastrophe. Surveillez à partir de 80%.
ZFS : intégrité contre ressources : checksums et redondance, mais demande de la RAM et des disques en mode HBA.
Directory : simplicité et transparence : idéal pour ISO, backups, templates. Pas optimal pour les VM en production.
Séparez runtime et archives : un storage pour vos VM, un autre pour vos backups.

Prochaines étapes

Installation Proxmox Installer Proxmox VE étape par étape

Configuration réseau Comprendre bridges, VLAN et NAT dans Proxmox

Interface Proxmox Naviguer efficacement dans l'interface web

Introduction Proxmox Comprendre l'architecture et les 4 piliers