Essaye un testdisk sur /dev/md0 en root, il arrivera peut être à rattraper la chose… Sinon il faut retrouver le superblock, je vais manger et je reviens
ok, je vais le telecharger et l’installer
je ne serai pas dispo de la soiree, je ferai les operations demain.
Pour avoir les endroits où sont les superblocs, fais
mkfs.ext3 -n /dev/md0
(pense au -n sinon il te reformatte le bazar!)
J’ai lance un testdisk. Il en est a 25%
J’avoue ne pas trop saisir les informations qu’il me donne.
Je posterai demain les resultats du testdisk et lancerai la commande pour les superblock
Le testdisk est terminé, mais les messages semblent pas trés rassurants … :
TestDisk 6.10, Data Recovery Utility, July 2008
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/md0 - 3000 GB / 2794 GiB - CHS 732569952 2 4
The harddisk (3000 GB / 2794 GiB) seems too small! (< 10701072 TB / 9732568 TiB)
Check the harddisk size: HD jumpers settings, BIOS detection...
The following partitions can't be recovered:
Partition Start End Size in sectors
Linux 32 0 1 799678847 1 4 6397430528
HFS 325747 0 1 2001282610 0 4 14724503928139260
HFS 1561879 1 1 2264230642 1 4 15910260592914140
HFS 5842627 0 1 151019018 1 4 3883811846720
HFS 6861686 1 1 346924397 0 3 6533506971176887
HFS 10517702 0 1 2825576672 0 2 1349707403305170
HFS 18232561 1 1 1776447459 0 2 10369439507797902
HFS 19828814 0 1 1778043711 1 2 10369439507797902
HFS 22391675 1 1 2929753914 0 4 4694834830286328
HFS 23628385 1 1 2334364609 1 2 20900531939068674
[ Continue ]
EXT4 Large file Sparse superblock Recover, 3275 GB / 3050 GiB
L’ecran suivant est :
Christophe GRENIER <grenier@cgsecurity.org>
http://www.cgsecurity.org
Disk /dev/md0 - 3000 GB / 2794 GiB - CHS 732569952 2 4
Partition Start End Size in sectors
L HFS 46414434 1 1 52493419 1 4 48631884 [D]
L HFS 62779457 1 1 153339740 1 4 724482268 [ zd ^C <6~[~M^C ^A z~H ^D`^C
L HFS 195662753 1 1 507907954 1 4 2497961612 [~X :~N?~\"O>^V#αP hF^A z~H
^D`^C]
Structure: Ok. Use Up/Down Arrow keys to select partition.
Use Left/Right Arrow keys to CHANGE partition characteristics:
*=Primary bootable P=Primary L=Logical E=Extended D=Deleted
Keys A: add partition, L: load backup, T: change type,
Enter: to continue
HFS, 1278 GB / 1191 GiB
Je dois lancer la commande ‘L’ pour chacune ?
Il y avait quoi initialement? Une seule partition ext4 si j’ai bien compris…
Exact, il y avait qu’une seule partition à la base.
Format ext4 … oui, je pense
Bon tu vas essayer la chose suivante:
mkfs.ext4 -n /dev/md0
Tu vas avoir une sortie immédiate de la forme
[...]
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624
Et là, tu essayes de faire
fsck.ext4 -b 32768 puis si ça ne marche pas, chacun des numéros successifs donnés par la commande. Si ça ne marche pas, je ne vois pas d’autre moyens que foremost ou photorec pour essayer de récupérer qques fichiers…
ok,; donc, je peux couper testdisk ?
(j’ai un message d’erreur comme quoi /dev/md0/ est occupé)
Oui, je pensais qu’il arriverait à récupérer quelque chose mais non. En plus je suis idiot, car testdisk travaille sur des disques entiers.
Voici le résultat du mkfs :
mke2fs 1.41.4 (27-Jan-2009)
Étiquette de système de fichiers=
Type de système d'exploitation : Linux
Taille de bloc=4096 (log=2)
Taille de fragment=4096 (log=2)
183148544 i-noeuds, 732569952 blocs
36628497 blocs (5.00%) réservés pour le super utilisateur
Premier bloc de données=0
Nombre maximum de blocs du système de fichiers=4294967296
22357 groupes de blocs
32768 blocs par groupe, 32768 fragments par groupe
8192 i-noeuds par groupe
Superblocs de secours stockés sur les blocs :
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968,
102400000, 214990848, 512000000, 550731776, 644972544
tiste@tiste-desktop:~$ Puis, je lance un fsck :
tiste@tiste-desktop:~$ sudo fsck.ext4 -b 32768
Usage : fsck.ext4 [-panyrcdfvtDFV] [-b super-bloc] [-B taille-de-bloc]
[-I nombre-blocs-du-tampon-i-noeuds] [-P taille-i-noeud-processus]
[-l|-L fichiers-des-blocs-défectueux] [-C fd] [-j journal-externe]
[-E options-étendues] périphérique
Aide d'urgence :
-p Réparation automatique (sans question)
-n N'appliquer aucun changement au système de fichiers
-y Supposer « oui » pour toutes les questions
-c Vérifier la présence de blocs défectueux et les
ajouter à la liste des blocs défectueux
-f Forcer la vérification même si le système de fichiers
est marqué propre
-v Travailler en mode bavard
-b super-bloc Utiliser un bloc alternatif pour le superbloc
-B taille-de-bloc Forcer la taille des blocs lors de la recherche du
superbloc
-j journal-externe Définir la localisation du journal externe
-l fichier-des-blocs-erronés
Ajouter à la liste des blocs défectueux
-L fichier-des-blocs-erronés
Définir la liste des blocs défectueux
tiste@tiste-desktop:~$
sudo fsck.ext4 -b 32768 /dev/md0
Si ça coince, essaye les numéros suivants…
J’ai testé tous les nombres :
tiste@tiste-desktop:~$ sudo fsck.ext4 -b 644972544 /dev/md0
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: Invalid argument lors de la tentative d'ouverture de /dev/md0
Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
ou alors, mais ca a l’air de revenir au meme :
tiste@tiste-desktop:~$ sudo fsck.ext4 -b 20480000 /dev/md0
e2fsck 1.41.4 (27-Jan-2009)
fsck.ext4: Bad magic number in super-block lors de la tentative d'ouverture de /dev/md0
Le superbloc n'a pu être lu ou ne contient pas un système de fichiers
ext2 correct. Si le périphérique est valide et qu'il contient réellement
un système de fichiers ext2 (et non pas de type swap, ufs ou autre),
alors le superbloc est corrompu, et vous pourriez tenter d'exécuter
e2fsck avec un autre superbloc :
e2fsck -b 8193 <périphérique>
Je refais la meme chose avec e2fsck ?
Non, c’est la même chose, fsck.ext4 n’est qu’un lien vers e2fsck:
$ ls -l /sbin/fsck.ext4
lrwxrwxrwx 1 root root 6 mars 21 2013 /sbin/fsck.ext4 -> e2fsck
francois@portos:~$
Là je commence à ne pas trop savoir quoi te conseiller. Si tu as des fichiers importants, tu peux essayer photorec ou foremost sur /dev/md0 mais c’est l’artillerie lourde, il te faut un disque tiers important et un temps long devant toi…
Dans tous les cas, je te remercie beaucoup de ton aide.
Avant de faire le formost (ca me laisse le temps de vider un disque et d’acquérir un NAS - d’ailleurs, quel est ton avis dessus, comme solution de sauvegarde ? ), je vais regarder sur d’autres forums s’il y a des idées que je viendrai te soumettre. Des fois qu’il y ait d’autres solutions eventuelles …
Une question qui me taraude : qu’est-ce qui aurait ainsi pêté mon RAID ? le defrag sur mon poste Windows (j’y crois pas), l’assemblage et la creation arrêtée en cours de route ? Manque totale de chance ?
[quote=“dionee”]
Une question qui me taraude : qu’est-ce qui aurait ainsi pêté mon RAID ? le defrag sur mon poste Windows (j’y crois pas), l’assemblage et la creation arrêtée en cours de route ? Manque totale de chance ?[/quote]
Je pense la suite d’assemblages/créations avortés
Je veux pas casser l’ambiance…mais gérer un raid via une machine virtuelle ressemble à du grand bricolage de schizophrène à tendance suicidaire 
Il y a beaucoup plus simple comme solutions en plus du raid matériel sur carte mère.
J’utilise FreeNas qui permet un paramétrage aux petits oignons (base BSD)
Quand j’ai un disque du raid qui tombe dès que tu remets un neuf dans le NAS il se reconstruit tout seul.
Je pense qu’on lui a dit plein de fois. Si on ne cherche pas l’efficacité mais juste une redondance et qu’on n’a pas de moyen financier (une seule machine puissante) et qu’on est sous windows, cette solution peut s’imposer. Il est clair que le raid est plus fragile, et je pense que dans ce cas le RAID1 s’impose (disque exploitable seul, cela aurait permis de récupérer les données). Mais dans son cas, je pense qu’il s’en fout. Son problème c’est 3G de données disparus.
Vous avez tous les raisons.
A l’époque, j’avais été échaudé par la perte d’un disque de 1To. Heureusement, pas de pertes, car le disque était pratiquement neuf …
L’idée qu’on m’a alors vendu était de faire ce RAID logiciel, sachant que je ne recherchais pas de la perf, mais de la redondance.
Le RAID logiciel m’avait été préconisé dans la mesure où il offrait plus de sécurité qu’un RAID matériel : si la carte brule, le RAID est perdu. En logiciel, il “suffit” de reconstruire.
Les faits par la suite m’ont montré les limites de cette architecture et j’envisageais meme l’acquisition d’un NAS.
Ce qui s’est passé dernièrement va accéléré ce projet …
J’en profite pour vous demander vos avis sur ce choix. La performance n’est pas un grand enjeu; ce que je veux, c’est de plus perdre mes données, quitte à y mettre le prix.
Connaissez-vous freedatarecovery.us/ ?
L’erreur est juste de te mettre dans la situation où un seul disque ne peut être exploité seul. Après, j’avoue que c’est une question de budget. Un disque en RAID1 est utilisable tout seul.
Le piège dans les RAIDs est que souvent les disques ont le même age, la même histoire et sont du même modèle. Ils accumulent souvent en même temps. Dans un RAID, c’est à mon avis une bonne idée de changer un disque régulièrement.