Linux sans magie #48 — Snapshots LVM : fonctionnement et limites

Dans le #47, nous avons vu pourquoi réduire un Logical Volume (LV) sans préparation pouvait détruire des données. Une question revient souvent avant une opération de stockage risquée : « Pourquoi ne pas prendre un snapshot LVM, puis revenir en arrière si nécessaire ? »

Un snapshot est utile : il expose une vue du volume à un instant donné tout en laissant évoluer l'origine. Mais il consomme des ressources, dépend du même stockage, et n'offre pas à lui seul la cohérence applicative ni l'indépendance d'une sauvegarde. Le comprendre permet de l'utiliser pour un test, une extraction ou une stratégie de retour arrière planifiée, sans en faire une assurance tous risques.

Le problème : figer une vue sans arrêter durablement le service

Imaginons une VM Linux dont le répertoire /srv/app est hébergé sur /dev/vgdata/lvapp. L'équipe doit lancer une migration applicative et aimerait conserver brièvement une vue de l'état antérieur.

Une copie classique de plusieurs dizaines de gigaoctets prend du temps. Pendant cette copie, les fichiers peuvent changer. Un snapshot LVM crée rapidement une vue logique des blocs à un instant donné ; on peut ensuite monter cette vue séparément dans un laboratoire ou s'en servir pour préparer une sauvegarde.

PV → VG vgdata
        ├── LV d'origine : lvapp → ext4 → /srv/app
        └── snapshot     : snap_app_pre_migration
                 └── vue des blocs à l'instant T

Le snapshot et son origine restent liés. Si le VG, ses disques ou le serveur sont perdus, la vue du snapshot peut être perdue également. Ce n'est pas une seconde copie indépendante conservée dans un autre domaine de défaillance.

Concept : un snapshot n'est pas un clone complet

Un snapshot représente l'état logique du LV au moment de sa création. La façon de préserver les anciennes versions des blocs dépend de la technologie LVM utilisée.

Dans un snapshot classique Copy-on-Write (CoW), une zone de stockage est réservée pour conserver les anciennes versions des blocs lorsque l'origine est modifiée. La taille déclarée pour le snapshot concerne cette réserve de changements, pas la capacité totale accessible dans la vue du snapshot.

Dans un thin snapshot, l'origine est déjà un thin LV géré par un thin pool. Les blocs peuvent initialement être partagés entre l'origine et le snapshot ; les changements introduisent de nouvelles allocations. La capacité est gérée au niveau du pool, dont il faut surveiller aussi les métadonnées.

Une activité d'écriture intense après la création peut donc accroître rapidement l'espace consommé. Un snapshot très ancien n'est pas automatiquement meilleur : il conserve davantage de différences potentielles et devient plus coûteux à maintenir opérationnellement.

Choisir le bon mécanisme

Critère	Snapshot CoW classique	Thin snapshot
Origine habituelle	LV classique	Thin LV dans un thin pool
Capacité réservée	Zone de changements spécifiée à la création	Espace consommé dans le thin pool au fur et à mesure
Surveillance principale	`Data%` du snapshot et espace disponible du VG	`Data%`, `Meta%` du thin pool et politique de saturation
Risque à saturation	Snapshot devenu invalide	Erreurs ou blocage d'I/O possibles selon la configuration du pool
Indépendance d'une sauvegarde	Non	Non

La distinction est importante pour interpréter les options de lvcreate. Une commande adaptée à un LV classique ne doit pas être transposée aveuglément à une architecture thin. Les propriétés réelles des volumes doivent être identifiées avant toute intervention.

Inventorier les volumes sans les modifier

Commencez par les commandes en lecture seule. Elles montrent l'origine éventuelle des snapshots, le pool associé et des indicateurs de consommation.

sudo pvs -o pv_name,vg_name,pv_size,pv_free
sudo vgs -o vg_name,vg_size,vg_free
sudo lvs -a -o vg_name,lv_name,lv_attr,lv_size,origin,pool_lv,data_percent,metadata_percent
lsblk -f
findmnt --target /srv/app -o SOURCE,TARGET,FSTYPE,OPTIONS

Un Data% absent n'est pas une preuve d'espace libre illimité : le champ dépend du type de LV. Pour un thin pool, la surveillance des métadonnées est aussi essentielle que celle des blocs de données. Notez la taille du VG, l'espace restant et la charge d'écriture anticipée pendant la durée de conservation du snapshot.

Assurez-vous également que /srv/app se trouve réellement sur le LV identifié. Les systèmes avec LUKS, RAID, cache, multipath ou snapshots multiples nécessitent une cartographie complète des couches.

Prérequis : définir la cohérence attendue

Un snapshot peut fournir une vue des blocs correspondant approximativement à un instant, sans que toutes les applications aient terminé leurs écritures. Pour une base de données, il peut manquer des transactions durablement synchronisées ou des fichiers répartis sur plusieurs volumes.

Il faut distinguer trois niveaux :

Cohérence bloc : vue des blocs à la création du snapshot.
Cohérence filesystem : filesystem pouvant être rejoué ou vérifié comme après une interruption, suivant la configuration.
Cohérence applicative : état explicitement préparé par l'application, ses journaux ou son moteur de base de données.

Lorsque la situation l'exige, utilisez le mécanisme officiel de mise au repos (quiesce) de l'application, des hooks de sauvegarde et, si pertinent, fsfreeze sur le filesystem compatible. La suspension des écritures doit être courte, orchestrée et suivie d'une reprise confirmée. Un simple appel à fsfreeze ne constitue pas une sauvegarde applicativement cohérente à lui seul.

Un snapshot unique ne garantit pas non plus une image atomique de plusieurs LVs. Si le service écrit sur plusieurs filesystems, choisissez une stratégie de cohérence inter-volumes adaptée.

Laboratoire : créer un snapshot classique limité dans le temps

Ce laboratoire suppose un LV classique et linéaire /dev/vgdata/lvtest, un VG de test disposant de plusieurs gibioctets libres et des données jetables. Il ne concerne pas directement un thin LV. Les chemins et tailles sont fictifs.

Étape 1 — contrôler la cible

sudo lvs -o lv_name,lv_path,lv_size,lv_attr /dev/vgdata/lvtest
sudo vgs -o vg_name,vg_free vgdata
lsblk -f

Vérifiez que le volume n'est ni racine, ni partagé avec une application de production, ni une couche chiffrée non prise en compte. Une marge d'espace libre doit rester disponible dans le VG. N'exécutez pas les commandes d'écriture si la cible est incertaine.

Étape 2 — préparer la création

La commande suivante est un exemple à valider et à exécuter exclusivement dans le lab, avec autorisation de modification du stockage :

sudo lvcreate --snapshot --size 2G --name snap_lvtest /dev/vgdata/lvtest

Pour cet exemple, 2 GiB représentent une réserve de changements, et non une sauvegarde de 2 GiB du LV d'origine. Le dimensionnement dépend du rythme d'écriture, de la durée de vie du snapshot, de la taille des blocs modifiés et des marges de sécurité. Le seuil doit être surveillé et augmenté si nécessaire avant saturation.

Les fonctionnalités de gel du filesystem ou d'arrêt applicatif doivent être coordonnées avant et autour de l'instant de création, lorsque la cohérence attendue l'impose. Ne conservez jamais un filesystem gelé faute de reprise contrôlée.

Étape 3 — observer le snapshot

sudo lvs -a -o lv_name,lv_attr,origin,lv_size,data_percent
sudo vgs -o vg_name,vg_free

Le nouveau snapshot doit apparaître avec une origine identifiable. Sur un snapshot classique, surveillez la part de la réserve occupée. Si elle atteint sa limite, le snapshot peut devenir invalide : on ne doit plus compter sur lui pour restaurer l'état initial.

Ne vous contentez pas d'un contrôle unique après la création. Prévoyez une mesure régulière, avec une réaction opérationnelle avant saturation.

Lire les données d'un snapshot avec précaution

On peut utiliser un snapshot comme source pour copier des fichiers ou générer une sauvegarde indépendante. Mais le montage doit respecter le filesystem et les identifiants du volume. Certains filesystems comportent des UUID identiques entre l'origine et le snapshot ; XFS demande des précautions particulières lorsqu'une copie du même filesystem est montée simultanément.

Même en lecture seule, le montage d'un filesystem journalisé peut nécessiter des mécanismes de récupération et provoquer des écritures dans certaines circonstances. Sur des données sensibles, privilégiez une méthode de lecture documentée pour ce filesystem et une cible de sauvegarde indépendante. Un snapshot ne doit pas devenir une seconde arborescence montée en écriture par commodité.

Pour les tests de restauration, préférez une copie du snapshot dans un environnement isolé. Vérifiez que la copie contient les données attendues avant toute opération sur l'origine.

Que se passe-t-il si le snapshot ou le thin pool est plein ?

Dans le modèle CoW classique, le snapshot a une zone de changements limitée. Lorsque cette zone est épuisée, la vue historique devient inutilisable. L'origine continue généralement de fonctionner, mais la possibilité d'exploiter cet instant passé disparaît.

Avec un thin pool, la situation peut affecter les opérations d'I/O des volumes qui utilisent ce pool. Selon le paramétrage du pool et les versions, des écritures peuvent être mises en attente ou renvoyer des erreurs. La saturation des métadonnées est également critique.

Consultez les valeurs Data% et Meta%, les journaux système et la politique d'extension automatique. Dimensionnez une marge et un seuil d'alerte adaptés au niveau de criticité. Il ne faut jamais laisser un snapshot grossir indéfiniment sans supervision.

Merge : ce que « revenir en arrière » signifie réellement

La fusion (merge) d'un snapshot vers son origine n'est pas une lecture anodine. Elle modifie les blocs de l'origine et peut annuler des écritures effectuées depuis l'instant du snapshot.

Pour un snapshot CoW compatible, lvconvert --mergesnapshot permet de planifier cette opération ; elle peut être différée jusqu'à une activation compatible si le LV est utilisé. Une fusion peut aussi nécessiter l'arrêt des applications et le redémarrage de l'environnement selon la situation.

# Illustration uniquement : opération de restauration potentiellement destructive
sudo lvconvert --mergesnapshot /dev/vgdata/snap_lvtest

Ne lancez pas cette commande en production sans validation du périmètre, arrêt des écritures, sauvegarde indépendante et fenêtre de restauration approuvée. Une fusion n'est pas un « Undo » universel : elle remplace un état de blocs, mais ne garantit pas la cohérence de services externes, d'autres volumes ou d'une base de données distribuée.

Supprimer un snapshot après usage

Un snapshot doit avoir une durée de vie définie. Lorsqu'il n'est plus nécessaire et qu'aucune opération de sauvegarde ou restauration n'y accède, on peut prévoir sa suppression après identification formelle du bon LV :

# À valider sur le seul snapshot de laboratoire
sudo lvremove /dev/vgdata/snap_lvtest

La suppression du snapshot ne supprime pas normalement le LV d'origine, mais l'erreur de chemin peut avoir de graves conséquences. Vérifiez lvs -a -o lv_name,origin,lv_path et assurez-vous de l'absence d'un montage ou processus encore actif sur le snapshot.

Confirmez ensuite que le snapshot a disparu et que le volume d'origine est toujours présent :

sudo lvs -a -o lv_name,origin,lv_path,lv_size
sudo vgs -o vg_name,vg_free

Bonnes pratiques et limites opérationnelles

Associez chaque snapshot à un objectif et à une échéance : tests applicatifs, sauvegarde à point cohérent ou possibilité de restaurer un état bien défini. Surveillez sa consommation, documentez son origine, et évitez d'empiler des snapshots dont personne ne maîtrise la durée de vie.

Ne remplacez pas une vraie stratégie de sauvegarde par des snapshots locaux. Une sauvegarde utile est indépendante du domaine de défaillance, restaurable, suivie et testée. Un snapshot peut aider à la produire, mais n'en constitue pas une copie hors site.

Vérifiez les versions de LVM2, du noyau, de la distribution et du filesystem avant de reprendre les commandes. La gestion avancée des thin pools, des snapshots externes, de LUKS, du RAID LVM, de clusters ou de bases de données distribuées dépasse ce scénario introductif.

Références officielles

Conclusion

Un snapshot LVM est une vue temporaire d'un volume, pas une sauvegarde indépendante. Le snapshot classique exige une réserve de changements ; le thin snapshot partage la capacité d'un thin pool, dont la saturation peut affecter les I/O.

Pour l'exploiter correctement, vérifiez l'architecture, la cohérence attendue, l'espace disponible, les métriques de consommation et la méthode de restauration. Dans le #49, nous passerons au RAID logiciel Linux avec mdadm, afin de distinguer cette fois disponibilité des données et stratégie de sauvegarde.