Restaurez en toute sécurité une mise à jour SLES ayant échoué avec Snapper

Sur une installation standard de SUSE Linux Enterprise Server (SLES) avec une racine Btrfs et Snapper activé, la méthode de récupération la plus sûre consiste à démarrer sur un instantané créé avant la mise à jour ayant échoué, à le tester en mode lecture seule, puis à exécuter la commande `snapshot` sudo snapper rollback. Cela crée une nouvelle racine accessible en écriture à partir de l'état testé ; cette opération ne restaure pas l'intégralité du disque, des sous-volumes ou des bases de données d'applications.

Les instructions d'administration actuelles de SLES 15 SP7 préconisent toujours cette procédure de démarrage et de test. Avant de la suivre, assurez-vous que la machine respecte la configuration de restauration prise en charge par SUSE et identifiez l' instantané antérieur à la transaction Zypper ou YaST ayant échoué.

Une restauration Snapper permettra-t-elle de restaurer l'intégralité du serveur ?

Non. La restauration du système amorçable s'applique aux instantanés dans la rootconfiguration Snapper par défaut. La documentation SUSE prend en charge l'organisation par défaut des sous-volumes racine, avec Btrfs sur un seul périphérique racine et un chargeur d'amorçage fonctionnel installé. La restauration modifie le contenu du sous-volume racine/ ; les autres sous-volumes ne sont pas concernés. Sur les configurations SLES classiques, des chemins tels que /var`/ var/log/`, `/ var/log/`, `/var/log /srv/ ` et `/var/log/` sont souvent situés en dehors de l'instantané. Une base de données ou un service peut donc conserver des données écrites après la création de l'instantané, même si ses paquets système sont restaurés./opt/usr/local/home

Avant de procéder à une restauration, effectuez ou vérifiez une sauvegarde distincte des données importantes de vos applications. Évitez également cette procédure si vous avez modifié la configuration par défaut des sous-volumes Btrfs ou si vous utilisez une racine multi-périphériques : la documentation relative à la restauration amorçable de SLES 15 SP7 ne couvre pas ces configurations. Consultez la documentation SUSE relative à la récupération Snapper avant de continuer.

Quel instantané a été créé avant l'échec de la mise à jour ?

Utilisez la configuration Snapper pour le système de fichiers racine et comparez les instantanés avant et après la transaction. Sur un système SLES standard avec les instantanés racine Btrfs activés, Zypper et YaST créent des instantanés autour des opérations sur les paquets. L'instantané « avant » représente l'état du système de fichiers racine avant l'opération ; l'instantané « après » représente l'état après son exécution, y compris en cas d'échec partiel d'une transaction.

1. Vérifiez que la configuration racine existe sudo snapper list-configs. Recherchez une configuration nommée root.
2. Vérifiez le type du système de fichiers racine avec la commande `ls` findmnt -no FSTYPE /. Pour cette procédure de restauration amorçable, la commande `ls` devrait indiquer `< nom_du_système_de_fichiers btrfs>`. Ensuite, exécutez la commande `ls` sudo btrfs filesystem show /et vérifiez que le système de fichiers racine est bien celui indiqué Total devices 1.
3. Listez les paires de transactions avec sudo snapper -c root list -t pre-post. Faites correspondre la date et la description à la mise à jour ayant échoué. Enregistrez le numéro dans la Pre #colonne, et non la paire Post #.
4. Examinez les différences entre les deux. Remplacez PREet POSTpar les numéros affichés sur votre machine :

sudo snapper -c root status PRE..POST
sudo snapper -c root diff PRE..POST

Ces commandes listent les chemins modifiés et les différences entre les fichiers. Les numéros de snapshot, les dates, les descriptions des paquets et le résultat varient selon l'hôte ; ne copiez pas un numéro d'exemple à partir d'une capture d'écran. Si aucune paire pertinente n'apparaît, vérifiez si Snapper est activé et si une règle de nettoyage a déjà supprimé le snapshot. Un snapshot manquant ne peut pas être recréé par Snapper a posteriori.

Comment tester l'ancienne racine avant de la rendre permanente ?

Redémarrez et utilisez l'entrée d'instantané du chargeur de démarrage. Sous SLES, sélectionnez Start Bootloader from a read-only snapshotl'instantané précédant immédiatement la transaction ayant échoué. Le menu de démarrage affiche la date et une description des entrées, pouvant inclure zypp(zypper)une opération YaST. Choisissez l'instantané enregistré avant la mise à jour ; ne sélectionnez pas l'instantané postérieur, même si sa description est plus facile à identifier.

Connectez-vous et testez les services ou applications qui ont échoué. Les fichiers racine de l'instantané sont en lecture seule pendant cet essai ; ce redémarrage ne modifie donc pas le système racine par défaut. Si l'instantané utilisé est incorrect ou si le système échoue toujours, redémarrez et essayez un autre instantané ou utilisez le système de récupération. Ne forcez pas une restauration simplement pour rendre le choix du menu permanent.

Quand faut-il exécuter snapper rollback ?

N’effectuez la restauration qu’une fois l’ancien instantané démarré et après vérification. À partir de cet instantané en lecture seule, exécutez :

sudo snapper rollback

Redémarrez ensuite et choisissez l'entrée de démarrage par défaut normale :

sudo reboot

Snapper conserve un instantané de l'état du système avant la restauration et crée un nouveau système de fichiers racine accessible en lecture-écriture à partir de cet instantané. Il n'est pas nécessaire de spécifier le numéro de l'ancien instantané lors de la procédure de démarrage à partir d'un instantané. Le résultat est un nouveau système de fichiers racine par défaut, et non une conversion accessible en écriture de l'instantané initial. Les instantanés peuvent être supprimés ultérieurement par des règles de nettoyage ; il est donc conseillé de copier les fichiers nécessaires avant d'utiliser un ancien instantané de restauration comme archive à long terme.

Que devez-vous vérifier après le redémarrage ?

Démarrez sur le point d'entrée par défaut et vérifiez la récupération effective, et pas seulement la fin de la commande. Confirmez l'état attendu du noyau et des paquets, consultez l'état et les journaux du service défaillant, et effectuez une vérification rapide au niveau de l'application. Enfin, examinez le nouvel état de Snapper :

sudo snapper -c root list

Pour une mise à jour de paquet classique, cela suffit généralement à confirmer que la machine démarre bien depuis le nouveau répertoire racine. Si l'opération ayant échoué était une migration de Service Pack , suivez également les vérifications post-restauration de SUSE : actualisez et inspectez les dépôts, puis vérifiez l'enregistrement.

sudo zypper ref -fs
sudo zypper lr
sudo SUSEConnect --status

Les dépôts doivent correspondre au Service Pack auquel vous êtes revenu, et les produits installés doivent être enregistrés. Si l'enregistrement n'est pas rétabli, suivez la procédure de restauration du Service Pack SLES 15 SP7sudo SUSEConnect --rollback décrite par SUSE. Cette commande d'enregistrement est spécifique à la récupération après une migration ; ne l'utilisez pas pour une mise à jour de paquet classique.

Si cet hôte utilise transactional-updateun système SLES transactionnel (par exemple, SLE Micro), suivez la procédure de ce produit au lieu d'appliquer la séquence de commandes SLES classique. Sa documentation décrit la procédure de sélection d'un instantané du système en cours d'exécution et un flux de travail distinct de démarrage en lecture seule à partir d'un instantané lorsque la racine actuelle est corrompue. Consultez les instructions de restauration des mises à jour transactionnellessudo transactional-update rollback SNAPSHOT_NUMBER de SUSE .