Restauration de SLES Btrfs Snapper après une mise à jour ayant échoué : Guide de récupération sécurisée

Une mise à jour SLES ayant échoué ne signifie pas toujours qu'il faut réinstaller le serveur. Sur une installation standard de SUSE Linux Enterprise Server utilisant Btrfs comme système de fichiers racine et avec Snapper activé, il est souvent possible de démarrer sur un instantané antérieur à la mise à jour, de le tester sans modifier le système actuel, puis de définir cet état fonctionnel comme nouvelle racine accessible en écriture.

La décision importante n'est pas simplement de savoir « quelle version de Snapper est la plus récente ? » mais plutôt « jusqu'où dois-je revenir ? ». Une restauration complète du système Snapper est appropriée lorsqu'une mise à jour a modifié plusieurs paquets, bibliothèques, services ou fichiers de configuration et que la machine ne fonctionne plus correctement. Si un seul fichier de configuration est erroné, sa restauration est généralement moins perturbatrice. Ce guide explique les deux options et suit le modèle de récupération SLES 15 SP7 documenté par SUSE et disponible en octobre 2026.

Choisissez la méthode de récupération avant de modifier quoi que ce soit.

SUSE distingue l'annulation des modifications d'une restauration système . L'annulation des modifications compare les instantanés et rétablit l'état des fichiers sélectionnés. Une restauration système permet de définir un instantané comme base pour une nouvelle racine accessible en écriture. SUSE recommande vivement de démarrer d'abord sur l'instantané cible lors d'une restauration du système de fichiers racine, afin de vérifier la version candidate avant de la valider. Consultez le Guide d'administration de SLES 15 SP7 .

Étape 1 : Vérifiez que ce serveur prend en charge le chemin de restauration standard de Snapper

Avant de choisir un instantané, vérifiez trois points : le système de fichiers racine est Btrfs, Snapper possède une configuration nommée rootet la racine Btrfs se trouve sur un seul périphérique. La documentation SUSE décrit la prise en charge de la restauration amorçable pour la configuration par défaut des sous-volumes racine et précise que le système de fichiers racine Btrfs doit être associé à un seul périphérique.

findmnt /
sudo snapper list-configs
sudo /sbin/btrfs filesystem show /

Si findmnt /le système de fichiers détecté est XFS ou Ext4, arrêtez l'opération : la procédure de démarrage par instantané Btrfs n'est pas disponible pour cette racine. Si snapper list-configsaucune rootentrée n'est présente, il est possible que les instantanés automatiques de la racine n'aient pas été activés. Arrêtez également l'opération si btrfs filesystem show /plusieurs périphériques sont détectés ; la documentation SLES 15 SP7 n'indique pas que cette configuration est prise en charge pour la restauration de la racine amorçable.

Étape 2 : Identifier l’instantané précédant immédiatement la mise à jour ayant échoué

Répertoriez les instantanés et examinez leur date, leur type, leur relation antérieure à l'instantané et leur description :

sudo snapper list

Sur une configuration SLES par défaut, les activités YaST et Zypper peuvent créer predes postpaires d'instantanés. Un preinstantané représente l'état du système de fichiers avant la transaction ; son postinstantané correspondant représente l'état après. Ne sélectionnez pas un instantané uniquement parce qu'il est antérieur à la panne. Faites correspondre l'horodatage et la description de l'instantané à la fenêtre de mise à jour.

Si la modification ayant échoué était une migration de Service Pack, le guide de mise à niveau SLES 15 SP7 de SUSE indique spécifiquement aux administrateurs de localiser l'instantané créé immédiatement avant la migration et précise que l'instantané concerné est marqué comme important.

Étape 3 : Examiner ce que l’instantané candidat modifierait réellement.

Si le système actuel démarre encore, comparez l'instantané candidat avec l'état actuel avant de redémarrer. Cela permettra de déterminer si la mise à jour a affecté un seul fichier de configuration ou un grand nombre de fichiers système.

sudo snapper status SNAPSHOT_ID..0
sudo snapper diff SNAPSHOT_ID..0 /etc/some-file.conf

Quand la restauration sélective représente le meilleur compromis

Si un fichier connu est corrompu et que le reste du système mis à jour est sain, la restauration de ce seul fichier évite d'annuler des modifications système sans lien avec celui-ci. SUSE documente cette procédure :

sudo snapper -c root -v undochange SNAPSHOT_ID..0 /etc/some-file.conf

N'omettez pas le nom du fichier à la légère. Sans nom de fichier, undochangeil est possible d'annuler toutes les modifications apportées aux fichiers entre les deux états. SUSE déconseille fortement d'utiliser la restauration de fichiers pour simuler une restauration complète du système. Les transactions de paquets peuvent modifier de nombreux fichiers interdépendants ; une restauration complète et testée est donc généralement plus facile à comprendre lorsque l'échec de la mise à jour est systémique.

Étape 4 : Démarrer l’instantané candidat à partir de GRUB

Redémarrez la machine. Dans le menu GRUB 2 de SLES, sélectionnez l'option permettant de démarrer le chargeur de démarrage à partir d'un instantané en lecture seule, puis choisissez l'instantané correspondant à l'état antérieur à la mise à jour. L'interface exacte peut varier selon le firmware et la configuration de démarrage, mais SLES 15 SP7 décrit cette option comme « Démarrer le chargeur de démarrage à partir d'un instantané en lecture seule » .

Seuls les instantanés issus de la rootconfiguration Snapper par défaut sont amorçables via ce mécanisme SLES. Si le menu des instantanés est absent, ne créez pas d'entrée de démarrage. Vérifiez que Snapper est bien activé, que la structure racine correspond toujours à la structure par défaut prise en charge et que le chargeur de démarrage installé est fonctionnel.

Étape 5 : Tester l’instantané pendant que la racine est en lecture seule

Une fois le snapshot démarré, vérifiez que vous exécutez bien le programme à partir de celui-ci et que le système de fichiers racine est en lecture seule :

findmnt /
mount | grep ' on / '

Testez maintenant les éléments qui ont échoué après la mise à jour : démarrage des services, configuration réseau, authentification, lancement d’applications, comportement dépendant du noyau et autres vérifications pertinentes. Évitez de considérer l’instantané en lecture seule comme un démarrage normal en production. Certaines opérations échoueront simplement parce que la partie de l’instantané du système de fichiers racine ne peut pas être écrite.

Si l'instantané n'est pas le bon, redémarrez et essayez-en un autre. Tant que vous n'aurez pas exécuté la commande de restauration, cet instantané ne sera pas défini comme nouvelle racine système accessible en écriture.

Étape 6 : Validez la restauration uniquement une fois que l’instantané a passé vos vérifications.

Lorsque l'instantané démarré se comporte comme prévu, rendez-le permanent :

sudo snapper rollback

Vous pouvez ajouter une description pour faciliter l'identification ultérieure de la capture d'écran :

sudo snapper rollback -d "Rollback after failed update"

D'après la documentation d'administration de SLES, Snapper crée un instantané de l'état antérieur à la restauration et un nouvel instantané accessible en écriture qui devient la racine par défaut. Il s'agit d'une mesure de sécurité importante : la restauration ne se contente pas d'écraser l'ancienne racine.

Redémarrez une fois la commande terminée :

sudo reboot

Au prochain démarrage, choisissez l'entrée SLES par défaut normale plutôt que de redémarrer l'ancien instantané en lecture seule.

Étape 7 : Vérifiez que le répertoire racine restauré est accessible en écriture et qu’il est désormais le répertoire par défaut.

Après un démarrage normal, vérifiez le montage racine et la liste des instantanés :

findmnt /
sudo snapper list

Répétez les tests fonctionnels qui ont initialement échoué. Si une application échoue toujours, vérifiez si une partie de cette application se trouve dans un répertoire non inclus dans l'instantané racine.

Étape 8 : Actualiser les dépôts et vérifier l’état des paquets

Pour une mise à jour de paquet classique, actualisez les dépôts et vérifiez les dépendances des paquets avant de tenter une nouvelle mise à jour. Lors d'une restauration d'un Service Pack, les vérifications des dépôts et de l'enregistrement des produits sont particulièrement importantes, car une incompatibilité des dépôts peut immédiatement rendre le système incohérent.

sudo zypper ref -fs
sudo zypper lr -u
sudo zypper verify

Pour la récupération du Service Pack, suivez les vérifications du Guide de mise à niveau officiel de SLES , qui préconise explicitement la vérification de la configuration du référentiel et de l'enregistrement du produit après la restauration.

Ce qu'une restauration du système Snapper ne restaure pas

Il est essentiel de comprendre cette limitation avant d'utiliser la restauration sur un serveur de production. L'instantané racine SLES par défaut exclut plusieurs sous-volumes afin d'éviter toute restauration inattendue des données volatiles, des données utilisateur ou des données d'application. La liste spécifique au produit peut inclure des chemins d'accès au chargeur de démarrage propres à l'architecture. Consultez la documentation SUSE sur les concepts de base de Snapper pour connaître/home la liste actuelle et sa justification /opt./usr/local/srv/tmp/var/run

Cette conception protège les données, mais elle présente un inconvénient : le code système peut régresser tandis que les données d'un sous-volume exclu restent à jour. SUSE signale plusieurs conséquences possibles, notamment /optl'incompatibilité des logiciels tiers, la modification des permissions et l'incapacité des applications à interpréter les formats de données écrits après la prise de l'instantané.

Cela est particulièrement important pour les bases de données et les applications serveur. Si une mise à jour a entraîné une migration de schéma ou modifié des données d'application sous `<nom_du_système>` /varou /srv`<nom_du_système>`, une restauration système complète peut ne pas annuler ces modifications. Consultez la procédure de restauration ou de rétrogradation propre à l'application avant de considérer que l'instantané système seul est suffisant.

Erreurs courantes à éviter

• Rétablir la configuration précédente avant de tester l'instantané. Démarrer d'abord l'instantané en lecture seule est la méthode de travail SLES la plus sûre, car elle permet de vérifier l'état cible.
• Choisir par erreur un instantané postérieur à la mise à jour. Vérifiez le type, la date, la description et la relation avant/après plutôt que de vous fier uniquement au numéro d'instantané.
• Utilisée undochangepour une transaction portant sur l'ensemble du système. Utile pour des fichiers sélectionnés ; SUSE recommande la méthode de redémarrage et de restauration pour une récupération complète du système à accès racine.
• S'attend /varà /homeun voyage en arrière avec la racine. Les exclusions de sous-volumes par défaut sont intentionnelles.
• Sans tenir compte de l'exigence d'un seul périphérique, SLES 15 SP7 documente la prise en charge de la restauration du système de fichiers racine amorçable pour un système de fichiers racine Btrfs sur un seul périphérique.
• Nouvelle tentative de mise à jour immédiate. Commencez par identifier la cause de l'échec, vérifiez les dépôts et déterminez si l'échec est dû à un défaut du paquet, à un logiciel tiers incompatible, à un espace disque insuffisant ou à un problème de configuration locale.

Si le système utilise des mises à jour transactionnelles

SLES peut également être installé avec le rôle de serveur transactionnel. Il s'agit d'un modèle de fonctionnement différent : les mises à jour sont appliquées aux instantanés et activées au redémarrage. Sur ces systèmes, SUSE permet transactional-update rollbackde définir un instantané comme racine par défaut. Il est fortement déconseillé d'intégrer une procédure de récupération de serveur transactionnel à une installation SLES classique en lecture-écriture sans avoir préalablement identifié le rôle du système. Le comportement officiel est décrit dans la documentation relative aux mises à jour transactionnelles de SLES 15 SP7 .

Liste de contrôle de récupération

• Vérifiez que le système de fichiers /est bien Btrfs, que la rootconfiguration Snapper existe et que le système de fichiers racine Btrfs se trouve sur un seul périphérique.
• Identifiez l'instantané précédant immédiatement la mise à jour ayant échoué.
• Utilisez snapper status-le snapper difflorsque vous avez besoin de comprendre la portée du changement.
• Privilégier le mode sélectif undochangeuniquement pour les fichiers clairement isolés.
• En cas d'échec de la mise à jour systémique, démarrez l'instantané candidat à partir de GRUB et testez-le en lecture seule.
• N'exécutez cette commande snapper rollbackque lorsque le candidat se comporte correctement.
• Redémarrez le système de fichiers par défaut et vérifiez que le répertoire racine restauré est accessible en écriture.
• Actualisez les dépôts, vérifiez l'état des paquets et contrôlez l'enregistrement après la restauration du correctif.
• Vérifiez les sous-volumes exclus pour détecter les incompatibilités d'application ou de format de données avant de déclarer la récupération terminée.

Le principal compromis réside dans la précision face à la cohérence. La restauration sélective de fichiers modifie moins de données, mais exige de connaître précisément l'élément défectueux. Une restauration système testée modifie davantage de données, mais restaure un état racine cohérent à partir d'un instantané et convient mieux à une mise à jour ayant échoué et affecté plusieurs composants. Sous SLES, la méthode la plus sûre consiste à utiliser le démarrage à partir d'un instantané en lecture seule comme point de décision, plutôt que de rendre la restauration irréversible avant d'avoir vérifié la solution candidate.