Sur un serveur Linux récent, la simple idée de redimensionner une partition de production suffit encore à faire transpirer plus d’un administrateur. Le schéma classique disque/partition/système de fichiers reste rigide, peu indulgent avec les erreurs, et difficile à faire évoluer sans interruption. LVM, le gestionnaire de volumes logiques, change la donne en apportant une couche d’abstraction qui permet d’agrandir, réduire, déplacer ou prendre des instantanés de volumes presque comme on manipule des fichiers. Une fois qu’on a goûté à cette souplesse, revenir au partitionnement classique ressemble à travailler avec des disquettes.
Ce texte s’adresse aux équipes qui gèrent des bases de données, des applications métiers, des clusters de VM ou un simple homelab, et qui veulent une gestion des volumes propre, documentée et reproductible. Tout est orienté terrain : on part de disques physiques bruts, on construit des groupes de volumes, on découpe en volumes logiques, on formate, on monte, puis on apprend à agrandir, à réaliser des snapshots et à surveiller l’ensemble dans la durée. Pour garder un fil conducteur concret, un cas d’usage Postgres sert de fil rouge, avec des disques séparés pour les données, les journaux et les sauvegardes. L’objectif est simple : qu’un lundi matin à 6 h, agrandir un volume ou restaurer un snapshot ne soit plus un pari, mais une procédure maîtrisée.
- En bref
- LVM sous Linux permet de découpler les systèmes de fichiers des disques physiques et de gérer l’espace de stockage de façon flexible.
- Les briques clés sont les Physical Volumes (PV), les groupes de volumes (VG) et les volumes logiques (LV), auxquels s’ajoutent snapshots et thin provisioning.
- Une bonne architecture LVM sépare données, journaux et sauvegardes, et garde toujours une réserve d’espace non alloué dans les VG.
- Les opérations d’extention de volume sont simples, les opérations de réduction de volume demandent rigueur et tests, surtout avec ext4.
- En production, LVM prend tout son sens dès qu’on le combine avec du RAID ou un stockage redondant, du monitoring et un minimum d’automatisation.
Comprendre LVM Linux et l’architecture des volumes logiques
Avant de lancer la moindre commande, un détour par l’architecture de LVM Linux évite bien des erreurs. LVM2, qui équipe aujourd’hui la quasi-totalité des distributions, ajoute une couche entre les disques physiques et les systèmes de fichiers, de la même manière qu’un switch VLAN abstrait les liens physiques d’un réseau. Cette couche découpe le stockage en unités logiques, indépendantes de la géométrie réelle des disques.
Premier niveau, les Physical Volumes (PV). Un PV correspond à un disque entier ou à une partition marquée de type LVM. Cela peut être un SSD local, un volume RAID, un LUN iSCSI ou Fibre Channel. Dans un datacenter, il n’est pas rare de voir des LUN de baie SAN directement convertis en PV, puis agrégés côté Linux. Le PV stocke les métadonnées LVM et expose une capacité continue en blocs, sans se préoccuper du reste.
Deuxième niveau, les groupes de volumes (VG). Un VG agrége un ou plusieurs PV en un espace unique. On peut le voir comme un « super disque » logique dans lequel on viendra piocher pour créer des volumes. C’est cette abstraction qui permet d’additionner un SSD de 100 Go et un disque magnétique de 2 To au sein d’un même pool, même si en pratique il vaut mieux éviter de mélanger des performances trop différentes pour un même service.
Troisième niveau, les volumes logiques (LV). Un LV est une tranche de capacité allouée dans un VG. Pour le système, un LV se comporte exactement comme un périphérique bloc classique : on le formate (ext4, XFS, Btrfs…), on le monte, on y stocke des données. La différence, c’est que sa taille et son emplacement peuvent évoluer dans le temps. Cette malléabilité est la raison pour laquelle beaucoup de bases de données et d’hyperviseurs recommandent explicitement LVM.
Pour fixer les idées, prenons une PME industrielle qui déploie un serveur Postgres pour sa traçabilité de production. L’infra équipe la machine de quatre disques : deux de 100 Go et deux de 50 Go. En LVM, ces disques deviennent quatre PV. On peut alors construire trois VG : un VG « PostgresData » qui regroupe les deux disques de 100 Go, un VG « PostgresLogs » sur un disque de 50 Go, et un VG « PostgresBackups » sur le dernier disque de 50 Go. Chaque VG héberge un LV : un pour les données, un pour les WAL, un pour les sauvegardes. Résultat : séparation claire des usages, extensions possibles par ajout de PV, et gestion beaucoup plus fine de la capacité.
LVM ne se limite pas à cet empilement PV/VG/LV. Deux fonctionnalités méritent une place à part. D’abord, le thin provisioning, qui permet de déclarer un LV de 1 To tout en n’allouant physiquement que l’espace réellement utilisé. Utilisé avec discernement, cela évite de surdimensionner des volumes pour des services qui consomment lentement. Mal maîtrisé, surtout sans monitoring, c’est une source de panne sèche brutale. Ensuite, les snapshots LVM, qui créent une vue instantanée d’un LV. Couplé à une base de données, ce mécanisme permet de figer un état cohérent pour une sauvegarde ou un test de migration, sans immobiliser l’application.
Certains administrateurs hésitent encore à adopter LVM, notamment sur de petits serveurs, au motif que « cela ajoute une couche de complexité ». Ce point de vue se comprend, mais il sous-estime le gain pratique lors du premier agrandissement de volume ou de la première restauration rapide depuis un snapshot. Un disque unique, partitionné en dur, donne une impression de simplicité qui disparaît le jour où la partition racine se retrouve pleine à 98 % en pleine campagne de production.
En résumé, LVM transforme un stockage figé en stockage modelable. Une fois les briques PV/VG/LV bien visualisées, le reste n’est qu’une affaire de commandes à connaître et de procédures à documenter. La suite du guide s’appuie justement sur ce modèle pour passer du concept à la mise en œuvre concrète.
Installation de LVM2 et premiers pas de gestion des volumes sous Linux
Avant de jouer avec les volumes logiques, il faut s’assurer que les outils LVM2 sont bien en place sur la distribution Linux utilisée. Sur la plupart des systèmes actuels, le paquet est déjà installé, surtout si l’on a choisi le partitionnement « guidé avec LVM » lors de l’installation. Une vérification rapide évite pourtant des surprises sur une VM minimale ou un conteneur un peu dépouillé.
La commande de base pour vérifier la présence du binaire consiste à interroger directement LVM :
Exemple de vérification :
sudo lvm version
Si la sortie affiche une version de type « LVM version: 2.03.xx », c’est gagné. Les lignes suivantes détaillent la version de la bibliothèque, du driver noyau et les options de compilation, ce qui permet de savoir si les fonctionnalités de thin provisioning sont intégrées. Si la commande échoue, il faut passer par le gestionnaire de paquets.
Sur un serveur Debian ou Ubuntu, l’installation repose sur le couple apt update / apt install. LVM2 se trouve dans les dépôts standards et ne nécessite aucun dépôt additionnel :
sudo apt update
sudo apt install lvm2
Sur une base Red Hat (RHEL, Rocky, Alma, CentOS Stream), l’approche est similaire avec dnf ou yum selon la version. Sur ces plateformes, le paquet s’appelle généralement aussi lvm2, parfois préinstallé si l’on a laissé l’installateur gérer le stockage avec LVM. Dans tous les cas, un passage par « lvm version » après installation permet de confirmer que tout est cohérent.
Un point souvent négligé concerne les services associés. Avec systemd, deux unités sont particulièrement utiles : lvm2-monitor et, sur certaines distributions, lvm2-lvmetad. Leur activation permet de gérer correctement la détection automatique des volumes au démarrage, évitant les boot qui s’éternisent faute de VG activé. Sur un serveur de base de données, ce type de détail fait la différence entre un redémarrage de 30 secondes et cinq minutes de diagnostic à distance.
Une fois LVM2 opérationnel, la première phase consiste à repérer les disques physiques disponibles. La commande lsblk donne une vue claire des périphériques bloc et de leur utilisation actuelle. Sur la VM Postgres de l’exemple, lsblk renverra typiquement un disque système vda, déjà partitionné et monté, ainsi que quatre disques vides /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd. Ce sont ces derniers qui serviront de base à la structure LVM.
La conversion de ces disques en PV se fait en une ligne :
sudo pvcreate /dev/sda /dev/sdb /dev/sdc /dev/sdd
À ce stade, aucune donnée n’est encore formatée ni montée. L’opération inscrit simplement des métadonnées LVM sur les disques, indiquant qu’ils appartiennent désormais à l’univers des volumes physiques. Un pvdisplay ou un pvs permet de vérifier que chaque disque est bien reconnu, avec une taille, un UUID et le champ VG vide, puisqu’il n’a pas encore été rattaché à un groupe.
Cette étape d’initialisation pose les fondations. Beaucoup de problèmes rencontrés plus tard (PV non détectés au boot, erreurs lors de l’activation d’un VG) ont pour origine un mélange entre anciens labels de partitions et métadonnées LVM à moitié effacées. Sur une machine de test, prendre quelques minutes pour créer puis supprimer un PV, via pvcreate et pvremove, permet de voir concrètement ce que rapportent les commandes d’inspection.
Le reste du guide s’appuiera sur ces commandes de base. Une fois qu’elles sont familières, la création de groupes de volumes et la découpe en LV deviennent de simples opérations d’assemblage. C’est à cette étape que la topologie cible (Postgres, VM, fichiers, sauvegardes) commence à se traduire en LVM concret.
Construire une architecture LVM pour un serveur Postgres de production
Avec les briques de base en place, il est temps de passer à un cas d’usage réaliste : un serveur Postgres qui doit tenir plusieurs années, avec des volumes séparés pour les données, les journaux de transactions et les sauvegardes. Beaucoup d’équipes commencent par tout mettre sur une seule partition, puis se retrouvent coincées lorsque les WAL saturent le disque. LVM permet d’éviter ce piège en structurant le stockage dès le départ.
Reprenons les quatre disques bruts évoqués plus haut. Après pvcreate, ils sont visibles comme quatre PV indépendants. La première décision consiste à définir les groupes de volumes. Une approche efficace consiste à créer trois VG :
sudo vgcreate PostgresData /dev/sda /dev/sdb
sudo vgcreate PostgresLogs /dev/sdc
sudo vgcreate PostgresBackups /dev/sdd
Le VG PostgresData agrège deux disques physiques de 100 Go, soit près de 200 Go bruts, qui serviront au stockage principal des bases. Les journaux (WAL) sont isolés sur un VG de 50 Go dédié, ce qui simplifie leur supervision et limite l’impact d’une poussée d’écriture sur le reste du système. Enfin, un dernier VG héberge les backups locales, avant envoi éventuel vers un stockage de plus long terme.
Une commande vgdisplay ou vgs permet de vérifier que chaque groupe existe, avec sa capacité totale et l’espace libre. À ce stade, aucun volume logique n’est encore créé. On dispose simplement de trois pools prêts à être découpés.
Vient ensuite la création des LV dans chaque VG. Pour l’exemple, une répartition courante peut ressembler à ceci :
sudo lvcreate -L 150G -n PostgresData PostgresData
sudo lvcreate -L 40G -n PostgresLogs PostgresLogs
sudo lvcreate -L 45G -n PostgresBackups PostgresBackups
On laisse volontairement quelques gigaoctets libres dans chaque VG (20 Go dans PostgresData, 10 Go dans PostgresLogs, 5 Go dans PostgresBackups). Cette réserve n’est pas du luxe : elle sert de marge de manœuvre pour une future extention de volume ou la création d’un snapshot temporaire au moment d’une mise à jour. Un VG rempli à 100 % est un VG difficile à faire évoluer.
Une fois les LV présents, lvdisplay ou lvs offre une vue synthétique : nom, taille, VG d’appartenance, attributs d’activation. On dispose alors de trois périphériques blocs prêts à être formatés. Sur un serveur Postgres, le choix du système de fichiers se fait souvent entre ext4 et XFS. Les deux fonctionnent correctement ; certains privilégient XFS pour les gros volumes et les charges lourdes, d’autres restent sur ext4 pour la familiarité et les outils de réparation.
Pour rester cohérent avec les commandes de base évoquées plus haut, prenons ext4 :
sudo mkfs.ext4 /dev/PostgresData/PostgresData
sudo mkfs.ext4 /dev/PostgresLogs/PostgresLogs
sudo mkfs.ext4 /dev/PostgresBackups/PostgresBackups
Formatés, les LV deviennent des systèmes de fichiers classiques. Il reste à les monter sur des points cohérents avec l’organisation voulue. Une hiérarchie simple peut ressembler à ceci :
sudo mkdir -p /data /logs /backups
sudo mount /dev/PostgresData/PostgresData /data
sudo mount /dev/PostgresLogs/PostgresLogs /logs
sudo mount /dev/PostgresBackups/PostgresBackups /backups
Une commande df -h donne alors une photographie lisible : trois nouveaux systèmes de fichiers, quasi vides, prêts à être intégrés à la configuration Postgres. Il est prudent, avant toute mise en production, d’ajouter les entrées correspondantes dans /etc/fstab, en s’assurant que les noms de périphériques choisis sont stables (par exemple en utilisant les UUID plutôt que les chemins /dev/mapper, selon la politique de l’équipe).
Pour visualiser les différents niveaux de cette architecture, un tableau comparatif aide souvent les équipes qui découvrent LVM :
| Élément | Rôle dans LVM Linux | Exemple dans le cas Postgres |
|---|---|---|
| Physical Volume (PV) | Support physique ou logique de base, exposant une capacité brute à LVM. | /dev/sda, /dev/sdb, /dev/sdc, /dev/sdd initialisés avec pvcreate. |
| Volume Group (VG) | Pool logique qui agrège un ou plusieurs PV et fournit l’espace pour les LV. | PostgresData, PostgresLogs, PostgresBackups créés avec vgcreate. |
| Logical Volume (LV) | Volume logique découpé dans un VG, formaté et monté comme « pseudo-partition ». | /dev/PostgresData/PostgresData, /dev/PostgresLogs/PostgresLogs, /dev/PostgresBackups/PostgresBackups. |
À partir de ce schéma, les questions habituelles des équipes changent de nature. On ne se demande plus « quelle taille donner à /dev/sda2 pour être tranquille », mais « combien garder en réserve dans PostgresData pour absorber une montée en charge ». Cette bascule est saine : on quitte une logique figée de partitionnement pour entrer dans une logique d’allocation flexible et réversible.
Pour un administrateur, le bénéfice immédiat apparaît le jour où la direction annonce un nouveau module applicatif très gourmand en stockage. Avec LVM, on peut ajouter un disque, l’intégrer à un VG et étendre le LV concerné sans bouleverser le reste. La section suivante aborde justement ces opérations de croissance et de maintenance au quotidien.
Commandes LVM essentielles pour l’extention, la réduction et la surveillance des volumes logiques
Une fois l’architecture en place, la vraie vie commence : la base grossit, les journaux gonflent lors d’une campagne de tests, les sauvegardes locales débordent. C’est là que les commandes LVM quotidiennes prennent tout leur sens. Sans elles, LVM reste une jolie théorie. Utilisées avec méthode, elles transforment la gestion des volumes en routine maîtrisée.
Premier réflexe avant toute opération : observer l’état actuel. Les commandes « complètes » pvdisplay, vgdisplay, lvdisplay donnent un niveau de détail utile pour diagnostiquer un problème. Pour une vision rapide, leurs équivalents simplifiés pvs, vgs, lvs suffisent largement. Par exemple, un vgs sur notre serveur Postgres affichera les tailles totales des VG et l’espace libre restant, ce qui permet de savoir tout de suite si une extention de volume est possible sans ajouter de disque.
Quand un VG commence à être à l’étroit, la solution la plus simple consiste à ajouter un nouveau PV. Supposons qu’un disque /dev/sdf de 100 Go vient d’être attaché. La séquence est classique :
sudo pvcreate /dev/sdf
sudo vgextend PostgresData /dev/sdf
Un nouveau pvs montrera alors /dev/sdf rattaché au VG PostgresData, et vgs indiquera une augmentation nette de VFree. Pas besoin de retoucher aux LV existants pour l’instant : le VG se contente d’augmenter son réservoir. C’est un point souvent sous-estimé : LVM sépare vraiment la capacité disponible (VG) de la capacité allouée (LV).
Pour agrandir un LV, la commande habituelle est lvextend (ou lvresize, plus générique). Si les données Postgres saturent plus vite que prévu, on peut ajouter 20 Go à chaud :
sudo lvextend -L +20G /dev/PostgresData/PostgresData
sudo resize2fs /dev/PostgresData/PostgresData
La première commande modifie la taille du LV dans LVM. La seconde ajuste le système de fichiers ext4 pour qu’il occupe toute la capacité. Sur ext4, cette opération peut se faire à chaud tant que le système de fichiers est monté en lecture/écriture et que le noyau la supporte, ce qui est le cas sur les distributions actuelles. XFS se redimensionne aussi à la hausse sans démontage, mais avec xfs_growfs.
La réduction de volume est plus délicate. Elle demande de commencer par réduire le système de fichiers, puis seulement ensuite le LV, sous peine de corruption de données. Avec ext4, la réduction doit en plus se faire à froid, donc système de fichiers démonté. La séquence typique ressemble à ceci :
umount /data
e2fsck -f /dev/PostgresData/PostgresData
resize2fs /dev/PostgresData/PostgresData 100G
lvreduce -L 100G /dev/PostgresData/PostgresData
resize2fs /dev/PostgresData/PostgresData
mount /data
Ce type d’opération mérite d’être testé sur un environnement de préproduction ou une VM de labo avant de s’attaquer à la prod. Beaucoup d’équipes font d’ailleurs le choix assumé de ne quasiment jamais réduire les LV, préférant jouer sur les snapshots et la croissance maîtrisée. C’est un choix raisonnable : raccourcir un LV pour « récupérer » quelques dizaines de gigaoctets est parfois plus risqué que d’ajouter un disque.
Les snapshots LVM occupent une place à part dans la boîte à outils. Ils permettent de figer l’état d’un LV à un instant T, puis de continuer à écrire sur l’original. Les blocs modifiés sont alors recopiés dans le snapshot, ce qui augmente sa taille au fil des changements. Pour préparer une mise à jour Postgres, par exemple, on peut créer un snapshot de 10 Go sur les données :
sudo lvcreate –size 10G –snapshot –name BeforeUpgrade /dev/PostgresData/PostgresData
La mise à jour peut alors être testée. En cas de souci, il est possible de restaurer l’état précédent en montant le snapshot et en procédant à une bascule contrôlée, ou, plus radicalement, en revenir à l’original si l’on a arrêté le service. L’important est de surveiller la consommation du snapshot avec lvs : si la Data% approche de 100 %, le snapshot n’est plus exploitable et doit être supprimé.
Pour finir, un mot sur la surveillance. LVM ne remplace pas les outils de monitoring habituels, mais il expose des métriques utiles à collecter. Beaucoup d’équipes exportent les sorties de vgs et lvs dans Prometheus via un script régulier, puis affichent dans Grafana l’espace libre par VG, la taille des LV critiques, la présence de snapshots. Une alerte simple du type « VFree
En pratique, les administrateurs qui maîtrisent vraiment LVM utilisent une poignée de commandes au quotidien, mais ils les connaissent par cœur. Pour mémoire, une liste courte et utile peut servir de pense-bête sur un wiki interne :
- pvs / vgs / lvs pour l’état synthétique des PV, VG, LV.
- pvcreate, vgcreate, lvcreate pour l’initialisation et la création.
- vgextend, lvextend, lvresize pour l’agrandissement des pools et volumes.
- lvremove, vgreduce, pvremove pour le nettoyage et le retrait de ressources.
- lvcreate –snapshot et lvremove pour le cycle de vie des snapshots.
Une fois ces réflexes installés, LVM cesse d’être un sujet d’angoisse et devient un allié au quotidien pour garder les serveurs de base de données à l’aise, même lorsque la charge et les volumes de données évoluent plus vite que prévu.
Bonnes pratiques LVM en production : planification, performance et sécurité
Mettre LVM en place est une étape. L’exploiter sereinement en production pendant des années en est une autre. Sur ce terrain, la différence entre une architecture robuste et un bricolage tient souvent à quelques bonnes pratiques simples, appliquées avec constance. Le cas du serveur Postgres fournit une base, mais les mêmes principes valent pour un cluster de VM, une ferme de microservices ou un NAS maison.
La première étape réellement structurante consiste à planifier. Pas un plan au sens d’un diagramme parfait qui survivra trois jours, mais quelques principes clairs : quels services méritent leur propre VG, quelle part de la capacité totale reste en réserve, quel est le profil de croissance attendu de chaque application. Dans une usine où la traçabilité génère un flux régulier de données, PostgresData grossira de façon linéaire, tandis que PostgresLogs aura des pics. Il est logique de prévoir une marge plus généreuse sur les journaux.
Sur le volet performance, la séparation des flux reste un levier concret. Mettre les WAL sur un VG différent, donc potentiellement sur un type de disque plus rapide, réduit les risques de contention entre lectures de données et écritures de journaux. Dans certaines PME, un choix raisonnable consiste à placer PostgresData sur des SSD SATA, PostgresLogs sur NVMe, et PostgresBackups sur des HDD lents mais bon marché. LVM accepte cette diversité ; il suffit de configurer les VG en conséquence.
Un point sur lequel beaucoup de déploiements pèchent encore : l’absence de RAID ou de redondance sous-jacente. LVM ne fournit pas, en soi, de tolérance aux pannes disque, même si des fonctionnalités de mirroring existent. Utiliser un VG qui s’étend sur deux disques indépendants sans RAID revient à jouer avec le feu : la perte d’un seul disque rend le VG incohérent et entraîne la perte de tous les LV qui y puisent. En clair, LVM doit reposer sur une couche de stockage déjà robuste (RAID matériel, mdadm, ZFS, stockage SAN redondant).
Du côté des snapshots, la tentation est forte de s’en servir comme mécanisme de sauvegarde permanent. C’est une mauvaise idée. Un snapshot LVM vit sur le même ensemble de disques que le LV d’origine. Un crash disque ou un incident LVM sérieux les affectera tous les deux. Les snapshots sont parfaits pour les opérations temporaires : sauvegarde rapide vers un autre support, tests d’upgrade, audits. Pour la sauvegarde long terme, il faut les combiner avec une copie vers un autre stockage, idéalement offsite.
Côté sécurité, deux aspects méritent de l’attention. D’abord, le chiffrement. Sur des environnements qui manipulent des données sensibles, chiffrer les LV avec LUKS reste une bonne pratique. Le pattern habituel consiste à chiffrer le PV en entier, puis à placer le VG et les LV par-dessus. Cela permet de garder toutes les fonctionnalités LVM tout en protégeant les données au repos. Ensuite, la gestion des droits et des accès : même si LVM s’opère en root, documenter les commandes autorisées dans les procédures internes évite les initiatives malheureuses (par exemple un lvreduce lancé trop vite en production).
Pour illustrer l’impact pragmatique de ces choix, prenons un cas réel fréquent : une équipe déploie un serveur de fichiers avec LVM, sans RAID, en étendant un VG sur deux disques de 4 To indépendants. Tout fonctionne bien pendant deux ans, jusqu’à ce que l’un des disques tombe en panne. Le VG devient inconsistant, les LV inaccessibles. Avec le même budget matériel, une configuration RAID 1 ou RAID 5 en dessous de LVM aurait permis de perdre un disque sans interruption majeure. LVM est alors accusé à tort, alors que la responsabilité vient surtout du design initial.
Sur le plan organisationnel, documenter les choix LVM dans le référentiel d’architecture évite aussi des frictions. Un diagramme simple montrant PV, VG, LV, systèmes de fichiers et points de montage rend les revues de changement plus fluides. Les nouveaux arrivants dans l’équipe comprennent plus vite pourquoi tel VG a été créé, pourquoi tel LV n’utilise pas toute la capacité, pourquoi certains snapshots sont réguliers et d’autres exceptionnels.
En croisant planification, performance, redondance et sécurité, LVM devient une couche de confort plus qu’un risque supplémentaire. Les surprises viennent alors beaucoup plus des applications elles-mêmes que du sous-système de stockage. Pour les équipes, c’est une transition appréciable : l’effort initial de conception est largement compensé par des années d’exploitation plus paisible.
Aller plus loin avec LVM : cas particuliers, automatisation et scénarios de croissance
Une fois les bases et les bonnes pratiques assimilées, certains scénarios avancés méritent d’être préparés à l’avance. Pas pour les rendre « automagiques », mais pour éviter d’improviser en pleine nuit. Trois cas reviennent régulièrement chez les clients : l’agrandissement d’un disque virtuel, la réorganisation d’un VG existant et l’automatisation de tâches répétitives autour de LVM.
Sur une VM hébergée, l’agrandissement de disque suit souvent la séquence suivante : l’équipe d’infra augmente la taille du disque virtuel dans l’hyperviseur, le système d’exploitation voit un disque plus grand, mais le PV et le VG restent à l’ancienne taille. Pour exploiter la nouvelle capacité, il faut d’abord demander au noyau de rescanner le périphérique, puis étendre la partition (si le PV est une partition), enfin exécuter pvresize pour adapter le PV aux nouveaux contours.
Un script simple peut aider à déclencher le rescan sur tous les disques SCSI exposés au noyau :
for disk in /sys/class/scsi_disk/*/device/rescan; do
echo 1 | sudo tee « $disk » >/dev/null
done
Ensuite, un outil comme cfdisk rend l’agrandissement de la partition plus lisible qu’un fdisk en mode texte brut. On choisit la partition LVM existante, on lui demande d’utiliser tout l’espace libre, on écrit la nouvelle table. Un appel à partprobe ou partx force le noyau à relire les partitions. À partir de là, pvresize /dev/sda2 (par exemple) permet à LVM de reconnaître que le PV s’étend désormais sur toute la partition.
Ce pattern est suffisamment courant pour mériter une procédure écrite, testée sur un environnement de labo. Beaucoup d’équipes commettent les mêmes erreurs les premières fois : oublier pvresize, ou tenter d’étendre directement un LV sans avoir agrandi le PV. Un document interne qui détaille les étapes, captures à l’appui, fait gagner un temps précieux lors de la première montée en capacité d’une VM critique.
Autre cas délicat : la réorganisation d’un VG. Une PME peut, par exemple, vouloir retirer un disque d’un VG pour le réutiliser ailleurs. Si le VG repose sur plusieurs PV, il faut d’abord migrer les extents LVM du disque ciblé vers les autres PV, avec pvmove, avant de l’exclure avec vgreduce. Cette opération tient plus du déplacement de mobilier dans un atelier que d’un simple coup de balai : il faut d’abord dégager la zone avant de retirer l’étagère. Là encore, LVM fournit l’outillage, mais l’équipe doit planifier et surveiller.
L’automatisation entre enfin en scène. Sur un parc de serveurs homogènes, écrire quelques scripts Bash ou playbooks Ansible pour :
- créer des PV et des VG selon un gabarit standard lorsqu’un nouveau serveur arrive ;
- provisionner des LV avec des tailles prédéfinies pour des bases, logs et backups ;
- configurer /etc/fstab et monter les systèmes de fichiers ;
évite des divergences et des erreurs de frappe. LVM s’intègre bien dans ce type d’outillage, car ses commandes sont scriptables et renvoient des codes de sortie clairs. Il devient alors possible de traiter la gestion des volumes comme du code d’infrastructure, versionné et relu.
Un dernier point mérite d’être évoqué : l’usage combiné de LVM et de filesystems plus riches comme Btrfs ou ZFS. Certains choisissent de superposer LVM et Btrfs, d’autres préfèrent laisser Btrfs ou ZFS gérer eux-mêmes les volumes, snapshots et RAID. Il n’existe pas de réponse universelle. Sur une équipe déjà à l’aise avec LVM, ajouter Btrfs par-dessus, uniquement pour ses snapshots, n’a pas toujours de sens. À l’inverse, sur un nouveau projet, partir directement avec ZFS peut simplifier certains aspects (compression, intégrité), mais impose d’autres contraintes.
En fin de compte, LVM reste un socle solide pour la majorité des scénarios Linux « classiques » : serveurs applicatifs, bases relationnelles, hyperviseurs KVM, stockage local en entreprise. Le combiner avec un peu d’automatisation, de monitoring et une discipline de documentation transforme une source potentielle de tracas en un élément calme de l’architecture, que l’on oublie presque… jusqu’au jour où il sauve la mise lors d’une croissance imprévue ou d’un rollback rapide grâce à un snapshot bien placé.
Pourquoi utiliser LVM sous Linux plutôt que des partitions classiques ?
LVM apporte une souplesse que le partitionnement traditionnel ne fournit pas. Il permet d’agrandir ou de réduire certains volumes (avec précautions), de créer des snapshots pour des sauvegardes rapides, et d’agréger plusieurs disques physiques dans un même groupe de volumes. Sur un serveur qui doit évoluer dans le temps, cette flexibilité réduit nettement le risque de se retrouver bloqué par une partition pleine au mauvais endroit.
LVM remplace-t-il le RAID pour la tolérance aux pannes disque ?
Non. LVM gère la disposition logique de l’espace disque mais n’assure pas, à lui seul, la redondance des données. Si un disque physique d’un VG tombe en panne, tous les volumes logiques qui l’utilisent sont potentiellement perdus. Pour la tolérance aux pannes, il faut s’appuyer sur du RAID matériel, mdadm, ZFS ou un stockage SAN redondant, puis placer LVM au-dessus.
Comment choisir la taille initiale de mes volumes logiques ?
La pratique courante consiste à allouer une taille confortable mais pas maximale, et à garder une réserve d’espace libre dans le groupe de volumes. Par exemple, sur un VG de 200 Go, créer un LV de 150 Go pour les données et laisser 50 Go libres permet d’absorber une croissance ou de créer ponctuellement un snapshot. Il est généralement plus sûr d’agrandir un volume que de le réduire ensuite.
Les snapshots LVM suffisent-ils comme stratégie de sauvegarde ?
Les snapshots LVM sont très utiles pour figer rapidement l’état d’un volume, notamment pour faire une copie cohérente vers un autre support. En revanche, ils vivent sur les mêmes disques que le volume d’origine et ne protègent pas contre une panne matérielle grave. Ils doivent donc s’inscrire dans une chaîne de sauvegarde plus large, avec des copies sur un stockage distinct, voire déporté géographiquement.
Peut-on utiliser LVM sur un serveur de petite taille ou un homelab ?
Oui, et c’est même une bonne façon d’apprendre. Sur une machine modeste, LVM simplifie déjà les agrandissements de volumes et les tests de configuration. Il suffit de rester raisonnable sur la complexité (quelques VG et LV bien nommés) et de documenter les commandes clés. Cette expérience se transfère ensuite facilement vers des environnements plus critiques.