Rétablir un volume de données avec un instantané LVM

Rétablir un volume de données avec un instantané LVM

Rétablir un volume de données avec un instantané LVM

Une mise à niveau ne se limite pas au remplacement du programme : elle peut aussi modifier les index, les fichiers de ressources et le format des données. Conserver l’ancien paquet d’installation ne suffit donc pas à garantir le retour arrière du volume de données. Sur un serveur dédié qui utilise déjà LVM (gestionnaire de volumes logiques), il est possible d’arrêter les écritures, de créer un instantané temporaire, puis de retrouver l’état antérieur à la mise à niveau par une fusion hors ligne. L’essentiel n’est pas que la commande de création de l’instantané réussisse, mais que les limites des écritures soient maîtrisées, que l’espace disponible soit suffisant et que la restauration soit pleinement validée.

1. Identifier le volume cible et le périmètre du retour arrière

Cet article prend pour exemple Debian 13, le système de fichiers ext4 et un volume de données LVM classique. Il ne traite ni du système de fichiers racine, ni des volumes de démarrage, ni des pools à allocation fine. La configuration standard de CloudUDP comprend deux disques NVMe de 1 To, chacun raccordé directement, sans RAID matériel. Cela ne signifie pas que LVM est déjà configuré : l’agencement réel du stockage doit être vérifié sur le serveur.

Commencez par relever la source du montage, le type de système de fichiers, les attributs des volumes logiques et l’espace libre du groupe de volumes :

findmnt -T /srv/appdata -o SOURCE,TARGET,FSTYPE,OPTIONS
sudo lvs -a -o vg_name,lv_name,lv_attr,segtype,origin,data_percent
sudo vgs -o vg_name,vg_size,vg_free
sudo lsblk -f

Si la cible est une simple partition, n’appliquez pas cette procédure. Ne formatez pas des données existantes pour pouvoir créer un instantané. Si les résultats indiquent des volumes à allocation fine, une couche de cache ou une autre organisation complexe, suivez la procédure propre à cette solution de stockage.

La suite suppose que le volume de données est vgdata/appdata, que son point de montage est /srv/appdata et que le service associé est app.service. Remplacez ces noms par les valeurs réelles et vérifiez l’absence de montages imbriqués et d’autres processus susceptibles d’écrire sur le volume. Exécutez les commandes par étapes : ne copiez pas l’ensemble de l’article pour le lancer d’un seul bloc.

Un instantané n’est pas une sauvegarde

Un instantané classique utilise la copie sur écriture pour conserver les blocs du volume d’origine avant leur modification. Il dépend du volume d’origine et du stockage sous-jacent. Il ne protège pas contre la panne d’un disque et ne couvre ni la configuration, ni les programmes, ni les données distantes situés hors du volume.

La fusion de l’instantané annule toutes les écritures effectuées sur le volume depuis sa création. Si l’application a déjà reçu des requêtes de production après la mise à niveau, exportez d’abord les nouvelles données à conserver et vérifiez leur compatibilité avec l’ancienne version du programme. Un retour arrière immédiat n’est pas possible dans ce cas.

2. Arrêter les services pour créer un point de restauration cohérent

Avant la mise à niveau, préparez une sauvegarde indépendante et consignez la version du programme, une synthèse de la configuration et l’état de santé de l’application. L’instantané ne garantit que l’état des blocs du volume désigné. Si plusieurs volumes ou une base de données externe sont concernés, il faut aussi définir un périmètre de cohérence entre les composants.

Avant d’arrêter le service, suspendez les requêtes entrantes, les consommateurs de files d’attente et les tâches planifiées afin qu’aucun processus ne continue à modifier les données après son arrêt. Dans la séquence suivante, la réussite du démontage sert de critère de mise au repos ; aucun démontage forcé ou différé n’est utilisé :

sudo systemctl stop app.service
sudo fuser -vm /srv/appdata
sudo sync
sudo umount /srv/appdata

Si le démontage échoue parce que le volume est occupé, vérifiez les répertoires de travail courants des processus, les fichiers ouverts et les autres services. Ne poursuivez pas tant que toutes les sources d’écriture n’ont pas été éliminées. Créez ensuite l’instantané :

sudo lvcreate --snapshot --size 20G \
  --name preupgrade /dev/vgdata/appdata
sudo lvs -o lv_name,lv_attr,origin,data_percent vgdata
sudo mount /srv/appdata

La valeur 20G correspond ici à un espace d’instantané choisi pour la démonstration. Ce n’est ni une caractéristique du produit ni une recommandation générale. Avant d’exécuter la commande, vérifiez que le groupe de volumes dispose de suffisamment d’espace libre et que preupgrade n’existe pas déjà. Dimensionnez l’instantané selon le volume de blocs qui seront modifiés pendant la période d’observation autorisant un retour arrière, plutôt qu’en appliquant mécaniquement un pourcentage de la capacité totale du volume d’origine.

Après avoir remonté le volume d’origine, créez d’abord un petit fichier de validation, puis procédez à une mise à niveau contrôlée. Les écritures réelles de production doivent rester bloquées à ce stade ; sinon, un retour arrière ultérieur exigera une étape supplémentaire de transfert des données.

3. Vérifier l’instantané en lecture seule et surveiller son occupation

Une fois l’instantané créé, il faut vérifier que son contenu est lisible. Les options suivantes s’appliquent uniquement à l’exemple ext4 de cet article : ro active la lecture seule et noload empêche le rejeu du journal au montage. Elles ne doivent pas être reprises telles quelles pour d’autres systèmes de fichiers.

sudo mkdir -p /mnt/app-preupgrade
sudo mount -t ext4 -o ro,noload \
  /dev/vgdata/preupgrade /mnt/app-preupgrade
sudo sha256sum /mnt/app-preupgrade/manifest.json \
  | sudo tee /root/app-preupgrade.sha256
sudo umount /mnt/app-preupgrade

manifest.json représente un fichier de données applicatives stable, choisi pour la vérification. Assurez-vous au préalable qu’il existe et qu’il constitue un indicateur pertinent pour valider la restauration. Le relevé de l’empreinte est conservé hors du volume cible. Après le retour arrière, comparez uniquement le champ contenant l’empreinte, pas le chemin de montage.

Évaluer le risque selon le volume de modifications

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

Data% indique la proportion d’espace utilisé dans l’instantané classique, et non le taux d’occupation du système de fichiers du volume d’origine. Effectuez des relevés réguliers avant et après la mise à niveau et observez la vitesse de croissance. Une reconstruction massive des index, l’écrasement de gros fichiers et d’autres opérations similaires peuvent consommer rapidement l’espace disponible.

À l’approche du seuil d’alerte défini à l’avance, suspendez les écritures suivantes et évaluez la nécessité d’une extension. Si le groupe de volumes dispose encore d’espace libre et que l’instantané reste valide, vous pouvez augmenter sa capacité selon cette évaluation :

sudo lvextend -L +10G /dev/vgdata/preupgrade

Ajouter de l’espace ne prolonge pas le délai de retour arrière autorisé par les contraintes de production. Si l’instantané est déjà invalide, une extension ne constitue pas une réparation : il faut passer à la procédure de restauration depuis la sauvegarde indépendante. Une surveillance des instantanés sans dispositif de réception et de traitement des alertes n’offre pas une protection fiable.

4. Effectuer la fusion hors ligne et vérifier la restauration

Une fois le retour arrière décidé, bloquez d’abord les requêtes de production, conservez les éléments permettant d’analyser l’échec et sauvegardez les nouvelles données indispensables. Les programmes et la configuration situés hors du volume doivent également être rétablis dans les versions correspondantes. Restaurer uniquement le volume de données peut créer une combinaison incompatible entre anciennes données et nouveau programme.

Vérifiez que l’instantané est valide et que son point de montage a été démonté. Arrêtez ensuite tous les services associés et démontez le volume d’origine. Les opérations suivantes modifient les données : contrôlez à nouveau les noms des volumes avant de les exécuter.

sudo systemctl stop app.service
sudo umount /srv/appdata
sudo lvchange -an /dev/vgdata/appdata
sudo lvconvert --merge /dev/vgdata/preupgrade
sudo lvchange -ay /dev/vgdata/appdata
sudo lvs -a -o lv_name,lv_attr,origin,data_percent vgdata

Si la fusion est programmée pour la prochaine activation, surveillez son état jusqu’à son achèvement. Ne relancez pas l’application au seul motif que la commande s’est terminée avec succès. Après une fusion réussie, le volume d’instantané disparaît. Remontez alors le volume d’origine et effectuez les vérifications :

sudo mount /srv/appdata
sudo sha256sum /srv/appdata/manifest.json
sudo cat /root/app-preupgrade.sha256

L’empreinte du fichier doit correspondre à la référence et le fichier de validation créé après l’instantané doit avoir disparu. Ces contrôles prouvent toutefois seulement que les fichiers concernés ont été rétablis, pas que l’application fonctionne correctement. Vérifiez aussi la version du programme, le nombre d’enregistrements essentiels, les résultats de lecture et une écriture contrôlée. Démarrez ensuite le service et examinez les journaux.

5. Transformer les résultats de l’essai en liste de contrôle pour la mise à niveau

Répétez d’abord la procédure complète sur un volume qui ne contient pas de données de production. Consignez la création de l’instantané, l’évolution de son occupation, l’état de la fusion et les résultats des vérifications applicatives. Avant une mise à niveau en production, confirmez au minimum les points suivants :

Lorsque la mise à niveau a été validée et que la période d’observation autorisant un retour arrière est terminée, vérifiez que l’instantané n’est pas monté. S’il existe encore, supprimez-le avec lvremove /dev/vgdata/preupgrade. Un instantané déjà fusionné n’a pas besoin d’être supprimé à nouveau.

Le livrable final doit être un compte rendu d’intervention comprenant l’agencement des volumes, le point de restauration, les relevés d’occupation et les résultats de validation de l’application. L’instantané n’est qu’un outil de retour arrière à court terme. La fiabilité repose sur une procédure de restauration reproductible, pas sur la présence d’un nom de volume supplémentaire.

Questions fréquentes

Cette procédure s'applique-t-elle directement à deux disques NVMe ?

Seulement si le système de fichiers visé repose déjà sur un volume logique LVM classique. Les commandes ne conviennent pas à un système de fichiers directement placé sur une partition. Il ne faut pas reconstruire le stockage pour une seule mise à jour.

Un instantané LVM remplace-t-il une sauvegarde indépendante ?

Non. Il dépend du volume d'origine et de son stockage. Une panne de disque peut affecter les deux, et un instantané plein peut devenir invalide. Une sauvegarde indépendante et une restauration vérifiée restent nécessaires.

La fusion conserve-t-elle les écritures effectuées après la mise à jour ?

Non. La fusion rétablit l'état du volume au moment de l'instantané et annule les écritures ultérieures. Il faut arrêter les services, démonter le volume et exporter les nouvelles données à conserver avant l'opération.

Serveur dédié AMD EPYC 7543P, à partir de $454/mois

Location mensuelle d’un serveur dédié complet

Vérifiez la configuration et le montant dû avant le paiement. Tous les prix sont facturés en dollars américains.