Comment récupérer une partition BTRFS qui ne sera pas montée?
L'installation de 12.04 a continué à échouer et la solution consistait à faire en sorte que le programme d'installation ignore la partition btrfs que j'utilisais précédemment pour/home.
Maintenant qu'il est installé, j'essaie de le faire monter la partition btrfs afin de pouvoir accéder à mes 70 Go de fichiers. Il ne montera pas et btrfsck affichera les erreurs avec les trois lignes suivantes:
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
parent transid verify failed on 31302336512 wanted 62455 found 62456
Quelqu'un peut-il me dire comment faire fonctionner cette partition? J'ai lu en ligne que je peux probablement récupérer les données en utilisant btrfs-restore, mais je ne trouve ce programme nulle part.
Moyen le plus simple
btrfs-zero-log /dev/sda5
Vous avez ce problème car une transaction (écriture ou suppression) est bloquée dans le journal du journal et que le disque ne lui correspond pas.
Comment ça marche:
Ainsi, lorsque les données sont écrites en premier, elles sont écrites dans le journal, puis sur le disque (ou en même temps, mais le journal enregistre simplement les métadonnées relatives à l'écriture à venir - je ne suis pas sûr ... nous avons besoin de plus de recherches sur cette partie) ...
Quoi qu’il en soit, si vous éteignez le système au milieu de cette opération d’écriture/suppression ou que vous faites quelque chose qui le rafraîchit (démontez la clé USB qui contient votre point de montage btrfs), puis, s’il revient, ce montage ne fonctionnera pas (dmesg et btrfsck vous montrera les erreurs plus en détail) ...
En regardant dmesg, vous verrez ces mêmes messages transmis.
Vous verrez quelque chose comme ça:
parent transid verify failed on 109973766144 wanted 1823 found 1821
Cela signifie que btrfs voulait la transition 1826 (c'était sur le journal) mais sur le disque qu'il voyait 1821. Le disque était donc à 2 transactions de la synchronisation avec le journal. Personnellement, je risquerais un journal brtfs-zero-log ici simplement parce que ce ne sont que 2 transactions. Mais pour être sûr à 100% s'il s'agit de vos seules données (d'ailleurs, si vous avez des données critiques, vous ne devriez JAMAIS JAMAIS en avoir une seule copie, gardez toujours une copie/sauvegarde dans un autre emplacement sûr - blâmer les créateurs de btrfs ne le ferait pas. justifier contre les personnes leur manque de responsabilité de ne pas avoir de sauvegarde - btrfs n'est pas une solution de sauvegarde, c'est un système de fichiers - rien n'est une solution de sauvegarde vraie à part le fait d'en avoir une copie ailleurs - pas même la parité ou les disques en miroir, une vraie sauvegarde est assis quelque part sous terre dans les Alpes tandis que sa copie active est dans votre bureau au Texas)
parent transid verify failed on 31302336512 wanted 62455 found 62456
Ici, le journal manque 62455 mais le disque est en avance à 62456, donc dans votre cas, je voudrais simplement effacer le journal. Le journal n'a pas mis à jour cette fois. Encore une fois, je vous ai parlé de sécurité, si ce sont vos seules données et ses méga critiques (honte à vous), et je ferais d’abord les opérations ci-dessous pour assurer votre sécurité.
L'exécution de btrfsck/dev/sda5 (qui d'ailleurs ne fait qu'une vérification en lecture seule, est donc totalement sûre, ses seules options btrfsck dont vous devez vous soucier) vous montreront également ces messages.
Mais méfiez-vous si ces données sont critiques, je le ferais d'abord (comme l'ont dit les autres hommes)
mount -t btrfs -o rootflags=recovery,nospace_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o rootflags=recovery,nospace_cache,clear_cache /dev/sda3 /mnt/sda3
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
Ensuite, cp ou rsync tous vos fichiers dans un emplacement sûr, puis lorsque le coffre-fort est sauvegardé, btrfs-zero-log, si c’est une opération réussie, vous perdez beaucoup de temps à sauvegarder votre système (mais s’il échoue, vous sauvegardez votre cul)
Ensuite, si les montages échouent, effectuez une restauration btrfs (sauvegarde du système, si je comprends bien, c’est une opération pouvant être reprise, mais il continue de demander Y ou y de temps en temps, alors regardez le résultat)
btrfs restore /dev/sda5 /USB
Ensuite, lorsque vous êtes en sécurité (lorsque la restauration de btrfs est terminée), exécutez btrfs-zero-log, si vous effectuez une opération réussie, vous perdez du temps à sauvegarder votre système (mais si vous échouez, vous ne sauvegardez que votre cul)
Vous pouvez lancer l'écran en premier
screen /bin/bash
btrfs restore /dev/sda5 /USB
NOTE CÔTÉ DE L'ÉCRAN
Pour détacher (la commande sera toujours exécutée): CONTROL-a puis tapez ": detach" sans les guillemets puis appuyez sur ENTREE
Une autre façon de se détacher: fermez ensuite PuTTY ou votre terminal et il se détachera (la commande/restauration sera toujours exécutée).
Pour le vérifier, il suffit de passer à l'écran:
screen -x
screen -x sera attaché aux sessions, même s'il est détaché, et contrairement à -h dit, il sera attaché même s'il est déjà attaché également)
Si vous avez plusieurs écrans, screen-x vous dira que vous devez être plus précis pour vous connecter à la session:
screen -ls
pour la liste de toutes les sessions, il est facile de s'en souvenir.
pour voir le PID, vous pouvez également le faire:
ps aux | grep screen
Une fois que vous avez trouvé votre PID, lancez l'écran comme ceci:
screen -x PID
Cela s'attachera à une session spécifique. Vous pouvez avoir plusieurs sessions/putts attachés au même écran (ils produiront le même texte, vous pourrez taper des commandes dans l’une et elles seront reproduites dans l’autre PuTTY).
Montez au démarrage en utilisant les options de montage root fs:
rootflags=recovery,nospace_cache
ou
rootflags=recovery,nospace_cache,clear_cache
La liste complète des options de montage de btrfs devrait être ici https://btrfs.wiki.kernel.org/index.php/Mount_options et d'autres éléments peuvent également être utiles, tels que noatime, nodatacow (corrigé bug du noyau pour moi en me donnant une chance de copier mes fichiers).
Ajoutez-le à votre grub.cfg/menu.lst, ou tapez-le lors du démarrage.
Nospace_cache rendra les choses terriblement lentes. Il suffit de démarrer, d’attendre (longtemps), d’arrêter et d’amorcer normalement.
J'ai eu la même chose il y a quelques jours, et ce qui précède l'a corrigé. Mais aussi après, il y a eu quelques problèmes d'espace ... l'espace signalé n'est pas à 100%, mais il peut toujours être saturé.
==
Je pense que vous pouvez également ajouter les mêmes options dans votre fstab, par exemple:
UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf /home btrfs defaults,recovery,nospace_cache,clear_cache,subvol=@home 0
2
Si vous tentiez de récupérer un répertoire/home monté sur une partition avec UUID=0237alksfadg-lhdfkj3624-4fdfjb-9dsfe2d-dfddaf.
J'ai eu le même problème. Après un redémarrage, je ne pouvais plus monter ma partition btrfs. Cependant, aucune des solutions mentionnées ici ne pourrait le résoudre.
Ce qui a résolu le problème pour moi, c’était de mettre à jour le noyau de 3.10 à 3.12. Après un redémarrage, la partition btrfs pourrait être montée à nouveau.
mount -t btrfs -o ro,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3
ro = lecture seule
Ce travail pour moi
La réponse de Peter a résolu le problème pour moi, mais pas sous Ubuntu. J'avais une partition /home btrfs'd qui a bien sûr été corrompue. Le système ne pouvait pas démarrer car il se trouvait sur fstabname__. Je suis entré en mode maintenance, j'ai coupé la ligne avec cette partition et démarré normalement (j'avais une partition de rechange ext4 que je pouvais utiliser comme /home).
J'ai monté la partition manuellement avec la commande suivante:
mount -t btrfs -o recovery,nospace_cache,nospace_cache /dev/sda3 /mnt/sda3 et a été en mesure de sauvegarder mes données. Bien qu'il ne fallut pas longtemps pour le monter. Alors merci Peter.