Bonsoir,
Apres avoir pu generer une table imparfaite, j'ai pu recuperer un fichier
ou j'avais sauvegarde les tables de partition.
Apres cela a ete simple de tout reconstituter (a l'exception de partitions
ntfs de tete qui necessitent un chkdsk).
Tout est rentre dans l'ordre presque sans degat.
Comme un nouvel incident c'est reproduit sur les disques, j'ai du checher
plus a fond.
Finalement, l'origine du probleme semble etre dans l'une des alimentations
5V qui ne delivre que 4.6 V (il y a 2 alim 5V dans le boitier d'alim) :
5V et 5VSB, quelle est la difference ?
Une fois tous les disques passes sur l'alimentation delivrant 5.1 V tout
semble fonctionne correctement.
Conclusion, il devrait y avoir des alertes sur les niveaux des alimentations.
En fait, je pense que mon probleme n'est pas nouveau. Il y a 2 ans j'avais
change un disque, j'ai du le renvoyer car il ne fonctionnait pas correctement,
et il est revenu avec le meme probleme. J'avais change de port d'alim
sans verifier les tensions, et le probleme avait ete resolu au moins
pendant 2 ans pour ce disque la.
Que dois-je mettre dans le fstab ?
/dev/mapper/VolGrpUsr2-home /home ext4 errors=remount-ro 1 2
?
===========================================================================
Patrick DUPRÉ | | email: pdupre@???
Laboratoire de Physico-Chimie de l'Atmosphère | |
Université du Littoral-Côte d'Opale | |
Tel. (33)-(0)3 28 23 76 12 | | Fax: 03 28 65 82 44
189A, avenue Maurice Schumann | | 59140 Dunkerque, France
===========================================================================
> Sent: Monday, July 17, 2017 at 10:50 PM
> From: "Yves Martin" <ymartin59@???>
> To: guilde@???
> Subject: Re: disques!!
>
> Bonsoir,
>
> Dans ce cas, photorec n'est pas pertinent pour "tout récupérer"... ce
> serait vraiment la solution de la dernière chance pour tenter de
> retrouver des fichiers importants.
>
> Si tu as produit un backup des tables de partition sur un disque, il
> serait possible d'utiliser photorec en choisissant "text file" et de
> faire un grep pour retrouver la sortie de fdisk ou sfdisk... À tenter.
>
> Sinon testdisk propose une table de partitions en fonction des
> informations spécifiques des systèmes de fichiers (magic header), mais
> ce n'est pas parfait, notamment par le fait que les superblocks sont
> dupliqués.
>
> Donc effectivement, l'idéal est de faire une copie avec "ddrescue" sur
> un nouveau support et de faire les expérimentations de table de
> partition avec des mount read-only.
>
> Attention: les disques SSD s'évaporent très rapidement (en tout cas
> celui que j'ai eu en main)... plus je lisais, plus j'obtiennais de
> l'aléatoire... au premier doute, la réaction est de tout stopper,
> acheter un nouveau support et faire un dd.
>
> Au passage, je suis très déçu qu'un support SSD ne se bloque pas en
> read-only à la première erreur d'allocation de bloc dans la table de
> redirection de l'espace addressé - probablement des économies de bouts
> de chandelles dans l'implémentation...
>
>
> Et dans la fstab de Linux, ne jamais oublier les options essentielles:
> "errors=remount-ro", ou "panic" à choix, sur tous les montages.
>
> Au moindre pépin, on est prévenu un peu brutalement mais mieux vaut
> cela que des heures de fsck ou de reconstruction... Au boulot, on a un
> SAN vieillissant avec impacts terrifiants sur VMware, "errors=remount-
> ro" m'a sauvé la vie plus d'une fois.
>
>
> Bon courage,
> N'hésites pas à informer de ta progression
> Yves
>
>
> On Fri, 2017-07-14 at 15:20 +0200, ALD wrote:
> > Je ne suis pas tres fort avec le maniement des partitions, je ne peux
> > pas me
> > risquer à te donner des conseils sur ce qu'il faut écrire comme
> > nouvelle
> > partition.
> >
> > Sinon, avec "testdisk", il doit également y avoir" photorec" qui
> > permet de
> > retrouver les fichiers perdus. Il lis les données et tente de
> > reconstituer et
> > reconnaitre les fichier et le type de fichier. J'ai aussi pu en
> > recuperer
> > comme ça.
> >
>
>
