Stockage local Proxmox VE : choisir entre Directory, LVM-thin et ZFS

Vous avez installé Proxmox, mais où stocker vos VM et conteneurs ? Cette question paraît simple, mais le choix du stockage conditionne tout le reste : performances, snapshots, sauvegardes, et même la facilité de dépannage. Ce guide vous aide à comprendre les options, choisir celle qui correspond à votre situation, puis créer votre premier storage en quelques minutes.

Décision rapide — Si vous êtes pressé

• Vous débutez / 1 nœud → gardez LVM-thin (c’est déjà installé par défaut)
• Stocker ISO et backups → ajoutez un Directory (ext4) sur un disque séparé
• Intégrité critique + 8 Go+ RAM + 2 disques → ZFS mirror

Comprendre les 3 options → · Créer un storage → · Éviter les pièges →

Pourquoi ce module est important

Le stockage est le fondement de votre infrastructure Proxmox. Un mauvais choix initial peut vous bloquer plus tard :

• Pas de snapshots si vous utilisez Directory avec des disques raw
• VM figées si votre thin pool LVM se remplit à 100%
• Système lent si ZFS manque de RAM pour son cache

Inversement, un bon choix vous donne de la flexibilité : snapshots instantanés pour tester des mises à jour, compression automatique pour économiser de l’espace, ou redondance pour protéger vos données.

Ce module vous apprend à faire ce choix en connaissance de cause, pas à l’aveugle.

Storage ≠ Disque : le concept fondamental

Avant de configurer quoi que ce soit, vous devez comprendre une distinction que beaucoup de débutants confondent.

Un disque physique (/dev/sdb, /dev/nvme0n1) est du matériel brut. C’est ce que vous branchez physiquement sur votre serveur. En soi, Proxmox ne peut rien en faire directement.

Un storage Proxmox est un objet logique configuré dans Proxmox. C’est lui qui dit à Proxmox : “tu peux stocker des disques de VM ici, en utilisant tel backend (LVM-thin, ZFS, etc.)”.

Cette distinction a des conséquences pratiques importantes :

• Vous pouvez avoir 3 disques physiques mais 1 seul storage (par exemple, 3 disques en ZFS raidz)
• Vous pouvez avoir 1 disque physique avec 2 storages (un pour les VM, un pour les backups)
• Un storage peut être local (sur les disques du serveur) ou partagé (NFS, iSCSI, Ceph)

Dans ce module, nous nous concentrons sur le stockage local — celui qui utilise les disques directement connectés à votre serveur Proxmox.

Les termes à connaître

Pour éviter toute confusion dans la suite du guide, voici le vocabulaire précis :

Terme	Ce que c’est	Exemple concret
Disque physique	Le matériel brut détecté par le système	/dev/sdb, /dev/nvme0n1
Backend	La technologie utilisée pour organiser les données	Directory, LVM-thin, ZFS, NFS…
Storage Proxmox	L’objet configuré dans l’interface Proxmox	local-lvm, backup-nfs, tank
Content type	Ce qu’un storage peut contenir	images (disques VM), iso, backup

Glissez pour voir

Quand vous créez une VM et qu’on vous demande “sur quel storage ?”, vous choisissez un storage Proxmox, pas un disque physique. Proxmox se charge ensuite de traduire ça en opérations sur le disque via le backend configuré.

Choisir le bon backend

Proxmox supporte de nombreux backends de stockage, mais pour le stockage local, trois options dominent largement. Chacune a ses forces et ses faiblesses — il n’y a pas de “meilleur” choix universel, seulement le bon choix pour votre situation.

Directory (ext4/XFS) — La simplicité avant tout

Un Directory storage est la forme la plus simple de stockage : c’est un répertoire sur un système de fichiers classique (ext4 ou XFS). Les disques virtuels de vos VM sont stockés comme de simples fichiers sur ce système de fichiers.

Comment ça fonctionne concrètement : quand vous créez une VM avec un disque de 32 Go sur un Directory storage, Proxmox crée un fichier (au format qcow2 ou raw) dans ce répertoire. Ce fichier représente le disque de la VM. Vous pouvez même le voir avec ls -la /var/lib/vz/images/100/ si votre VM a l’ID 100.

Les avantages de Directory :

• Simplicité maximale : tout le monde connaît ext4, pas besoin de compétences spéciales
• Debugging facile : les disques sont des fichiers, vous pouvez les copier, les monter, les inspecter
• Aucun prérequis matériel : fonctionne sur n’importe quel disque, n’importe quelle quantité de RAM
• Tous les content types : peut stocker VM, ISO, backups, templates — tout ce que vous voulez

Les limites de Directory :

• Snapshots avec overhead : les snapshots utilisent le mécanisme qcow2, qui peut dégrader les performances I/O au fil du temps
• Pas de protection intégrée : si un bit se corrompt sur le disque, vous ne le saurez pas (contrairement à ZFS)
• Performances prévisibles mais pas optimales : correct pour la plupart des usages, mais pas le plus rapide

Quand choisir Directory : c’est le choix idéal pour stocker vos ISO d’installation, vos sauvegardes, et vos templates de conteneurs. Pour ces usages, vous n’avez pas besoin de snapshots rapides ni de performances extrêmes. C’est aussi un bon choix si vous débutez et voulez quelque chose de simple à comprendre et dépanner.

LVM-thin — Le standard Proxmox

LVM-thin (Logical Volume Manager avec thin provisioning) est le choix par défaut de l’installateur Proxmox, et pour de bonnes raisons. Il offre un excellent équilibre entre fonctionnalités et simplicité.

Comment ça fonctionne concrètement : au lieu de stocker les disques VM comme des fichiers, LVM-thin crée des volumes logiques dans un “thin pool”. Le “thin” signifie que vous pouvez sur-allouer : créer 10 VM avec des disques de 100 Go chacune sur un pool de 500 Go, tant que l’espace réellement utilisé ne dépasse pas 500 Go.

Imaginez un hôtel qui a 100 chambres mais accepte 150 réservations parce qu’il sait que tout le monde ne viendra pas en même temps. C’est le même principe : vos VM ne remplissent pas leurs disques à 100% dès le premier jour.

Les avantages de LVM-thin :

• Snapshots instantanés : créer un snapshot prend une fraction de seconde, quelle que soit la taille du disque
• Thin provisioning : sur-allocation possible, vous ne “gaspillez” pas d’espace
• Bonnes performances : les volumes logiques sont plus efficaces que les fichiers qcow2 pour les I/O
• Pas de prérequis RAM : contrairement à ZFS, LVM-thin fonctionne très bien avec 4-8 Go de RAM

Les limites de LVM-thin :

• Le piège du thin pool plein : si vos VM écrivent plus que l’espace disponible, tout se fige. C’est l’erreur #1 des débutants avec LVM-thin.
• Pas de checksums : comme Directory, LVM-thin ne détecte pas la corruption silencieuse des données
• Gestion plus technique : agrandir un pool, récupérer de l’espace… demande de connaître quelques commandes LVM

Quand choisir LVM-thin : c’est le choix par défaut pour vos VM et conteneurs si vous avez un seul gros disque (ou si le RAID est géré par un contrôleur matériel). Les snapshots rapides sont précieux pour tester des mises à jour : snapshot → mise à jour → si ça casse, rollback en 2 secondes.

Le piège du thin pool à 100%

C’est l’incident le plus fréquent avec LVM-thin, et il est brutal.

Le thin provisioning vous permet de promettre plus d’espace qu’il n’en existe. C’est pratique, mais si vos VM écrivent jusqu’à saturer le pool :

1. Les écritures sur disque échouent
2. Les VM se figent ou plantent
3. Vous devez agrandir le pool en urgence, souvent en mode panique

La règle d’or : surveillez l’utilisation avec lvs -o lv_name,data_percent et agissez dès que data% dépasse 80%. À 90%, c’est l’alerte rouge. À 100%, c’est trop tard.

ZFS — L’intégrité avant tout

ZFS est bien plus qu’un système de fichiers : c’est un gestionnaire de volumes complet avec des garanties d’intégrité que les autres options n’offrent pas. C’est le choix des administrateurs qui ne veulent jamais perdre de données silencieusement.

Comment ça fonctionne concrètement : ZFS gère directement vos disques physiques, sans passer par des partitions ou du RAID matériel. Il crée un “pool” (équivalent d’un RAID logiciel) et expose des “datasets” ou “zvols” à Proxmox. Chaque bloc de données est protégé par un checksum : si un bit se corrompt, ZFS le détecte et, en mode mirror/raidz, le corrige automatiquement.

Les avantages de ZFS :

• Intégrité garantie : chaque bloc est vérifié par un checksum. La corruption silencieuse (“bit rot”) est détectée et corrigée.
• Snapshots instantanés et efficaces : comme LVM-thin, mais avec la compression en plus
• Compression native : LZ4 par défaut, quasi gratuit en CPU, économise 20-40% d’espace selon les workloads
• RAID logiciel intégré : mirror (équivalent RAID1), raidz (équivalent RAID5), raidz2 (équivalent RAID6)
• Scrub : vérification périodique de l’intégrité de toutes vos données

Les limites de ZFS :

• Consommation RAM : ZFS utilise la RAM pour son cache de lecture (ARC). Il peut prendre jusqu’à 50% de la RAM disponible par défaut.
• Incompatible avec les contrôleurs RAID matériels : ZFS veut voir les disques bruts. Si vous avez un contrôleur RAID matériel, configurez-le en mode HBA/JBOD.
• Complexité : plus de concepts à maîtriser (pools, vdevs, datasets, ashift…)
• Performances d’écriture : le checksum et la copy-on-write ont un coût, surtout sur des disques lents

Quand choisir ZFS : c’est le choix idéal si vous avez au moins 8 Go de RAM et 2 disques identiques pour faire un mirror. L’intégrité des données devient alors votre priorité, et ZFS vous la garantit. C’est aussi excellent si vous voulez la compression native pour économiser de l’espace.

ZFS et RAM — ce qu'il faut savoir

ZFS utilise la RAM pour son cache de lecture (ARC). Ce n’est pas un bug, c’est une feature : plus l’ARC est grand, plus les lectures sont rapides.

Par défaut, ZFS peut utiliser jusqu’à 50% de la RAM disponible pour l’ARC. Avec 16 Go de RAM, ça laisse 8 Go pour vos VM — généralement suffisant pour un homelab.

Recommandations pratiques :

• Minimum : 8 Go de RAM totale
• Confortable : 16 Go de RAM
• Règle empirique : prévoyez environ 1 Go de RAM par To de stockage ZFS, mais ce n’est pas une règle stricte

Si vous avez seulement 4-6 Go de RAM, préférez LVM-thin. Vous pourrez toujours migrer vers ZFS plus tard en ajoutant de la RAM.

Tableau récapitulatif : quel backend pour quelle situation ?

Votre situation	Backend recommandé	Pourquoi ce choix
Homelab débutant, 1 disque	LVM-thin	Déjà installé par défaut, snapshots rapides, simple
Stocker ISO et backups	Directory (ext4)	Pas besoin de snapshots rapides, simplicité maximale
Données critiques, 2+ disques, 8 Go+ RAM	ZFS mirror	Intégrité garantie, redondance, compression
Serveur avec peu de RAM (4-6 Go)	LVM-thin	ZFS consommerait trop de RAM
Vous ne savez pas	LVM-thin	C’est le défaut de Proxmox pour de bonnes raisons

Glissez pour voir

Arbre de décision visuel

Ce schéma résume le processus de décision en fonction de votre configuration matérielle :

Créer vos storages

Maintenant que vous savez quel backend choisir, passons à la pratique. Cette section vous guide pas à pas pour créer chaque type de storage.

Préparer un disque

Avant de créer un storage, vous devez identifier les disques disponibles sur votre serveur. Cette étape est cruciale pour éviter d’effacer accidentellement votre système.

1. Accédez à la liste des disques

   Dans l’interface Proxmox, sélectionnez votre nœud dans l’arborescence de gauche, puis cliquez sur Disks dans le menu.

   Vous voyez la liste de tous les disques physiques détectés par le système : leur taille, leur modèle, et leur état d’utilisation.

2. Identifiez le disque système — NE PAS TOUCHER

   Le disque où Proxmox est installé est généralement /dev/sda ou /dev/nvme0n1. Il contient les partitions système (boot, swap) et souvent un storage local-lvm pré-configuré.

   Règle absolue : ne reformatez jamais ce disque, vous perdriez votre installation Proxmox.

3. Repérez les disques disponibles

   Les disques utilisables sont ceux marqués “unused” ou sans partition. Ce sont vos candidats pour créer de nouveaux storages.

   Si vous testez dans une VM avec des disques virtuels, ils apparaîtront ici comme de vrais disques physiques.

4. Effacez les données existantes (si nécessaire)

   Si un disque contient des données d’une ancienne installation (partitions, LVM, ZFS…), vous devez les effacer avant de créer un nouveau storage :

   • Sélectionnez le disque
   • Cliquez sur Wipe Disk
   • Confirmez — cette opération est irréversible

   Proxmox efface les signatures de partitions, ce qui “libère” le disque pour une nouvelle utilisation.

Créer un Directory storage (ext4/XFS)

Le Directory storage est idéal pour stocker vos ISO d’installation et vos sauvegardes. Voici comment le créer sur un disque dédié.

1. Créez le système de fichiers

   Dans Nœud → Disks, sélectionnez votre disque disponible, puis cliquez sur Create: Directory.

   Une fenêtre s’ouvre avec les options suivantes :

   • Filesystem : choisissez ext4 (le standard Linux, fiable et bien supporté) ou XFS (meilleur pour les très gros fichiers, mais moins courant)
   • Name : donnez un nom explicite comme backup-local ou iso-storage

   Cliquez sur Create. Proxmox formate le disque et monte automatiquement le nouveau système de fichiers.

2. Vérifiez que le storage est créé

   Allez dans Datacenter → Storage. Votre nouveau storage doit apparaître dans la liste avec :

   • Le type dir
   • L’espace total et disponible
   • Le chemin de montage (généralement /mnt/pve/nom-du-storage)

3. Configurez les content types

   Par défaut, un Directory storage accepte tous les types de contenu. Pour un usage “ISO et backups”, affinez :

   • Sélectionnez le storage dans la liste
   • Cliquez sur Edit
   • Dans Content, cochez uniquement : ISO image, VZDump backup file, Container template
   • Cliquez sur OK

   Cette restriction n’est pas obligatoire, mais elle évite de stocker accidentellement des disques VM sur ce storage (qui serait moins performant pour ça).

Résultat : vous avez maintenant un storage dédié pour vos ISO et sauvegardes. Quand vous téléchargerez une ISO ou ferez un backup, vous pourrez choisir ce storage comme destination.

Créer un LVM-thin storage

Si vous avez un disque dédié aux VM et que vous voulez bénéficier des snapshots rapides, créez un LVM-thin storage.

1. Créez le thin pool

   Dans Nœud → Disks → LVM-Thin, cliquez sur Create: Thinpool.

   Les options disponibles :

   • Disk : sélectionnez le disque à utiliser
   • Name : donnez un nom explicite comme vm-storage ou ssd-thin

   Cliquez sur Create. Proxmox crée un Volume Group et un Thin Pool sur ce disque, puis configure automatiquement un storage Proxmox.

2. Vérifiez la création

   Dans Datacenter → Storage, votre nouveau storage apparaît avec :

   • Le type lvmthin
   • L’espace total du thin pool
   • Les content types par défaut : Disk image et Container

3. Comprenez le thin pool existant (local-lvm)

   Si vous avez installé Proxmox avec les options par défaut, vous avez déjà un storage local-lvm de type LVM-thin sur votre disque système.

   Ce storage est parfaitement utilisable pour vos premières VM. Vous n’êtes pas obligé d’en créer un nouveau — sauf si vous voulez séparer les VM sur un disque dédié.

Vous avez déjà local-lvm ?

L’installation standard de Proxmox crée automatiquement un storage local-lvm sur le disque système. C’est un LVM-thin prêt à l’emploi.

Pour un homelab simple, utilisez-le directement pour vos premières VM. Vous pourrez toujours ajouter un second storage plus tard si vous ajoutez des disques.

Comment surveiller un thin pool :

# Voir l'utilisation du thin pool
lvs -o lv_name,data_percent,metadata_percent

# Exemple de sortie :
#   LV      Data%  Meta%
#   data    45.32  8.21

Si Data% approche de 80%, il est temps d’agir (supprimer des snapshots inutiles, agrandir le pool, ou ajouter un disque).

Créer un pool ZFS

Pour bénéficier de l’intégrité des données et des fonctionnalités avancées de ZFS, créez un pool ZFS. Cette procédure suppose que vous avez au moins un disque disponible (idéalement deux pour un mirror).

1. Créez le pool ZFS

   Dans Nœud → Disks → ZFS, cliquez sur Create: ZFS.

   Les options importantes :

   • RAID Level : c’est le niveau de redondance
     • Single : 1 disque, aucune redondance (pour tests uniquement)
     • Mirror : 2 disques identiques, équivalent RAID1 (recommandé pour débuter)
     • RAID-Z : 3+ disques, équivalent RAID5 (1 disque de parité)
     • RAID-Z2 : 4+ disques, équivalent RAID6 (2 disques de parité)
   • Disks : sélectionnez les disques à inclure dans le pool
   • Name : le nom du pool (par convention, souvent tank ou rpool)
   • Compression : laissez sur on — la compression LZ4 est quasi gratuite en CPU et économise 20-40% d’espace

2. Vérifiez la création en ligne de commande

   Ouvrez un shell sur votre nœud (via l’interface web : Nœud → Shell) et tapez :

   zpool status tank

   Vous devez voir :

   • state: ONLINE — le pool est sain
   • La liste des disques avec leur état

   Si vous voyez DEGRADED ou FAULTED, quelque chose ne va pas (disque défaillant, erreur de configuration).

3. Le storage est automatiquement créé

   Contrairement aux autres backends, ZFS crée automatiquement un storage Proxmox du même nom que le pool. Vérifiez dans Datacenter → Storage que le storage tank (ou le nom que vous avez choisi) apparaît.

Pourquoi activer la compression ?

La compression LZ4 est le meilleur rapport gain/coût que vous trouverez :

• Quasi invisible en termes de CPU (< 1% d’overhead sur des CPU modernes)
• Économise 20-40% d’espace selon le type de données
• Peut même améliorer les performances (moins de données à lire/écrire sur le disque)

Il n’y a pratiquement aucune raison de la désactiver, sauf si vous stockez des données déjà compressées (vidéos, images).

Valider que tout fonctionne

Après avoir créé vos storages, prenez quelques minutes pour vérifier que tout est bien configuré. Un storage mal configuré peut causer des problèmes subtils plus tard.

Checklist de validation

Parcourez cette liste pour chaque storage créé :

• Le storage apparaît dans Datacenter → Storage
• L’espace affiché correspond à la réalité du disque
• Les content types sont corrects pour l’usage prévu
• (ZFS) La commande zpool status affiche ONLINE
• (LVM-thin) La commande lvs montre le thin pool avec de l’espace libre

Commandes de diagnostic rapide

Ces commandes vous donnent une vue d’ensemble de vos storages en quelques secondes :

# Vue globale de tous les storages Proxmox
pvesm status

# Exemple de sortie :
# Name             Type     Status           Total            Used       Available        %
# backup-local     dir      active       234567890         1234567       233333323    0.53%
# local            dir      active        98765432        12345678        86419754   12.50%
# local-lvm        lvmthin  active       500000000       150000000       350000000   30.00%

# Pour LVM-thin : surveiller l'utilisation du thin pool
lvs -o lv_name,data_percent,metadata_percent
# Alerte si data% > 80%

# Pour ZFS : état détaillé du pool
zpool status
# Doit afficher "state: ONLINE"

# Pour ZFS : utilisation de l'espace
zpool list
# Montre la capacité, l'utilisation, et la fragmentation

Test fonctionnel : créer une VM de test

Le meilleur test, c’est d’utiliser réellement le storage :

1. Créez une VM de test (pas besoin d’installer un OS, juste les paramètres par défaut)
2. À l’étape Disks, choisissez votre nouveau storage
3. Terminez la création de la VM
4. Vérifiez dans VM → Hardware que le disque apparaît bien sur le bon storage
5. (Optionnel) Créez un snapshot pour tester cette fonctionnalité
6. Supprimez la VM de test

Si tout fonctionne, votre storage est opérationnel et prêt pour vos vraies VM.

Pièges et incidents

Le stockage est un domaine où les erreurs ont des conséquences sérieuses. Voici les incidents les plus fréquents et comment les éviter (ou les résoudre).

Tableau des problèmes courants

Problème	Symptôme	Cause	Solution
Thin pool plein	VM figées, I/O errors dans les logs	Sur-allocation excessive, pas de surveillance	Agrandir le pool + configurer alertes à 80%
ZFS + RAM insuffisante	Système très lent, swap utilisé en permanence	ARC consomme trop de RAM	Limiter l’ARC ou migrer vers LVM-thin
ZFS sur RAID matériel	Performances erratiques, erreurs aléatoires	Double abstraction, ZFS ne voit pas les vrais disques	Reconfigurer le contrôleur en HBA/JBOD
Confusion snapshot/backup	Performances dégradées après plusieurs snapshots	Les snapshots ne sont pas des backups	Supprimer les vieux snapshots, utiliser PBS pour les vrais backups
VM et backups mélangés	Pool saturé par les backups	Design inadapté	Séparer sur 2 storages distincts

Glissez pour voir

Urgence : thin pool à 100%

C’est l’incident le plus stressant avec LVM-thin. Quand le thin pool atteint 100% :

1. Les écritures échouent — les VM ne peuvent plus écrire sur leurs disques
2. Les VM se figent — elles attendent indéfiniment que l’écriture réussisse
3. Vous devez agir immédiatement — agrandir le pool ou libérer de l’espace

Comment s’en sortir :

# Voir l'état actuel
lvs -o lv_name,data_percent

# Option 1 : supprimer des snapshots inutiles (libère de l'espace)
# Dans l'UI : VM → Snapshots → supprimer les vieux snapshots

# Option 2 : agrandir le pool (si vous avez de l'espace sur le VG)
lvextend -L +50G pve/data

# Option 3 : supprimer une VM non critique
# Dans l'UI : supprimer une VM de test

Prévention : configurez une alerte qui vous notifie dès que data% dépasse 80%. À 90%, agissez. Ne laissez jamais atteindre 100%.

Bonnes pratiques

Ces recommandations viennent de l’expérience d’exploitation. Suivez-les pour éviter les problèmes courants.

Séparez VM et backups

C’est la règle la plus importante pour un design sain :

• Storage VM : content types images et rootdir — optimisé pour les performances
• Storage backup : content types backup, iso, vztmpl — optimisé pour la capacité

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

Nommez vos storages explicitement

Des noms clairs évitent les erreurs et facilitent le travail en équipe :

❌ Nom vague	✅ Nom explicite	Pourquoi c’est mieux
local	local-vm	On sait que c’est pour les VM
storage1	ssd-fast	On connaît le type de disque
zfs	tank-data	Nom du pool + usage
backup	backup-local ou backup-nfs	On distingue local vs réseau

Glissez pour voir

Surveillez vos storages

La surveillance évite les surprises :

Backend	Quoi surveiller	Seuil d’alerte	Commande
LVM-thin	data% du thin pool	80% warning, 90% critique	lvs -o lv_name,data_percent
ZFS	Utilisation + état du pool	80% warning, scrub mensuel	zpool list, zpool status
Directory	Espace disque classique	80% warning	df -h

Glissez pour voir

Pour ZFS, planifiez un scrub mensuel qui vérifie l’intégrité de toutes vos données :

# Lancer un scrub (peut prendre plusieurs heures selon la taille)
zpool scrub tank

# Vérifier l'avancement et les résultats
zpool status tank

Référence : content types

Chaque storage Proxmox définit les types de contenu qu’il peut accueillir. Voici la liste complète :

Content type	Description	Usage typique
images	Disques virtuels des VM (qcow2, raw, vmdk…)	Storage VM principal
rootdir	Systèmes de fichiers des conteneurs LXC	Storage VM (avec images)
iso	Images ISO pour installer des OS	Storage dédié ISO/backup
backup	Sauvegardes VZDump de VM/CT	Storage dédié backup
vztmpl	Templates de conteneurs (.tar.gz)	Storage ISO/backup
snippets	Fichiers divers (cloud-init, hooks…)	Storage VM ou dédié

Glissez pour voir

Un storage peut accepter plusieurs content types. Par exemple, local (le storage Directory créé à l’installation) accepte souvent iso, vztmpl, et snippets — mais pas images car c’est local-lvm qui s’en charge.

À retenir

Ce guide vous a présenté les trois backends de stockage local dans Proxmox. Voici les points essentiels à garder en mémoire :

1. Storage ≠ Disque : un storage est un objet logique configuré dans Proxmox, pas un disque physique. Cette distinction est fondamentale.

2. LVM-thin est le choix par défaut : snapshots rapides, thin provisioning, pas de prérequis RAM. Surveillez juste le thin pool pour éviter le piège des 100%.

3. ZFS si vous avez les ressources : avec 8 Go+ de RAM et 2 disques identiques, ZFS vous offre l’intégrité des données, la compression, et la redondance.

4. Directory pour la simplicité : parfait pour les ISO, backups, et templates. Pas besoin de snapshots rapides pour ces usages.

5. Séparez VM et backups : deux storages distincts évitent qu’un problème sur l’un n’affecte l’autre.

6. Surveillez vos storages : alertes à 80%, action à 90%. Ne laissez jamais un storage atteindre 100%.

Prochaines étapes

Maintenant que votre stockage est configuré, vous pouvez passer à la suite de la formation :

Interface Proxmox Naviguer efficacement dans l'interface web

Introduction Proxmox Comprendre l'architecture et les 4 piliers

×

📖 Voir la documentation →