Une mise à jour de noyau, de pilotes ou de paquets peut laisser un poste ou une VM dans un état inutilisable. Si votre racine repose sur Btrfs, un snapshot pris juste avant l’opération garde un point de retour local, à condition de viser le bon sous-volume.
La méthode ci-dessous crée une copie en lecture seule, puis contrôle qu’elle existe vraiment. Elle ne remplace pas une sauvegarde et ne lance pas de restauration automatique du système.
Confirmer que la racine est un sous-volume Btrfs
Ne lancez pas un snapshot parce que la machine utilise Btrfs quelque part. Il faut vérifier le système de fichiers qui porte /, puis identifier le sous-volume monté. Sur un serveur distant, gardez votre session SSH ouverte pendant toute la vérification.
findmnt -T / -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo btrfs subvolume show /
sudo btrfs subvolume list -p /
sudo btrfs filesystem usage /La première commande doit afficher btrfs dans la colonne FSTYPE. btrfs subvolume show / confirme que la racine correspond à un sous-volume. Regardez aussi l’espace non alloué et l’espace libre, car un snapshot partage d’abord les blocs existants, puis consomme de la place quand les fichiers changent.
Cette procédure vise une racine Btrfs montée comme sous-volume. Si /home est séparé, prenez un snapshot distinct pour les données qui doivent suivre le retour arrière. Sur une machine configurée avec LVM, ext4 ou XFS, ces commandes ne sont pas adaptées.
Créer une copie avant la mise à jour
Choisissez un répertoire de snapshots situé sur le même système de fichiers Btrfs. L’exemple crée un nom daté et une copie en lecture seule. Adaptez le chemin si votre distribution ou votre outil de snapshots utilise déjà un emplacement dédié.
sudo install -d -m 700 /@snapshots
sudo btrfs subvolume snapshot -r / /@snapshots/root-before-update-2026-09-02L’option -r protège ce point de retour contre une modification involontaire. Attendez la fin de la commande avant de lancer apt upgrade, dnf upgrade ou votre procédure habituelle. La documentation Btrfs décrit ce mécanisme de snapshot et les propriétés des sous-volumes.
Je réserverais cette commande à une racine dont vous avez lu le montage. Créer un snapshot du mauvais chemin donne une impression de sécurité, puis ne restaure pas le système qui a réellement été modifié.
Contrôler le point de retour après la mise à jour
Un snapshot annoncé par le terminal n’est pas encore un contrôle suffisant. Listez-le, affichez ses propriétés, puis redémarrez et vérifiez le service ou l’application touchée par la mise à jour.
sudo btrfs subvolume list /@snapshots
sudo btrfs subvolume show /@snapshots/root-before-update-2026-09-02
sudo btrfs property get -ts /@snapshots/root-before-update-2026-09-02 roLa dernière commande doit indiquer ro=true. Gardez le snapshot jusqu’à la validation du démarrage et des services concernés. Une fois la mise à jour validée, vous pouvez le supprimer pour récupérer les blocs qui ne sont plus partagés.
sudo btrfs subvolume delete /@snapshots/root-before-update-2026-09-02Ne supprimez pas une copie dont vous pourriez encore avoir besoin pour diagnostiquer une régression. Si la machine ne redémarre plus, la marche à suivre dépend du chargeur, de la disposition des sous-volumes et de l’outil de gestion des snapshots. Préparez cette procédure avant l’incident, plutôt que depuis une session de secours.
Un snapshot local ne protège pas le disque
Le snapshot reste sur le même pool Btrfs. Une panne de disque, un volume chiffré inaccessible ou une suppression du pool peut emporter la racine et ses snapshots. Pour récupérer un fichier après un incident matériel, gardez aussi une sauvegarde hors du pool. Notre méthode pour vérifier une restauration BorgBackup complète ce contrôle.
Le choix est simple : snapshot pour revenir vite après une mise à jour, sauvegarde séparée pour survivre à la perte du stockage. Les deux répondent à des pannes différentes.
Pour les détails sur les sous-volumes et leurs snapshots, la documentation Btrfs reste la référence utile avant de changer l’organisation d’un système existant.