Journal Btrfs restore à la rescousse

Posté par .
Tags :
31
15
sept.
2018

Sommaire

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 !

  • # Éliminé

    Posté par (page perso) . Évalué à 3 (+2/-1).

    Système de quota non finit, pas moyen de savoir quel espace il reste -> impossible à utiliser en production en entreprise pour moi ;-)

    • [^] # Re: Éliminé

      Posté par (page perso) . Évalué à 6 (+4/-0).

      root@nas01 [~] btrfs filesystem df /mnt/data
      Data, RAID10: total=4.86TiB, used=4.67TiB
      System, RAID10: total=64.00MiB, used=544.00KiB
      Metadata, RAID10: total=7.00GiB, used=5.78GiB
      GlobalReserve, single: total=512.00MiB, used=0.00B
      
      root@nas01 [~] btrfs filesystem usage /mnt/data
      Overall:
          Device size:                  14.55TiB
          Device allocated:              9.74TiB
          Device unallocated:            4.81TiB
          Device missing:                  0.00B
          Used:                          9.34TiB
          Free (estimated):              2.60TiB      (min: 2.60TiB)
          Data ratio:                       2.00
          Metadata ratio:                   2.00
          Global reserve:              512.00MiB      (used: 0.00B)
      
      Data,RAID10: Size:4.86TiB, Used:4.67TiB                                                                                                                                                                            
         /dev/sda1       1.22TiB                                                                                                                                                                                         
         /dev/sdb1       1.22TiB
         /dev/sdc1       1.22TiB
         /dev/sdd1       1.22TiB
      
      Metadata,RAID10: Size:7.00GiB, Used:5.78GiB
         /dev/sda1       1.75GiB
         /dev/sdb1       1.75GiB
         /dev/sdc1       1.75GiB
         /dev/sdd1       1.75GiB
      
      System,RAID10: Size:64.00MiB, Used:544.00KiB
         /dev/sda1      16.00MiB
         /dev/sdb1      16.00MiB
         /dev/sdc1      16.00MiB
         /dev/sdd1      16.00MiB
      
      Unallocated:
         /dev/sda1       2.42TiB
         /dev/sdb1       2.42TiB
         /dev/sdc1       2.42TiB
         /dev/sdd1       2.42TiB
      
      root@nas01 [~] df -h /mnt/data 
      Filesystem      Size  Used Avail Use% Mounted on
      /dev/sda1       7.3T  4.7T  2.7T  65% /mnt/data
      
  • # B-Trees vs CoW

    Posté par (page perso) . Évalué à 3 (+1/-0). Dernière modification le 15/09/18 à 12:50.

    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.

    Des arbres binaires (à deux branches, quoi).

    Sinon, certes mais ReiserFS était déjà basé sur les B-Trees et n'avait pas les « qualités » de btrfs. D'après wikipedia : « Apple's filesystem HFS+, Microsoft's NTFS,[8] AIX (jfs2) and some Linux filesystems, such as btrfs and Ext4, use B-trees. »

    Il me semble que le grand apport de btrfs c'est le copy on write qui donne des facilités pour la gestion efficace des snapshots avec partage de données : les FS historiques sous Linux n'implantent pas ça.

    Adhérer à l'April, ça vous tente ?

  • # Sauvegardes / snapshots

    Posté par (page perso) . Évalué à 2 (+0/-0).

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

    J’utilise snapper, ça marche plutôt bien.

    • [^] # Re: Sauvegardes / snapshots

      Posté par . Évalué à 1 (+0/-0). Dernière modification le 15/09/18 à 21:02.

      Alors snapper, j'aime bien et ça peut être pratique quand on a un disque avec en peu trop de place, mais ce n'est pas non plus ce que je qualifierais de « sauvegarde ».

    • [^] # Re: Sauvegardes / snapshots

      Posté par . Évalué à 6 (+5/-0). Dernière modification le 16/09/18 à 04:28.

      Merci !

      Je comptais écrire un journal sur mon système de sauvegarde, ça implique nextcloud, rsync et les instantanées btrfs. À 3h du mat, mes fichiers sauvegardés sont à trois endroits différents et j'ai accès aux versions quotidiennes de ces fichiers si je souhaite consulter le passé.

  • # Chez la concurrence

    Posté par . Évalué à 4 (+2/-0).

    Ç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.

    Alors pour ce que ça vaut, je monte régulièrement des snapshots RBD de volumes XFS sur la même machine que le volume "parent", sans aucune difficulté (et c'est assez pratique pour exposer ça aux clients Windows à la sauce "Versions précédentes").

    Le seul truc, c'est qu'il faut passer quelques options qui font peur au montage du snapshot :

    mount -t xfs /dev/rbdXX /monsnapshot -o ro,norecovery,nouuid
    Le norecovery évitant que le montage ne vérifie la cohérence du volume (qui ne l'est pas forcément, du coup, selon quand/comment le snapshot a été pris).

    Le nouuid contournant une fonctionnalité de XFS qui "tague" ses volumes avec un identifiant unique, entre autre pour éviter qu'on monte deux fois le même volume. Ce qui :
    * n'est pas très utile en RBD, vu qu'on peut fort justement le monter depuis deux machines (et tout casser)
    * est contreproductif pour snapshot qui a donc, forcément, l'UUID de son parent.

    À priori, ça fonctionnerait pareil avec un volume manager "local", type LVM.

    • [^] # Re: Chez la concurrence

      Posté par (page perso) . Évalué à 3 (+2/-0).

      Question naïve, qu'est-ce qu'un snapshot RBD ?

      • [^] # Re: Chez la concurrence

        Posté par (page perso) . Évalué à 4 (+1/-0).

        RDB, c'est le système de stockage block device de Ceph.

        « 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

    • [^] # Re: Chez la concurrence

      Posté par . Évalué à 3 (+1/-0).

      Oui mais monter le volume en read-only, c'est pas drôle. Je pense que raphj parlait de monter en R/W…

      • [^] # Re: Chez la concurrence

        Posté par . Évalué à 1 (+0/-0).

        En passant le périphérique /dev/sdX à Qemu sans option particulière, c'est clair que c'est lecture / écriture direct depuis le boot ! On peut espérer qu'aucune écriture ne se fait avant le démarrage du noyau Linux, mais après…

        Il y a peut-être une option dans Qemu qui permet d'avoir un disque dur virtuel en lecture seul ? Peut-être en faisant passer le disque dur pour un cdrom ?

        • [^] # Re: Chez la concurrence

          Posté par . Évalué à 2 (+0/-0).

          man qemu-system :

              -drive option[,option[,option[,...]]]
              […]
              readonly
                         Open drive file as read-only. Guest write attempts will fail.
          

          Mais tu ne vas pas aller très loin avec ton système qui ne pourra rien écrire sur le disque.

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.