jeremyb14 a écrit 33 commentaires

Merci pour ces précisions, je suis d'accords, btrfs est excellent dans le bon setup hardware, pour l'ECC je n'avais pas vu a l'epoque sinon j'aurais acheté cette Ram mais bon trop tard je suis passé sur Ext4 et pour la compression je ne m'en sert pas de toute facon.

Oui c'est vrai j'ai inversé : c'est BTRFS et non BRTFS
désolé.

J'en suis arrivé au même constat, c’est sûrement un solide FS en environnement contrôlé mais pour le perso domestique de base vaut mieux un autre.Ext4 est éprouvé,d’ailleurs peut être un jour brtfs lui succedera qui sait..

d'accords donc j'ai juste pas eu de chance car j'ai utilisé ce FS à titre domestique pour le stockage de mes archives (8To + 8To en backup) et j'ai eu un incident environ tous les 8-12 mois, j'ai pu tout récupérer à chaque fois mais la perte de temps additionné est colossal, il faut 30h pour réup 8TO avec brtfs restore.

Merci mais j'ai trouvé sur un forum, je ne suis pas assez calé sur ce FS pour avoir déduit moi-même …
tu as le même message visiblement,je ne sais pas si tu peux monter ton disque ou si tu est bloqué comme moi mais au moins en dernier recours on peux extraire nos données tant qu'il y a une superblock valide..
perso j’arrête BRTFS et je passe en EXT4
je pense que ce FS est très bien pour du Raid mais pour un usage classique c'est encore trop expérimental et mine de rien je n'ai jamais eu de probleme avec l'Ext4.J'ai essayé brtfs pendant 6 ans pour mes stockages et j'ai été *** tous les 8 mois.

Bon j'ai pu trouver comment exécuter un btrfs restore, je donne la soluce :

j'ai d’abords cherché des blocks valides pour pouvoir lire l’arborescence du FS avec :

sudo btrfs-find-root /dev/sdb1

    parent transid verify failed on 274579456 wanted 67934 found 67931
    parent transid verify failed on 274579456 wanted 67934 found 67931
    Superblock thinks the generation is 67934
    Superblock thinks the level is 0
    Found tree root at 447201280 gen 67934 level 0
    Well block 150192128(gen: 67933 level: 0) seems good, but generation/level doesn't match, want gen: 67934 level: 0
    Well block 88375296**(gen: 67932 level: 0) seems good, but generation/level doesn't match, want gen: 67934 level: 0

Puis j'ai lancé sudo btrfs restore -t 150192128 /dev/sdb1 /media/linux/DATA2

j'ai choisis le premier block valide sur les deux trouvés par
btrfs-find-root

-Well block 150192128 et Well block 88375296

ça semble fonctionner pour l'instant, mes données sont en train d’être copiées sur un autre HDD

j'ai lancé un btrfs rescue chunk-recover pour voir ce que ça donne
le btrfs rescue zero-log /dev/sdb1 donne :
```

parent transid verify failed on 274579456 wanted 67934 found 67931
parent transid verify failed on 274579456 wanted 67934 found 67931
ERROR: could not open ctree
```

Merci, j'ai testé les commandes suggérées dans ce post reddit :

-sudo btrfs rescue super-recover /dev/sdb1

All supers are valid, no need to recover
et

-sudo mount -o rescue=usebackuproot /dev/sdb1 /mnt

mount: /mnt: impossible de lire le superbloc à l’adresse /dev/sdb1.


PS : j'ai lancé : rsync --recursive --min-size=8192P-1 /media/jeremy/d8ddff72-49c7-4060-a10b-70123c4074d9 /media/jeremy/18dd994c-3e65-47f8-91d6-8dc7cf3b5828/ARCH --verbose --progress --dry-run

Sortie :
sending incremental file list

listing des fichiers puis :

sent 12.986.897 bytes received 62.340 bytes 41.757,56 bytes/sec
total size is 7.897.021.415.775 speedup is 605.171,12 (DRY RUN)

j'ai relancé en réel et c'est bon, les 20 000 dossiers de l'arborescence ont été copiés en 3s ! puissant ce Rsync
le Topic est clos, merci encore pour votre réactivité.

Merci pour cette piste, aprés avoir lu les réponses j'en déduit qu'il n'existe pas d'opérateur à cp pour exclure automatiaquement les fichiers dans une copie récursive, ce qui confirme mes recerches.
Je dois dupliquer une arborescence de dossier d'un disque dur de 8TO (plein !), rsync me parait pas mal en effet.
je vais lancer en dry-run pour voir.
merci

Merci beaucoup, ce ne sera pas utile pour ce cas ci mais je garde cette commande sous la main

oui ! c'est bien le cable USB qui à causé une erreur fatale

Merci je ne connaissais pas Btrfs Assistant, je vais tester
vous avez raison pour le disque, j'avais prévu de toute façon une fois restauré, de le débrancher et de le ranger bien au chaud
Je vais continuer l'archivage sur le 6To en attendant que le prix des 16 To baisse.
Du coup je garde BRTFS car il est supérieur au NTFS en terme de restauration et de prévention,
le dev avait raison, j'ai vérifié et j'ai perdu des données sur le second disque NTFS à cause du cable USB ( ça c'est pareil terminé la station d'acceuil USB, je repasse sur de l'interne SATA), sauf que contrairement au BRTFS pas de moyen de restaurer les fichiers avec leur noms et l’arborescence (les solutions de recouvrement de fichiers type Recuva, Stellar,R-studio,ect n'inclus pas l'arborescence ni le nom d'origine, ce qui est impraticable quand on à beaucoup de fichiers)
C’est la principale raison pour laquelle je vais rester sur BRTFS, (et petit plus mais il gère les caractères spéciaux dans les noms de fichiers)

J'ai activé la compression avant de lancer btrfs restore, je verrais à la fin la différence.

Petit PS mais je viens d'installer WinBRTFS sous W10 et il y a une GUI de gestion ! C'est un comble quand même en sachant qu'il n'y en a pas sous Linux !

Bon j'ai repris le btrfs restore depuis le début après avoir formaté mon disque de 6TO en BRTFS au lieu du NTFS, je vais pouvoir récupérer 100% des fichiers car je me suis aperçu que les erreurs de récupération (invalid argurment) que j'avais sur 0.2% de mes données étaient du à des caractères spéciaux dans le nom de fichiers.Je dois donc faire une restauration sur un disque Brtfs car NTFS ne comprends pas les caractères spéciaux.

J'ai eu une réponse d'un dev brtfs :

Question : Cause primaire de l'erreur "parent transid verify failed"

"C'est probablement le pont USB/SATA qui pose problème."

Question : Pourquoi mon second disque NTFS n'est pas impacté alors qu'il est branché dans la même station d'acceuil  ?

"Les autres systèmes de fichiers ne repèrent pas toujours les écritures abandonnées - btrfs effectue beaucoup de vérifications de la cohérence interne et détecte les problèmes plus tôt que les autres systèmes de fichiers. (Il est également très bon pour repérer la mauvaise mémoire vive, par exemple)."

Question : Pourquoi la réparation à été impossible ?

"Parce que les outils de réparation ne peuvent pas réparer une défaillance transidirectionnelle."

Voila l'info importante étant que les outils de réparations BRTFS ne peuvent rien face à une erreur de type : parent transid verify failed

-Question : si le disque est trop plein, est-ce que BRTFS peux planter ?
Non

Je pense que ce post est clos, merci à ceux qui auront pris le temps de me répondre.Portez vous bien

Merci ! J’espère avoir une explication même si je pense que le plantage est du à un trop plein de mon disque, ce qui empêché la réparation , j'envisage de reformater en activant la compression par defaut avec_ -o compress=zstd_ dans etc/fstab
Par contre j'aimerais savoir pourquoi lors de la restauration j'ai des fichiers irrécupérables avec cette sortie : "Invalid argument", je restaure présentement sur un disque NTFS, peut-être une histoire de caractères spéciaux ?

Merci ! je vais attendre que le Restore soit terminé ( Pourquoi vous n’avez pas choisi cette solution à l’époque?), je l'ai lancé hier et il est toujours en cours D’âpres les logs je suis en train de récupérer 99,8%, je vais avoir quelques centaines de fichiers perdus mais sur les 550 000 de ma partition c’est acceptable
Par curiosité j’irais voir si le salon IRC existe toujours pour leurs soumettre le lien vers ce post afin qu’ils identifie le problème car même si je repasse sur du NTFS cela m’intéresse en tant que technicien de comprendre et si ils y'en a qui ont les réponses ce sont bien les Devs.
Je fais de l’archivage depuis 15 ans et les 10 premières années j’ai été sur du NTFS, jamais je n’ai eu ma partition bloquée de la sorte, quelques corruptions de fichiers inévitables (suite au Chkdsk) mais rien de grave, par contre ces 5 dernières années de travail sur Brtfs, j’ai eu ce problème une fois par ans et même si j'arrive au final à presque tout récupérer la perte de temps n'est pas acceptable.

Edit ; je viens de ckecker le serveur IRC #Brtfs, personne dedans
Je n'utilise jamais IRC, j'ai pris le premier client que j'ai trouvé : Hexchat

oui j'y ai pensé,ce serait une excellente solution mais du coup le Btrfs restore ne vas récrire ce qui à été déplacé ?
je vais essayer je verrais bien, merci !

La commande sudo btrfs restore -i /dev/sdb1 continue avec succès pour l'instant, déjà 1 TO de récupéré et pas tant de fichiers perdus que ça, actuellement c'est un ratio de 0.1% de perte.
Je remarque que les erreurs proviennent de fichiers avec un long noms et la présence de ? ou ! dans le nom.
ça va prendre 48h au moins pour récupérer les 6TO/8TO, si quelqu’un me lit et connaît une solution pour restaurer les 2TO manquants à la fin sur un autre disque.Je remarque que la commande btrfs restore procède de façon séquentielle et alphabétique, j'ai cherché en vain un moyen de faire une sélection de l'arborescence que l'on veut restaurer.
Par exemple mon disque contient 7 dossiers majeurs A,B,C,D,E,F,G, les dossiers de A à E vont être copiés sur le disque de 6TO et j'aimerais pouvoir par la suite copier seulement F et G sur un autre disque.
Est-ce seulement possible ? j'ai vu que l'on pouvait créer des sous-volumes avec des dossiers et ensuite copier ces mêmes sous-volumes de façon sélective.

Faute de solution je devrais tout recommencer une fois que j'aurais trouvé un autre disque de 8TO

oui c'est vrai quoique nouveau nouveau, il existe depuis plus de 10 ans maintenant
Ce qui manque à mon sens c'est une GUI de gestion pour les néophytes (même si Gparted le prends en charge, cela se cantonne à des fonctions basiques)

J'ai lancé un sudo btrfs restore -i /dev/sdb1_ sur mon second disque NTFS de 6To (que je vide au fur et a mesure) pour voir ce que je peux déjà récupérer avec un peu de chance je pourrais compléter ce qui manque avec mon demi-backup en ligne.
je m'attends à 20% de perte , j'ai beaucoup de fichiers qui engendrent cette erreur pendant la restauration : failed: Invalid argument_

Une question mais si les 6TO venaient à étre remplis avant la fin du Restore, est-il possible de continuer sur un autre disque ?

Je viens d'apprendre que ma sauvegarde en ligne à été corrompue à 55%, c'est 15 ans de travail qui partent à la poubelle
Mon disque de 8 TO est désormais la seule copie intégrale de ce travail d’archivage,
Je vais le garder le temps de trouver comment réparer ce fichus système de fichiers, cela doit bien être possible, c'est sois-disant le FS du futur !
Sinon il me reste plus qu’a acheter un second disque de 8To et de tenter le Brtfs Restore (j’avais commencé à le lancer et ça fonctionne)

La commande sudo btrfs check /dev/sdb1

me donne au final :

ERROR: errors found in extent allocation tree or chunk allocation
[3/7] checking free space cache
cache and super generation don't match, space cache will be invalidated
_
_ERROR: errors found in fs roots
found 7979657719808 bytes used, error(s) found
total csum bytes: 7775052220
total tree bytes: 8508260352
total fs tree bytes: 179781632
total extent tree bytes: 425984
btree space waste bytes: 462126238
file data blocks allocated: 8019437592576
referenced 8019437592576

Hélas déja essayé : mount: /mnt/A-Archives: wrong fs type, bad option, bad superblock on /dev/sdb1, missing codepage or helper program, or other error.

je suis d'accords,c'est abusé si c'est ça
et ça explique pourquoi dans les précédents cas j'arrivais à corriger, parce que mon disque n'était pas aussi plein.

c'est quoi une PF virtualisée? c'est une VM non ? j'ai VMWare Workstation si c'est ça je pourrais en monter une.