Linux sans magie #47 — Réduire un volume LVM : précautions et risques

Dans le #46, nous avons étendu un Logical Volume (LV) et son filesystem. L'opération inverse paraît symétrique : si un LV de 60 GiB n'utilise que 15 GiB, pourquoi ne pas lui retirer 20 GiB ? Parce que réduire le périphérique bloc avant le filesystem peut détruire des données, même lorsque l'espace affiché par df paraît largement suffisant.

Cette étape de la série Linux sans magie n'est donc pas une recette universelle. Elle explique les couches en jeu, les contraintes des filesystems, les vérifications préalables et les conditions d'un laboratoire contrôlé. En production, la décision de réduire doit rester exceptionnelle et justifiée.

Comprendre ce que l'on veut récupérer

Dans notre exemple, une application conserve ses données sur /srv/app, monté depuis le LV /dev/vgdata/lvapp. Le LV mesure 60 GiB, le filesystem est ext4 et 15 GiB apparaissent utilisés. L'objectif envisagé serait de revenir à 40 GiB pour réattribuer les extents libérés à un autre LV du même Volume Group (VG).

VG vgdata
  ├── LV lvapp  : 60 GiB → ext4 → /srv/app
  ├── autres LV
  └── extents libres
             ↓ réduction envisagée
  LV lvapp  : 40 GiB → ext4 redimensionné
  + extents restitués au VG

Les tailles sont fictives. Les 15 GiB utilisés ne suffisent pas à garantir qu'une réduction à 40 GiB est possible : le filesystem contient aussi des métadonnées, des réservations et des structures internes. L'emplacement des données et la compatibilité de leur organisation sont plus importants qu'une simple soustraction.

Réduire un LV ne réduit pas automatiquement un disque physique, un volume cloud ou la facture associée. L'opération restitue d'abord des extents au VG. Le retrait d'un Physical Volume (PV) ou la réduction de capacité sous-jacente relèvent d'un autre projet, avec d'autres risques.

Deux objets distincts : filesystem et Logical Volume

Un LV expose une capacité de stockage ; le filesystem y organise les données. Lors d'une extension, le LV peut souvent grandir avant le filesystem. Lors d'une réduction, l'ordre devient critique.

Réduction admissible d'un ext4 compatible :
1. arrêter les écritures et démonter
2. vérifier et réduire le filesystem
3. réduire le LV sans couper la fin du filesystem
4. vérifier, remonter et valider les données

Si l'on commence par lvreduce sans préparation, des blocs que le filesystem considère encore comme appartenant à son espace peuvent disparaître. Une confirmation interactive n'est pas une protection contre ce scénario.

La commande lvreduce --resizefs demande à LVM de coordonner la réduction du filesystem via fsadm, lorsque la combinaison est prise en charge. Elle ne dispense ni d'une sauvegarde restaurable, ni d'une fenêtre d'arrêt, ni de contrôles préalables. Les versions et outils installés doivent être validés sur la distribution réellement utilisée.

Vérifier d'abord : ext4 n'est pas XFS

Le type de filesystem conditionne la décision.

Filesystem	Extension	Réduction
ext4	Possible en ligne sur configurations compatibles	Possible hors ligne, après démontage et vérifications
XFS	Possible en ligne sur filesystem monté	Pas de réduction en place prise en charge
Autre filesystem	Dépend de l'implémentation	Ne rien supposer sans documentation dédiée

Ne réduisez pas un LV contenant XFS en espérant que XFS suivra. La solution usuelle, si une capacité XFS plus petite est réellement nécessaire, consiste à créer un nouveau volume, y créer un filesystem adapté, transférer les données, les valider puis organiser la bascule applicative. Le redimensionnement direct n'est pas une option générique.

Pour un LV chiffré avec LUKS, un thin LV, un LV RAID, un snapshot, un filesystem root ou un stockage partagé, ce guide ne fournit pas de procédure de réduction. Il faut comprendre toutes les couches interposées avant d'agir.

Inventaire non destructif avant toute décision

Ces commandes ne modifient pas le stockage. Adapter les chemins à l'environnement réel ; ne jamais conclure à partir du seul nom d'un LV.

sudo lvs -o vg_name,lv_name,lv_size,lv_path,lv_attr
sudo vgs -o vg_name,vg_size,vg_free
lsblk -f
findmnt --target /srv/app -o SOURCE,TARGET,FSTYPE,OPTIONS
df -hT /srv/app
sudo blkid /dev/vgdata/lvapp

Confrontez lvs à findmnt et blkid : le périphérique qui doit changer est-il réellement celui contenant les données de l'application ? Un nom /dev/mapper/... peut cacher des couches supplémentaires. lsblk -f aide à visualiser les relations ; il ne prouve pas que la réduction est sûre.

df décrit l'espace utilisé selon le filesystem monté, et non le placement des blocs ni la taille minimale atteignable. Vérifiez également les volumes associés, les chemins de sauvegarde, les jobs de maintenance et le taux de croissance prévisible des données.

Prérequis d'une opération planifiée

Avant même de proposer une taille cible, exigez une sauvegarde restaurable validée par un test, une fenêtre d'indisponibilité acceptée, une procédure de redémarrage et des personnes habilitées à intervenir. Sur une VM, un snapshot hyperviseur peut aider à certains scénarios de récupération, mais ne remplace pas une sauvegarde applicativement cohérente et testée.

La réduction d'ext4 nécessite un filesystem démonté. En pratique, il faut arrêter proprement les services qui écrivent, contrôler les montages et planifier une intervention hors ligne. S'il s'agit du filesystem racine, préparez un environnement de maintenance adapté : n'essayez pas de démonter / depuis la session système normale.

Les commandes de validation de montage sont utiles avant l'arrêt :

findmnt --target /srv/app
sudo fuser -vm /srv/app

fuser signale des processus qui accèdent au point de montage. Il ne garantit pas l'absence de toute dépendance métier ; un administrateur doit également connaître les unités systemd et services liés.

Laboratoire contrôlé : comprendre l'ordre sans improviser

Le scénario suivant suppose un LV de test linéaire, déjà créé dans un VG de laboratoire, avec un filesystem ext4, aucune donnée de valeur, et une sauvegarde restaurable. Il ne doit pas être transposé tel quel à /srv/app en production. Les commandes modifiant le stockage sont présentées comme plan d'intervention à valider, pas comme script prêt à lancer.

Étape 1 — constater le démontage

Après arrêt des applications et démontage organisé du point de montage de test, l'opérateur doit confirmer que le périphérique n'est plus monté :

findmnt --source /dev/vgdata/lvtest
sudo lvs -o lv_path,lv_size /dev/vgdata/lvtest

L'absence de sortie de findmnt peut être attendue pour un volume démonté ; contrôlez aussi les autres chemins et namespaces pertinents. Si le LV est encore monté ou activement utilisé, arrêtez la procédure.

Étape 2 — contrôler le filesystem

Sur le volume ext4 démonté, un administrateur autorisé peut programmer une vérification complète :

sudo e2fsck -f /dev/vgdata/lvtest

Cette commande peut modifier les métadonnées pour corriger des incohérences. Elle n'est donc pas une simple lecture. Analysez son résultat et n'enchaînez pas si des erreurs restent non résolues ; un e2fsck lancé sur un filesystem monté n'est pas un test valide.

Étape 3 — redimensionnement coordonné

Sur une plateforme LVM2 dont le couple outils/filesystem a été vérifié, l'opération de laboratoire peut être préparée sous cette forme, sans exécution automatique :

sudo lvreduce --resizefs --size 40G /dev/vgdata/lvtest

Le 40G désigne ici la taille finale visée, et non 40 GiB à retirer. La taille doit être supérieure à la taille minimale réellement compatible avec les données et le filesystem, avec une marge opérationnelle. Les tailles LVM peuvent être arrondies aux extents ; il faut lire la valeur finale rapportée.

En présence d'une erreur, d'une incompatibilité de fsadm, d'un avertissement inattendu ou d'une interruption : ne lancez pas une seconde commande lvreduce au hasard. Préservez l'état et engagez la procédure d'incident.

Pourquoi ne pas commencer par `lvreduce -L -20G` ?

La syntaxe relative -20G retranche 20 GiB à la taille actuelle du LV ; elle ne sait pas si le filesystem peut perdre cet espace. lvreduce --test simule principalement des écritures de métadonnées LVM, mais ne valide pas la sécurité d'une réduction du filesystem. Ni --force ni --yes ne corrigent une mauvaise cible.

L'approche manuelle « resize2fs puis lvreduce » existe, mais exige la maîtrise des unités, de l'alignement et des marges. Ce guide ne la présente pas comme une procédure simplifiée à copier : une erreur entre les deux tailles peut entraîner une corruption irréversible.

Vérification après intervention

Après une réduction réellement achevée et un remontage contrôlé du volume de laboratoire, comparez les couches et vérifiez les fichiers attendus :

sudo lvs -o vg_name,lv_name,lv_size,lv_path
sudo vgs -o vg_name,vg_free
findmnt --target /mnt/lvtest -o SOURCE,FSTYPE,TARGET
df -hT /mnt/lvtest
ls -la /mnt/lvtest

Le LV doit présenter une taille compatible avec la cible, le VG davantage d'extents libres et df une capacité cohérente. La simple réussite de ces commandes ne prouve pas l'intégrité applicative : vérifiez fichiers témoins, checksums disponibles, démarrage du service, journaux et tests fonctionnels.

En cas de divergence entre lvs et df, ne devinez pas : réidentifiez le périphérique et le montage. Si une corruption est suspectée, stoppez les écritures et déclenchez le plan de récupération.

Bonnes pratiques opérationnelles

Réduire pour « faire propre » est rarement une bonne justification. Identifiez plutôt le besoin métier : capacité insuffisante dans un autre LV, migration vers une nouvelle architecture ou décommissionnement. Un VG avec des extents disponibles offre déjà de la flexibilité ; déplacer des données ou provisionner un nouveau LV peut être moins risqué qu'une réduction.

Conservez une marge de croissance et des seuils de surveillance après la modification. Documentez les identifiants des volumes, tailles avant/après, versions d'outils et heure de l'opération. Évitez les commandes génériques qui ciblent le premier LV trouvé et les scripts supposant que tous les filesystems se redimensionnent de la même façon.

Distinguez enfin trois objectifs : récupérer des extents dans le VG, restituer un PV au système de stockage, et diminuer une ressource facturée. Ils n'impliquent ni les mêmes outils ni le même niveau de risque.

Sécurité et limites

La réduction est une opération destructive potentielle. Une sauvegarde non testée n'est pas une garantie. LVM ne valide pas les données applicatives, et un lvreduce forcé peut supprimer des blocs indispensables au filesystem. Un point de montage mal identifié, une couche de chiffrement oubliée ou une automatisation exécutée sous privilèges peuvent multiplier l'impact de l'erreur.

Le scénario décrit se limite à un LV linéaire et à ext4, sur une distribution prenant en charge les outils concernés. Les commandes doivent être adaptées et validées sur la version exacte de LVM2, e2fsprogs et du système. Aucune réduction réelle n'a été exécutée pour cet article ; il s'agit d'une revue documentaire et d'une proposition de laboratoire.

Retour arrière : préparer la restauration, pas une commande inverse

Si une réduction coupe des blocs encore utilisés, agrandir à nouveau le LV ne restaure pas magiquement leur contenu. Le retour arrière doit s'appuyer sur une restauration vérifiée : sauvegarde de données, reconstruction du filesystem ou bascule sur un environnement sain selon les besoins de l'application.

Avant de commencer, notez qui décide de l'arrêt, où se trouve la sauvegarde, comment vérifier sa cohérence et combien de temps prendra la reprise. Si ces réponses manquent, la bonne décision est de reporter la réduction.

Références officielles

Conclusion

Étendre et réduire un LV ne sont pas deux opérations symétriques. Pour ext4, une réduction exige une démarche hors ligne, une vérification du filesystem, un dimensionnement conservateur et un plan de restauration. Pour XFS, la réduction en place n'est pas prise en charge : il faut envisager une migration des données vers un nouveau volume.

Avant de libérer des extents, demandez-vous si l'opération est réellement nécessaire. Dans le #48, nous examinerons les snapshots LVM, leur fonctionnement et leurs limites, sans les confondre avec une sauvegarde.