Mise en place d’un mécanisme de snapshot/rollback sur système d’exploitation GNU/Linux avec le système de fichiers Btrfs.
Cet article fait suite à des travaux de mise en place, sur les systèmes que je gère, d’un mécanisme d’instantanés (snapshots) et de retour en arrière (rollback) sur la partition racine. Tout ce qui suit s’applique en principe à une distribution Debian ou dérivées, mais doit être adaptable aux autres distributions GNU/Linux.
Sur les distributions Fedora ce sont les gestionnaires de paquets YUM et DNF qui intègrent nativement les instantanés Btrfs permettant de faire des mises à jour avec possibilité de retour en arrière, assurant ainsi une grande stabilité et tranquillité d’exploitation pour l’administrateur système.
Sommaire
- Description
- Prérequis techniques
- Introduction à Btrfs
- Mise en œuvre manuelle
- Cas particulier d’Ubuntu
- Utilisation de YUM et DNF
- Conclusion
Il s’agit pour moi de ma première expérience en qualité de rédacteur d’article, aussi je vous réclame toute votre indulgence. Je ferai au mieux pour apporter une information complète et claire.
Voici le commentaire à l’origine de cet article, portant sur le même sujet.
Ayant cherché pendant un certain temps à mettre en place une solution fonctionnelle permettant un retour en arrière (rollback) suite à une mise à jour système défaillante, j’ai le plaisir de vous faire découvrir la recette magique. Nous verrons que la procédure est plus ou moins complexe suivant la distribution. Suite à une conclusion personnelle, je vous donnerai, pour terminer, une liste de liens.
Je remercie vivement tous les corédacteurs de cet article.
Description
L’exploitation d’une machine GNU/Linux dans une entreprise ou à titre privé demande de réaliser des interventions régulières : mises à jour système et applicatives. Généralement, on s’appuie sur un gestionnaire de paquets. Beaucoup connaissent ici la fameuse commande apt-get install <nom-du-paquet>
.
Souvent, l’installation d’un paquet, bien qu’étant complexe dans les mécanismes internes, se déroule normalement sans incident. Cela d’autant plus que l’on s’appuie sur une distribution intégrant un processus de contrôle et validation des mises à jour de paquets.
Il arrive, au contraire, que ce qui fonctionne habituellement de manière transparente, conduise à un incident sur le service ou le serveur. On se retrouve alors très embarrassé et avec au mieux la possibilité de restaurer le système (grâce aux sauvegardes effectuées en amont), au pire une cohorte d’utilisateurs mécontents en attente de la restauration du service.
La procédure de restauration n’est pas toujours explicite et peut être complexe. Le temps pour le faire assez long, ce qui engendre une interruption de service conséquente.
Pour remédier à ces éventuelles difficultés, il faudrait pouvoir disposer d’une image du système créée à la demande ou régulièrement. Ces images sont appelées ici snapshots. Ce sont des instantanés du système de fichiers pris à un instant donné. Idéalement ces snapshots devront couvrir l’ensemble des données liées à l’application et au système d’exploitation. On pourra exclure les données utilisateurs (/home
) si elles résident sur le même serveur, de même que les données applicatives (bases de données, etc.).
Le terme rollback est repris du monde des bases de données relationnelles. Une transaction complexe sera validée dans son ensemble si l’ensemble des transactions élémentaires aboutissent. Si une seule échoue, l’ensemble de la transaction est annulée : on parle de retour en arrière ou rollback.
Idéalement, il faudrait pouvoir bénéficier des mêmes services quand on exploite un système GNU/Linux. Pour cela, on pourra s’appuyer sur un système de fichiers bénéficiant d’instantanés. Les candidats sont : LVM, Btrfs, XFS…
Paradoxalement, ces mécanismes sont disponibles en environnement virtualisé (VirtualBox) ou via la para‐virtualisation (Docker, LXC) et sont très faciles à mettre en œuvre, alors qu’il faut parfois batailler pour avoir des fonctionnalités similaires si l’on travaille avec les gestionnaires de paquets usuels.
Comme l’indique une réponse au commentaire à l’origine de l’article, certaines distributions proposent une solution basée sur snapper ; en l’occurrence, la distribution mentionnée dans la réponse est Arch Linux.
snapper est un outil venant d’openSUSE dont une des fonctionnalités est la création d’instantanés à l’aide des gestionnaires de paquets YaST et zypp. Cela signifie que les distributions openSUSE et dérivées intègrent nativement la gestion des instantanés sur les systèmes de fichiers Btrfs et LVM. D’autres distributions ont fait des efforts pour porter snapper à leurs infrastructures respectives.
Outre Arch Linux susmentionnée, il y a des paquets snapper créés automatiquement par les développeurs openSUSE pour d’autres distributions, à savoir CentOS, Debian, Fedora, RHEL, SLE, Scientific Linux et Xubuntu.
Prérequis techniques
Il faut disposer d’une machine avec un système d’exploitation GNU/Linux comportant :
- une partition racine au format Btrfs ainsi que l’utilitaire associé (paquet
btrfs-tools
) ; - un espace disque suffisant pour gérer des instantanés.
Sachez qu’il est possible de convertir une partition au format ext3 ou ext4 vers le format Btrfs avec la commande btrfs-convert
.
Introduction à Btrfs
Avant de vous lancer dans l’exploitation de volumes Btrfs, sachez que certains bogues liés à la gestion des RAID 5 et 6 persistent. Il est généralement conseillé de n’utiliser Btrfs que dans certains cas : sauvegarde ou en excluant les RAID 5 et 6. Pour le reste, Btrfs apporte des fonctionnalités simples à utiliser dont il serait dommage de se priver : haute disponibilité par la mise en œuvre de fonctions de maintenance à chaud (en ligne).
Fonctionnalités de Btrfs
- Btrfs s’appuie sur la notion de volumes et sous‐volumes ;
- le volume principal est une partition et sera formaté avec la commande
mkfs.btrfs
; - les sous‐volumes seront gérés par la commande
btrs subvolume create <chemin>
; - un sous‐volume peut être créé dans le volume principal ou dans un sous‐volume ;
- un instantané est un sous‐volume avec des caractéristiques particulières : volume COW + attributs lecture seule ou lecture‐écriture, etc. ;
- Btrfs gère la notion de volume par défaut :
btrfs subvolume [set-default|get-default]
; - il est possible de monter un sous‐volume par son nom ou son identifiant ; c’est ce mécanisme qui est utilisé au moment du démarrage du système (GRUB et fstab).
On pourra se reporter au guide de prise en main de Btrfs pour les détails de mise en œuvre. L’objet premier de cet article est de montrer les mécanismes de mise en œuvre de snapshot/rollback sur système d’exploitation GNU/Linux.
Petite précision : la commande btrfs
accepte des arguments dont la longueur importe peu, en effet les trois commandes ci‐dessous sont identiques :
btrfs subvolume list /
btrfs sub l /
btrfs su l /
Il est juste nécessaire que les arguments passés à la commande btrfs
soient suffisamment discriminants.
Mise en œuvre manuelle
Dans un premier temps, je vous montrerai une mise en œuvre d’un instantané permettant le redémarrage d’un système GNU/Linux depuis un état antérieur réputé fonctionnel. Par la suite, on verra qu’il est possible d’automatiser la procédure, en particulier avec des outils tels que snapper ou des greffons complémentaires aux gestionnaires de paquets GNU/Linux.
L’idée consiste à :
- réaliser un instantané de la racine ;
- effectuer les modifications ; dans le cas présent, il suffira de créer des fichiers sur le compte root pour la démonstration ;
- procéder au retour en arrière avec la commande
btrfs subvolume set-defaut
.
Pour vous faire la main, vous ferez les manipulations dans une machine virtuelle. Vous avez l’embarras du choix. Il vous suffit d’installer une distribution GNU/Linux en mode console avec le minimum de paquets et d’effectuer un instantané une fois le système d’exploitation installé. Rien de nouveau sur ce sujet.
Je me connecte sur le serveur, je passe super‐utilisteur (root) et je vais observer le répertoire du compte super‐utilisteur /root
:
- initialement, le répertoire
/root
est vide ; - on crée un fichier indiquant qu’on est avant le snapshot (
before-snapshot
) ; - pour finir, on liste les sous‐volumes Btrfs :
cd /root
touch before-snapshot
ls
before-snapshot
btrfs subvolume list /
ID 257 gen 43 top level 5 path @
Voyons comment est géré l’accès au volume Btrfs sur notre machine :
mount | grep btrfs
/dev/sda5 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
/dev/sda7 on /home type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@home)
- on voit que la partition racine possède le subvolid 257 et un nom de volume
/@
; - la partition
/home
est montée dans une seconde partition indépendante ; habituellement, si l’on ne précise rien, l’installateur Debian créé un sous‐volume du même nom rattaché au volume principal.
cat /etc/fstab
...
UUID=c4eedff5-784a-4cda-9da1-dd192befc889 / btrfs defaults,subvol=@ 0 1
...
- ici, nous avons la racine rattachée au volume par défaut (
/@
) ; pas de spécification de volume ID ; - le reste importe peu, si ce n’est que la partition
/boot
est indépendante.
Nous allons donc créer un instantané de la partition racine que l’on va placer dans le répertoire /.snapshot
:
mkdir /.snapshots
btrfs subvol snapshot / /.snapshots/01
Create a snapshot of '/' in '/.snapshots/01'
On vérifie que nous avons maintenant un volume principal et un sous‐volume (ID 261
, chemin d’accès /.snapshots/01
). Cet instantané est en lecture‐écriture ; il faudrait utiliser l’option -r
pour le passer en mode lecture seule :
btrfs subvol list /
ID 257 gen 85 top level 5 path @
ID 261 gen 85 top level 257 path .snapshots/01
Vérifions qu’on a bien la présence des fichiers « signature » dans chaque répertoire /root
:
touch /root/after-snapshot
ls -al /root/*snap* /.snapshots/01/root/*snap*
-rw-r--r-- 1 root root 0 déc. 29 13:17 /root/after-snapshot
-rw-r--r-- 1 root root 0 déc. 28 11:58 /root/before-snapshot
-rw-r--r-- 1 root root 0 déc. 28 11:58 /.snapshots/01/root/before-snapshot
Changement du volume par défaut
Afin de redémarrer la machine sur l’instantané (état précédent), on va changer le volume par défaut et redémarrer la machine :
btrfs subvol get-default /
ID 5 (FS_TREE)
btrfs subvolume list /
ID 257 gen 86 top level 5 path @
ID 261 gen 85 top level 257 path .snapshots/01
btrfs subvolume set-default 261 /
btrfs subvol get-default /
ID 261 gen 85 top level 257 path .snapshots/01
On relance la machine et on observe ce qu’il s’est passé :
cd /root
ls -al /root/*snap* /.snapshots/01/root/*snap*
-rw-r--r-- 1 root root 0 déc. 29 13:17 /root/after-snapshot
-rw-r--r-- 1 root root 0 déc. 28 11:58 /root/before-snapshot
-rw-r--r-- 1 root root 0 déc. 28 11:58 /.snapshots/01/root/before-snapshot
mount | grep btrfs
/dev/sda5 on / type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@)
/dev/sda7 on /home type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@home)
Malheureusement, on peut constater que la machine n’a pas redémarré sur le bon instantané (Ubuntu seulement). Le volume ID de l’instantané devrait être 261.
Cas particulier d’Ubuntu
Quand on installe la racine d’Ubuntu sur une partition Btrfs, l’installateur crée automatiquement et de manière transparente un sous‐volume @
et démarre sur /@/
. Quant à la partition /home
, elle est localisée dans le sous‐volume /@home/
. Cela permet de gérer dans un seul volume Btrfs, l’ensemble des sous‐volumes nécessaires au fonctionnement d’un système GNU/Linux.
Cela a pour corollaire qu’Ubuntu ne démarre pas sur le volume par défaut, mais bien sur le sous‐volume /@/
. Par ailleurs, le volume racine de ce sous‐volume porte toujours l’ID 5 (toplevel 5
) :
root@ubuntu:/# btrfs sub list /
ID 257 gen 132 top level 5 path @
ID 261 gen 139 top level 257 path @/.snapshots/01
Pour contrôler le sous‐volume sur lequel Ubuntu démarre, on pourra donc au choix supprimer le montage de la racine sur le volume /@
et s’appuyer sur le volume par défaut, ou renommer le répertoire /@
en un autre sous‐volume et transférer l’instantané 01
vers /@
:
# liste des sous‐volumes ;
root@ubuntu:/# btrfs sub list /
ID 257 gen 132 top level 5 path @
ID 261 gen 139 top level 257 path @/.snapshots/01
# je monte le volume racine (id=5)
root@ubuntu:/# mount -o subvolid=5 /dev/sda5 /mnt
root@ubuntu:/# ls -alt /mnt/
total 16
drwxr-xr-x 1 root root 244 déc. 29 13:08 ..
drwxr-xr-x 1 root root 244 déc. 29 13:08 @
drwxr-xr-x 1 root root 2 déc. 27 12:50 .
# le sous‐volume /@ est bien visible
root@ubuntu:/# ls -alt /mnt/@/
total 32
drwxrwxrwt 1 root root 94 janv. 2 13:57 tmp
drwx------ 1 root root 88 déc. 29 13:17 root
drwxr-xr-x 1 root root 4 déc. 29 13:16 .snapshots
drwxr-xr-x 1 root root 244 déc. 29 13:08 .
drwxr-xr-x 1 root root 2894 déc. 28 20:32 etc
…
Permutation du sous‐volume /@
avec /@/.snapshots/01
:
root@ubuntu:/mnt# mv @ @_old
root@ubuntu:/mnt# mv @_old/.snapshots/01 @
root@ubuntu:/mnt# ls
@ @_old
root@ubuntu:/mnt# reboot
Connection to 192.168.0.155 closed by remote host.
Connection to 192.168.0.155 closed.
Concernant GRUB, je supprime la partie rootflags
:
cat /boot/grub/grub.cfg
...
linux /vmlinuz-4.4.0-21-generic root=UUID=... ro rootflags=subvol=@
Redémarrage…
# c’est bien le sous‐volume ID 261 qui est monté par défaut
root@ubuntu:/root# btrfs sub get-default /
ID 261 gen 151 top level 5 path @
# liste des sous‐volumes (les chemins d’accès ont changé)
root@ubuntu:/root# btrfs sub list /
ID 257 gen 144 top level 5 path @_old
ID 261 gen 149 top level 5 path @
# comment est montée la partition racine
root@ubuntu:/root# mount | grep btrfs
/dev/sda5 on / type btrfs (rw,relatime,space_cache,subvolid=261,subvol=/@)
/dev/sda7 on /home type btrfs (rw,relatime,space_cache,subvolid=257,subvol=/@home)
root@ubuntu:/root# btrfs sub list /
ID 257 gen 144 top level 5 path @_old
ID 261 gen 149 top level 5 path @
Utilisation de YUM et DNF
Les gestionnaires de paquets YUM et DNF sont présents dans Fedora et dérivées (CentOS, RHEL…). À terme, DNF vise à supplanter YUM. Dans le cas d’espèce, YUM possède un greffon nommé yum-fs-snapshot qui, lorsqu’activé, prend automatiquement une image du système de fichiers (SF) avant d’entamer toute transaction. Ainsi, à la fin de cette dernière, arriverait‐il qu’on souhaite restaurer le système de fichiers à son état antérieur qu’il suffira d’effectuer un rollback. Ce greffon a été porté sur DNF et est mentionné dans les cas d’utilisation sur le Wiki de Btrfs.
Travaux pratiques
Installation de snapper et de son greffon dans DNF ; Btrfs est supposé déjà configuré :
dnf install snapper python3-dnf-plugins-extras-snapper
Configurer snapper sur un (sous‐)volume indiqué. Par défaut, la configuration est appelée « root » :
snapper create-config /
snapper list-configs
snapper list
Modifier le système sans prendre d’instantané :
dnf --disableplugin=dnf.plugin.snapper install <FOO>
Modifier le système en prenant un instantané. Les différents instantanés sont numérotés et leurs numéros figurent dans les sorties de snapper list
:
dnf update <FOO>
snapper list
Supposons que la mise à jour précédente a entraîné la création de l’instantané no N. Pour revenir à l’instantané no N-1 :
snapper rollback <N-1>
systemctl reboot
À noter que DNF dispose de ses propres transactions qu’il ne faudrait pas confondre avec celles de snapper et qui sont elles aussi dotées de mécanismes de retour en arrière :
1- historique de toutes les transactions ; la première colonne indique leur numéro ;
2- annuler toutes les transactions accomplies après la transaction no X.
dnf history # 1-
dnf history rollback <X> # 2-
Conclusion
La mise en œuvre d’instantanés sur la partition racine permet d’enregistrer une image disque d’un système GNU/Linux qui pourra être réutilisée en cas d’incident suite à une mise à jour du système.
Btrfs est un système de fichiers dont la mise en œuvre est simple. Il permet de créer des instantanés très facilement. Il est possible sur certaines distributions GNU/Linux d’adjoindre un greffon au gestionnaire de paquets, ce qui facile la mise en œuvre des instantanés et des retours en arrière (Fedora, Arch Linux). Pour les autres distributions (Debian, Ubuntu), il faudra passer par une mise en œuvre manuelle en attendant que les communautés prennent en charge ces fonctionnalités.
On peut lister ici les outils complémentaires :
- snapper ;
- NixOS (dépêche en cours de rédaction) ;
- DNF + greffon ;
- apt-btrfs-snapshot ;
- grub-btrfs : permet d’ajouter aux menus GRUB, les sous‐volumes Btrfs présents à la racine.
Aller plus loin
- Documentation de Btrfs (209 clics)
- Wiki Btrfs sur Archlinux (144 clics)
- Snapper (184 clics)
# Snapshot auto sous Debian avec snapper
Posté par THE_ALF_ . Évalué à 5.
Bonjour,
une petite info complémentaire concernant Debian lorsque snapper est installé (je ne sais pas à quel point ceci est spécifique à Debian): des snapshots sont automatiquement faits avant et après chaque installation ou désinstallation par apt. De mémoire, je n'ai rien configuré, donc je penses que c'est automatiquement le cas après une installation de snapper. Bref, il n'y a pas à se préoccuper de faire des snapshots de manière manuelle, une simple installation permet de créer ce qu'il faut pour revenir en arrière si une install s'est mal passée.
# Snapshot
Posté par matteli . Évalué à 2.
A ma connaissance, XFS ne permet pas le snapshot. Tu confonds peut être avec ZFS.
[^] # Re: Snapshot
Posté par Davy Defaud . Évalué à 3.
Oui et non : https://en.wikipedia.org/wiki/XFS#Snapshots
# grub
Posté par Psychofox (Mastodon) . Évalué à 6. Dernière modification le 05 février 2018 à 14:36.
Tu mentionnes vaguement grub-btrfs en dernière partie, et j'espère que tu prendras le temps d'en montrer un aperçu dans une future dépêche, ce type de fonctionnalités commence essentiellement à avoir de l'intérêt au moment où tu peux choisir le snapshot sur lequel tu vas pouvoir redémarrer ton système. Ce n'est pas drôle d'avoir recours à un système live en cas de problème.
En attendant, le lienz pour ceux qui veulent un aperçu du fonctionnement .
[^] # Re: grub
Posté par Marc Quinton . Évalué à 4.
Précisions : cette news était au départ rédigée à la première personne du singulier. La forme est restée. Il s'agissait pour moi d'illustrer mon expérience initiale concernant le sujet des snapshots avec BTRFS. Par la suite, plusieurs contributeurs ont apporter de nouveaux éléments. Je suis donc un peu gêné quand je vois ta remarque commencer par : "Tu mentionnes …". Il est vrai qu'il n'y a pas beaucoup de littérature en français sur ce sujet.
[^] # Re: grub
Posté par collinm (site web personnel) . Évalué à 3.
c'est par défaut dans suse
www.solutions-norenda.com
[^] # Re: grub
Posté par AR7 (site web personnel) . Évalué à 1.
La solution d'openSUSE est techniquement différente. Elle a ses propres limites et c'est pour ça que c'est intéressant de voir ce qui se fait ailleurs…
Je n'ai pas essayé grub-btrfs mais visiblement il faut régénérer le
grub.cfg
sur une restauration – je pense qu'il faudrait aussi régénérer lecore.img
en toute rigueur ou alors j'ai pas compris – mais ça a l'avantage de fonctionner avec un grub sans patch.# Fiabilité
Posté par cluxter . Évalué à 2.
Le système de snapshots/rollbacks intégré à Btrfs m'intéresse au plus haut point depuis un moment, mais j'ai une certaine réticence à utiliser Btrfs en production. J'avais pris la peine de lire tout un tas d'articles sur le sujet mais j'en étais arrivé à la conclusion que pour le moment il était plus sûr de rester sur ext4. Ceci dit c'était il y a un petit moment et j'ai l'impression qu'ils ont résolu plus ou moins tous les problèmes de fiabilité : https://btrfs.wiki.kernel.org/index.php/Status#Overview
Est-ce que vous pensez que c'est suffisamment fiable pour un serveur web ou une grosse base de données par exemple ? Si vous avez des références récentes sur le sujet je suis preneur.
[^] # Re: Fiabilité
Posté par Pol' uX (site web personnel) . Évalué à 4.
Aucune idée de la fiabilité (et perso j'ai actuellement la même interrogation que toi), mais de fait aujourd'hui gparted annonce un support complet de la bête, ce qui est déjà en soit une garantie sur le service après vente…
(Je me suis fait avoir par du reiser 4 il y a 13 ans …)
Adhérer à l'April, ça vous tente ?
[^] # Re: Fiabilité
Posté par Marc Quinton . Évalué à 2.
aucun soucis pour ma part sur plusieurs serveurs en PROD. Je touche du bois, mais sans inquiétude. Je n'utilise pas le RAID (multi-volume) le point faible (si on peut dire), sur ce FS. Les snapshots sont un véritable bonheur.
# Sans vouloir casser l'optimisme...
Posté par Dabowl_75 . Évalué à 6.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/7.4_release_notes/chap-red_hat_enterprise_linux-7.4_release_notes-deprecated_functionality
[^] # Re: Sans vouloir casser l'optimisme...
Posté par Marc Quinton . Évalué à 3.
c'était l'objet de ce journal : https://linuxfr.org/users/saltimbanque/journaux/btrfs-ne-serait-plus-le-futur
[^] # Re: Sans vouloir casser l'optimisme...
Posté par foobarbazz . Évalué à 2.
C'est juste Red Hat qui tire dans les pattes d'Oracle, en tentant de générer du FUD.
[^] # Re: Sans vouloir casser l'optimisme...
Posté par Albert_ . Évalué à 3.
Sauf que ce n'est plus Oracle qui est derriere Btrfs mais le pourquoi de cette depreciation alors que il parait que BTRFS est utilise en prod dans des trucs comme Facebook c'est en effet curieux.
Perso, je suis repasse a ext4 parceque en fait c'est un peu chiant ce systeme avec les problemes de "balancing" a gerer a la main et le fait que, comme c'est dit ici, les snapshots c'est sexy mais si c'est pas integre automatiquement a ton systeme de boot ben voila … ca sert a rien. Alors tant que grub ou le boot de systemd ne permettront pas de redemarrer sur le systeme precedent cela ne servira pas a grand chose.
Autrement je n'ai jamais eu de probleme de perte de donnees je dois avouer, ce qui parait normal mais bon n'est pas le cas sous tous les systemes de fichiers…
[^] # Re: Sans vouloir casser l'optimisme...
Posté par claudex . Évalué à 4.
Parce que ça coûte d'avoir des gens qui connaissent bien ce système pour pouvoir répondre aux besoins (et tickets) des clients. Donc, si ça n'apporte pas suffisamment d'avantages, ils préfèrent mettre leur argent ailleurs.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.