Journal Btrfs restore à la rescousse

Sommaire

• Introduction
• Élément perturbateur
• Espoir
• Résignation
• Happy ending
• Et du coup, est-ce que tu vas repasser à ext4 ?

Introduction

Btrfs, c'est un système de fichiers qui me laisse l'impression de rester éternellement jeune (« modern », dirait sa documentation officielle). Et qui paraît également beaucoup plus intéressant que la musique forte des voisins qui accompagne la rédaction de ce présent journal.

Introduit en 2009 dans le noyau Linux 2.6.29, stable depuis 2013 avec le noyau 3.10, il présente des fonctionnalités sympas comme les sous-volumes et les instantanées (snapshots), la compression transparente, le RAID et le redimensionnement à chaud et des mécanismes de cohérences / sommes de contrôles pour vérifier que tout va bien.

C'est basé sur les B-trees (B-Trees File System—n'est-ce pas—Better FS), et c'est trop bien, même je ne sais pas trop ce que c'est.

Il est souvent comparé à ZFS, qui présente des fonctionnalités similaires mais qu'on n'a pas la chance d'avoir de façon native sous Linux à cause d'une incompatibilité de licences. D'ailleurs, les deux systèmes appartenant à Oracle, on peut se demander si Oracle trouve ça plus simple de redévelopper un système de fichiers de zéro que changer la licence d'un système de fichiers performant et éprouvé. (Ouh, les pics, ça FUSE !)

Ça marche très bien la plupart du temps, mais c'est quand même jeune :

• il y a des fonctionnalités assez importantes encore expérimentales (les quotas)
• des trucs prévus qui tardent à arriver (la prise en charge du chiffrement)
• je soupçonne Btrfs de faire faire des pics occasionnels d'utilisation du processeur (d'un coup, on voit un kworker bouffer 100% du CPU dans top)—en même temps je ne le ménage pas
• on ne sais jamais trop quel espace libre il reste sur le disque
• et surtout, les outils de vérification et de réparation du système de fichiers paraissent un peu rudimentaires au premier abord.

Rudimentaires, les outils de récup' de Btrfs ?

Élément perturbateur

Si vous souhaitez participer pleinement à ce journal avec votre propre partition Btrfs, il vous faut :

• Qemu, et
• une idée de génie du style : « mais en fait, si je veux démarrer une distribution dans une machine virtuelle sans m'embêter, il suffit de faire un instantané des sous-volumes du système en cours de fonctionnement, et démarrer sur ces instantanés plutôt que sur le système principal, comme ça pas de conflit ! », ou tout autre idée similaire qui mènera à une catastrophe.

Spoiler : en fait, ça se passe mal. Ça ne marche pas d'avoir deux pilotes Btrfs sur un même volume, même si on les fait fonctionner sur des sous-volumes différents. Essayez avec un autre système de fichiers ou une voiture, ça se passera probablement pareil.

Espoir

Direction Internet et la documentation de Btrfs pour chercher de l'aide. Les symptômes : impossible de monter le système de fichiers. Mais Grub trouve le noyau et l'initrd et arrive à les booter, donc ça ne doit pas être trop mal, non ? Dans les logs, on voir apparaître deux erreurs du genre :

parent transid verify failed on 14266105856 wanted 464223 found 464221

(je n'ai pas pris de notes pendant l'incident, donc je fais les choses de mémoire. Aussi, il se peut que l'histoire soit légèrement imprécise voire romancée et que les messages d'erreurs soient des copiés collés de Stack Overflow).

Une des première choses qu'on apprend, c'est que btrfs check ne sert pas à grand chose, et que btrfs check --repair est même possiblement dangereux. Ah. Je ne sais pas vous, mais si je suis planté, mort de panique sans internet devant mon shell, c'est la première chose que je découvre et que j'essaie…

La doc nous conseille, en tout premier lieu, de lancer btrfs scrub sur le système monté. Option éliminée, je ne peux pas monter, j'ai éteint l'ordinateur dès que mon cerveau a réalisé que j'étais en train de faire une grosse connerie.

Donc, regardons la doc de Btrfs:

In a nutshell, you should look at:

• btrfs scrub to detect issues on live filesystems
• look at btrfs detected errors in syslog (look at Marc's blog above on how to use sec.pl to do this)
• mount -o ro,recovery to mount a filesystem with issues
• btrfs-zero-log might help in specific cases. Go read Btrfs-zero-log
• btrfs restore will help you copy data off a broken btrfs filesystem. See its page: Restore
• btrfs check --repair, aka btrfsck is your last option if the ones above have not worked.

Regarder les erreurs dans le syslog, ça c'est fait.
Monter avec l'option recovery: ça ne fonctionne pas.

btrfs-zero-log est conseillé sur cette question StackOverflow https://stackoverflow.com/questions/46472439/fix-btrfs-btrfs-parent-transid-verify-failed-on pour le message que j'obtiens.

# btrfs rescue zero-log /dev/sdb5
[...]
# mount /dev/sdb5
mount: /dev/sdb5: Désolé vieux, je ne peux rien pour toi, ta partoche a vraiment une sale gueule.

Arf. Ça fait très largement écho à ce beau message d'avertissement sur la page https://btrfs.wiki.kernel.org/index.php/Btrfs-zero-log :

btrfs-zero-log n'est pas un outil à tout réparer, malgré ce que beaucoup de gens croient et affirment sur tout l'internet. Vous n'avez généralement pas besoin de l'utiliser

La description de btrfs restore me dit que ça consiste à copier toutes les données de ma partition. Mais ce que je veux vraiment faire, c'est réparer ma partition. Je tente un coup de btrfs check --repair contre toute recommandation, et là : Rien. Ça ne fonctionne pas.

btrfs rescue chunk-recover ne sauve rien non plus.

Résignation

Bref, tous ces outils de récupération, c'est un peu la foire. On vire les 36000 snapshots des sources Android qui prennent des téras sur mon deuxième disque dur de 500 Gio, on supprime les trucs qui traînent depuis aussi longtemps que la vaisselle dans mon évier, et on lance la récup'.

… Pour découvrir qu'en fait, par défaut, btrfs restore ne restaure pas :

• les liens symboliques
• les attributs / droits UNIX des fichiers
• un tas d'autres choses
• et surtout, si vous aviez des instantanées / sous-volumes, il ne va les restaurer, par défaut. C'est con, j'ai mon /home dans le sous-volume @home et ma racine dans mon sous-volume @…

… Heureusement, une option permet de récupérer les sous-volumes ! Mais ils sont copiés comme des dossiers simples. Donc d'un coup, si vous aviez trois instantanées de vos données, ça va tout dé-dupliquer et ça prendre trois fois plus de place que sur l'original. Ce qui fait que clairement, ma partition de destination de 500 Gio n'était pas assez grosse pour accueillir tout ce qu'il y avait dans ma partition de 450 Gio toute cassée.

Sans plus attendre, la commande pour restaurer les données est :

yes | btrfs restore -s -x -m -S -v -i -o /dev/sdb5 /mnt/destination/

Explications :

• -s récupère aussi les sous-volumes
• -x récupère aussi les attributs étendus
• -m récupère aussi les métadonnées (droits, dates)
• -S récupère aussi les liens symboliques
• -v pour moins s'ennuyer, ça fait défiler des trucs à l'écran (et surtout on sait où on en est dans la récupération)
• -i ne pas s'arrêter à cause des erreurs (très important pour la suite, et de toute façon si on veut tout récupérer on ne veut pas que ça s'arrête)
• -o pour réécrire les fichiers qui existeraient déjà sur la destination (oui, il a fallu que je relance la commande plusieurs fois en apprenant à l'utiliser)
• yes, parce que même avec l'option -i, btrfs restore s'arrête de temps en temps en affichant We seem to be looping a lot on XXX, do you want to keep going on ? (y/N):, donc oui on veut que ça continue.

Et là, la petite astuce quand on n'a pas assez de place, c'est d'empêcher la récupération des dossiers / instantanés volumineux soit en créant des sous-volumes btrfs en lecture seule sur la destination là où les différents instantanées doublons seraient placés, quitte à les récupérer séparément plus tard:

btrfs subvolume create @plonk
btrfs subvolume snapshot -r @plonk la/ou/la/restoration/doit/etre/bloquee

Soit en créant un dossier la/ou/la/restoration/doit/etre/bloquee et de lancer:

  chattr +i la/ou/la/restoration/doit/etre/bloquee

ce qui aura pour effet de mettre le dossier en lecture seule, même pour root. chattr +i pour enlever la lecture seule.

Et pour restaurer un dossier particulier (précédemment ignoré par exemple) :

• soit on restaure tout, en bloquant tous les dossiers déjà restaurés avec les techniques présentées juste avant
• soit avec les expressions régulières dont le format est assez infâme (c'est beaucoup plus rapide). Je recommande vivement cette page pour construire la bonne expression régulière, ça fonctionne bien : http://www.kossboss.com/?p=2277

Happy ending

Bref. J'ai retrouvé toutes mes données et perdu beaucoup de temps, encore plus qu'avec la rédaction de ce journal (c'est dire). D'ailleurs, mon /home actuel est le résultat de btrfs restore, et ça fonctionne étonnamment bien. Tellement, que c'est frustrant qu'il n'y ait pas d'outil capable de réparer la partition.

Et heureusement, parce que Btrfs n'est pas pris en charge par photorec, et cette prise en charge sera(it) probablement un peu compliquée à implémenter, vu le fonctionnement « copie à l'écriture » (copy on write) de Btrfs, qui consiste, à chaque écriture dans fichier, d'écrire sur un nouveau bloc plutôt que directement sur place. Ce qui donne des fichiers non-contigu assez rapidement. Or, si j'ai bien compris, photorec récupère les fichiers contigus sans interpréter le format de la partition.

Et du coup, est-ce que tu vas repasser à ext4 ?

Non :-) J'aime beaucoup trop pouvoir faire btrfs subvolume delete @ par erreur et avoir la joie de retrouver ce bon vieux « ls : Commande introuvable » .

Mais je vais continuer les sauvegardes régulières !