Bonnes pratiques de sauvegarde LVM

La plupart des distributions Linux serveur déploient le stockage via le Logical Volume Manager (LVM). LVM abstrait les disques physiques en partitions virtuelles flexibles, mais cette abstraction modifie ce qu'un agent de sauvegarde doit lire pour produire une image cohérente et restaurable. Choisir la mauvaise couche produit des sauvegardes impossibles à restaurer.

Ce guide explique quelle couche LVM StateWarden protège, comment les snapshots cohérents et le suivi des modifications se comportent sur les volumes LVM, et ce qu'il faut prendre en compte lors d'une restauration ou d'une reconstruction complète du système.

1. Les couches LVM et la règle du volume logique

LVM organise le stockage en trois couches :

1. Physical Volumes (PV) : les disques ou partitions sous-jacents consommés par LVM (par exemple /dev/sda2, affichés par des outils comme lsblk avec le type LVM2_member).
2. Volume Groups (VG) : un pool de capacité de stockage agrégé à partir d'un ou plusieurs PV.
3. Logical Volumes (LV) : les partitions virtuelles découpées dans un VG, là où résident réellement les systèmes de fichiers et les données (par exemple /dev/vg0/root ou /dev/mapper/vg0-data).

Sélectionnez toujours le volume logique comme source de sauvegarde. Un LV est un périphérique bloc ordinaire avec une frontière stable : il possède un système de fichiers, une taille définie et peut être snapshoté. Dans la vue de stockage de l'appareil du Dashboard, les PV apparaissent comme des entrées de membres de pool estompées et ne sont pas proposés comme cibles de sauvegarde individuelles ; ce sont les LV empilés au-dessus qui constituent les périphériques sélectionnables.

Sauvegarder un LV unique (comme data) permet également de le restaurer indépendamment, sans toucher aux autres LV (comme root) du même VG.

2. Pourquoi les volumes physiques ne sont pas des cibles de sauvegarde valides

Lire un PV directement (par exemple imager /dev/sda2) ne produit pas une sauvegarde exploitable :

• Aucun instant cohérent. Une lecture brute de PV capture des secteurs pendant que le système écrit dessus. Les en-têtes de métadonnées LVM et les données du système de fichiers peuvent être capturés en pleine mise à jour, et le résultat peut être irrécupérable. Un PV ne peut pas être snapshoté seul.
• Données incomplètes sur les groupes multi-disques. Si un VG s'étend ou est réparti (striping) sur plusieurs PV, un seul PV ne contient que des fragments de chaque LV. Reconstruire le VG exigerait tous les PV capturés exactement au même instant, ce qui est impossible sur un système en cours d'exécution.
• Aucune restauration par volume. Une image de PV mélange les extents de tous les LV du VG ; les volumes individuels ne peuvent donc pas être restaurés sélectivement.

3. Sauvegardes cohérentes avec les snapshots LVM

StateWarden utilise le mécanisme de snapshot natif de LVM pour obtenir des sauvegardes cohérentes en cas de crash (crash-consistent) des volumes logiques :

1. Avant de lire le volume, l'agent crée un snapshot LVM temporaire du LV source. Un snapshot présente une vue figée du volume à un instant donné ; LVM redirige les écritures ultérieures sur l'origine en copy-on-write, de sorte que le contenu du snapshot ne change pas pendant l'exécution de la sauvegarde.
2. L'agent lit les données de sauvegarde depuis le périphérique de snapshot plutôt que depuis l'origine active. Bases de données et fichiers sont capturés exactement tels qu'ils étaient à l'instant du snapshot, même si la sauvegarde elle-même dure longtemps.
3. À la fin de la tâche, le snapshot temporaire est supprimé.

Notes d'exploitation :

• Les snapshots LVM classiques consomment de l'espace dans le VG à mesure que l'origine change pendant la fenêtre de sauvegarde. Conservez suffisamment d'extents libres dans le VG pour absorber le volume d'écriture attendu pendant la durée d'une sauvegarde ; un snapshot à court d'espace devient invalide et la sauvegarde échoue.
• La cohérence au niveau applicatif est un sujet distinct. Pour les bases de données, utilisez leurs mécanismes natifs de vidage (flush) ou de mise en quiescence lorsqu'ils existent ; le snapshot LVM garantit une image cohérente en cas de crash, pas une image mise en quiescence applicative.

4. Comportement du CBT sur les volumes LVM

Sur les partitions simples, Smart CBT accélère les sauvegardes incrémentales en suivant les blocs modifiés entre les exécutions. Les volumes logiques LVM se comportent différemment : LVM fournit des mécanismes de snapshot natifs que l'agent utilise pour identifier les données modifiées, de sorte qu'appliquer la couche CBT distincte à un LV est inutile.

En conséquence, la bascule CBT de la vue de stockage de l'appareil du Dashboard affiche l'infobulle suivante pour les volumes LVM :

LVM utilise des snapshots natifs. La couche CBT n'est pas requise.

C'est une information, pas une erreur. Les sauvegardes incrémentales des volumes LVM continuent de s'exécuter ; la détection des modifications est simplement assurée par les mécanismes de snapshot propres à LVM plutôt que par la couche utilisée pour les partitions simples. Pour le fonctionnement de Smart CBT sur les autres types de volumes, voir Smart CBT : sauvegardes incrémentales et Smart NTFS et sauvegardes au niveau bloc.

5. Volumes en provisionnement fin (thin provisioning)

Le provisionnement fin LVM alloue la capacité à la demande depuis un thin pool au lieu de la pré-assigner à chaque volume. Les LV fins (thin) sont sauvegardés comme tout autre volume logique, mais gardez les points suivants à l'esprit :

• L'espace des snapshots provient du thin pool. Les snapshots des volumes fins consomment de la capacité du pool à mesure que des données sont écrites pendant la fenêtre de sauvegarde. Surveillez l'utilisation du pool et gardez de la marge ; un thin pool épuisé peut affecter les volumes d'origine, pas seulement le snapshot.
• Taille virtuelle et données réelles. Un LV fin peut présenter une taille virtuelle bien supérieure à la capacité physique du pool. Les cibles de restauration sont dimensionnées sur la taille virtuelle du LV (voir section 6) ; prévoyez donc le stockage cible en conséquence lorsque vous déplacez un volume fin vers un matériel différent.

6. Ce qu'il faut exclure

Tous les périphériques bloc d'un système LVM ne méritent pas d'être protégés :

• Les volumes de snapshot. N'ajoutez pas les périphériques de snapshot LVM (qu'il s'agisse des snapshots temporaires de StateWarden ou de snapshots créés manuellement) comme sources de sauvegarde. Le contenu copy-on-write d'un snapshot est transitoire et redondant ; sauvegarder des snapshots de snapshots gaspille du stockage et produit des images sans valeur de restauration propre. Sauvegardez le LV d'origine à la place.
• Les volumes de swap. Le swap ne contient que des pages mémoire transitoires, sans valeur après un redémarrage. Les périphériques de swap sont exclus du suivi des modifications et ne doivent être assignés à aucune politique de sauvegarde. Un LV de swap se recrée sans effort lors d'une reconstruction.

7. Considérations de restauration

Les volumes LVM sont restaurés au niveau bloc, ce qui impose des règles de dimensionnement sur la cible :

• Taille égale ou supérieure. Le LV cible doit être au moins aussi grand que le LV source au moment de la sauvegarde. Restaurer une image de niveau bloc sur un LV plus petit est impossible ; créez le LV cible avec une taille suffisante avant de lancer la restauration.
• Agrandissez le système de fichiers ensuite. Lors d'une restauration sur un LV plus grand, le système de fichiers restauré conserve sa taille d'origine. Agrandissez-le après la restauration pour exploiter l'espace supplémentaire (par exemple xfs_growfs pour XFS ou resize2fs pour ext4, selon le type de système de fichiers).
• Recréez LVM avant de restaurer sur des installations neuves. Si la machine cible ne possède pas encore la structure VG et LV requise, créez-la d'abord avec les outils LVM standard (pvcreate, vgcreate, lvcreate), puis restaurez le contenu des volumes dans les nouveaux LV.

8. Bare Metal Recovery sur les systèmes à base de LVM

Protéger les volumes logiques plutôt que les disques physiques n'empêche pas la reprise complète du système sur du matériel vierge. Smart BMR enregistre la topologie de stockage du système protégé avec les données des volumes. Pendant une restauration bare metal, l'environnement de récupération :

1. Démarre la machine cible depuis le Recovery ISO StateWarden.
2. Présente les disques physiques vides disponibles pour sélection.
3. Recrée la structure LVM (volumes physiques, groupes de volumes et volumes logiques) à partir des informations de topologie stockées avec la sauvegarde.
4. Restaure les données sauvegardées dans les LV nouvellement créés et applique les corrections du chargeur de démarrage nécessaires pour rendre le système amorçable.

La procédure complète, y compris la préparation du support de récupération et la génération du jeton, est décrite dans le Guide Bare Metal Recovery.

Liste de contrôle récapitulative