Petite historique :
 
Au départ, un raid 5 logiciel (4x 1to) dans une box debian (pas de carte : contrôleur de la mobo), partagé par Samba
 
- Après une panne de mobo, je ré-installe mes disques dans une box temporaire un peu ancienne (nforce 2) avec un contrôleur promise PCI
- Le raid semble bien reprendre ses fonctions
- Je m’aperçois que des exécutables win32 stockés sur le raid sont corrompus..
- Quand je copie des données (installs...) dessus  -> corrompues également à la lecture - ça commence à puer..
- Je lance une VM, juste pour voir si elle aussi à des problèmes (ma box me servait également pour ça)
- Un peu plus tard,  le serveur se coupe brutalement
- Au démarrage, il manque un disque à la grappe raid
- Je l'ajoute, re-synchro raid démarre
- Au bout de 15min, je constate que la machine s'est à nouveau éteinte
- Après le démarrage, il manque deux disques au raid...
-> la j’arrête les conneries...
 
J'aimerais bien avoir des conseils sur la marche à suivre une fois que j'aurais monter une box neuve..
-> scans des disques ? (fsck ?)
-> remontage du raid, des trucs spéciaux à faire ?
 
Merci.
 
edit : orthographe + précision de taille

remontage du raid et voir le disque hs?

J'ai oublié une précision de taille : au dernier démarrage, il manquait 2 disque à la grappe...
 
Ajouté dans mon post de base

raid avec 2 hdd en moins = out

les 2 hdd en question sont toujours la, mais pas dans le raid..
 
donc je me dis qu'il y a encore un espoir

essaye une reconstruction du raid et vois celui qui déconne

all right
 
je vais remonter ca sur du matos neuf et on verra

tant que tas encore tes disques et qu'ils sont détectés avec la bonne lettre nickel, tu reconstruits ton raid et dès que ca passe en dégraded tu regarde celui qui est out

avec la bonne lettre ?.. de lecteur ?

/dev/sd* je parlais ^^

tiens, je remet mon MP en copie ici :
 

 
 
Voilà, pour toutes questions concernant la journalisation avec mdadm ou même l'installation sur un raid md (déjà fais sur raid 0, 1, 4, 5, 6, 10 et 10 avec des layout spéciaux), je peux toujours aider  
 
[don't try this at home]
sinon, si vraiment rien ne marche, j'aurais bien une technique de reconstruction de superblock md, c'est TRES bourin et très risqué mais mieux que rien. j'ai bien déjà réussi à transformer des raid0 en raid4 le mois dernier, sans pertes de données, alors que j'avais pété les superblock   (en fait l'astuce réside dans la création d'un raid avec le même strip size et le même layout sur les disques existants, mais création dégradée pour éviter absolument la resynchro (donc pas de modif' des données), qui sera faite ultérieurement), pour réussier à faire ça, il faut absolument connaître 2 paramètres : le layout et le chunk size, info que tu peux récupérer avec un mdadm -E /dev/sdx1 par exemple, si sdx1 est un des éléments du raid, la moindre erreur avec ce genre de manip' et tu perd TOUT.
[/don't try this at home]
 
Si il n'y a que ça, je peux toujours faire un test où je crée un raid, je le blinde de données, je le pète en foirant 2 superblock par exemple, et après j'essaye de sauver les meubles    
 
Dans tous les cas, une fois que tu aura remonté ton raid, il va faloir faire une branlée de fsck par contre  
 
Il faudra quand même que tu me dise comment tu as agencé le montage de ton raid avec debian, j'ai vraiment plus l'habitude de deb' que j'ai pas touché depuis 2008, ayant été très occupé sur des enterprise linux

Merci bcp pour ta réponse
 
En fait, après la mort de ma première carte mère, j'ai testé avec un linux tout neuf dans ma bécane principale.
Le raid s'est remonté direct, sans reconstruction, et j'ai pu monter /dev/md0, donc je me suis dis que c'était ok (ouf surtout!)
 
Par contre,  je n'ai pas testé d'écriture ou de lecture sur le raid ainsi testé (et j'aurais ptet dut)
 
Ensuite, en attendant de racheter du matos 'clean', j'ai tout remonté (avec le disque système d'origine) dans une machine que je gardais au fond d'un placard. Mauvaise idée surement.
 
Le raid est revenu comme avant, et là avec samba, j'ai testé des lecture et des écriture.  
Horreur, car j'ai testé quelques isos et .exe, et un certain nombre sont corrompus.  
Meme chose si je pose un fichier neuf et que je l’exécute après...
 
Mais peut etre la conf de remplacement est en cause (carte mère, ram, que sais-je...)
 
Le pire dans l'histoire c'est que j'ai justement l'alim que tu décris, une corsair 400W, acheté sur conseils de canard pc
 
Ça me ferais mal que mes problèmes viennent de la...
 
Pour la suite, je vais tout remonter dans une config neuve et voir les choses une par une..  
Mais je suis pas sorti de l'auberge je pense...

c'est quoi ta vieille machine de récup', j'ai déjà vu des pb très très bizares se produire aussi avec des chips réseau "bizares" et samba, si jamais à l'install l'installeur à chargé un module compatible mais qu'en fait les spécif' de la puce sont trop différentes (ce qui pourrait expliquer que tu vois des données corrompues qui ne le sont peut-être pas).  

machine de recup :  
athlon xp2800 sur a7n8x (nforce2)
jutilise une 3com 905 car impossible de faire fonctionner les 2 cartes du nforce !!!
 
c'est aussi la question que je me pose.. et c'est pour ce que je vais chopper du matos neuf (alim comprise) pour remonter le raid et le tester dans de bonne conditions...
 
reste a trouver le bon matos à acheter...

Ok
 
config NAS bien et pas chère :
 
mobo : asus M4A78LT-M LE (idéale pour un NAS : 6 SATA et chip video intégrée) <50€
proc : Athon II x2 250 (nickel pour géré un raid soft : pas cher et bien plus costaud qu'un imfâme sempron) Et pour faire tourner quelques petites VM dédiées ce sera suffisant <55€
RAM : de la value corsair ou kingston, tu mets 2 Go (toujours pour les VM) et ça roule <25€
Alim : Une bonne 400W, je suis étonné que ta CX400 déconne, enfin bon y'a p'tet aussi un pb sur ton ancienne mobo (vérifie l'état des condo, peut-être qu'il y en a qui ont le cul qui glonfe), pourtant je me rapelle bien de cette mobo, elle était vraiment pas mal à l'époque. Pour le moment, je te conseille de partir sur du Antec neo eco 400 ou 400C (la 400 est modulaire et la 400C ne l'est pas, c'est la seulle différence, alim parfaite pour un NAS   ) compte ~45€
 
Il faudrait quand même tester ta CX400 (sur une machine de récup' par exemple), elles sont bien ces alim, tu peux même sortir 500W dessus  
 
ça te fait une config (nas+virtu légère) neuve pour environ 175€  

J'ai d'ailleurs posté à ce sujet mais je n'ai pas trouvé mon bonheur..
 
http://forum.hardware.fr/hfr/Hardw [...] 6710_1.htm

edit fait, comme tu peux le constater, tout le monde va te conseiller de l'AMD en socket AM3 pour un nas en ce moment, intel n'ayant rien dans cette tranche de prix actuellement ^^

J'étais un fervent utilisateur AMD y'a un petit moment, et la je sens que je vais avoir du mal à y revenir..
 
Le chipset est bien géré par linux ? (pasque bon le nforce2 c'était la misère)
(j'en-ai-marre-de-galérer-inside)
 
Et comme je compte faire tourner 2 ou 3 VMs (pas trop méchantes mais bon ca consomme un peu de ressources tout de meme) ca te parait suffisant ?
 
edit : et vraiment merci pour tes réponses top !

Au pire (enfin au mieux ) tu mets 4Go de ram et tu ajoute 25€ à la note totale
 
Là pas de soucils actuellement sur les matos récents, après par contre le seul point qui pourait poser pb avec cette mobo est sa carte réseau intégrée, qui utilise des chip réseau plutot récents, tu va surement être obligé d'installer un module tiers pour l'utiliser (t'enmerde pas et installe un kmod-atl1c si je me souvient bien c'est ce qu'il faut pour ce chip réseau là)
 
Je ne te cacherais pas que c'est souvent la carte réseau qui pose pb avec les distro rock-stable qui utilisent un kernel d'origine un peu ancien, comme les debian ou les RHEL et dérivés, 2 solutions : bricoler le kernel et/ou les modules, ou acheter une carte réseau additionnelle (et désactivation par le bios bios du contrôleur intégré) en intel du genre celle là : intel pro1000 CT, PCI-express 1x qui fonctionnera avec un module e1000e supporté depuis très longtemps maintenant et qui sera certainement au dessus du chip intégré en terme de perf', les cartes réseau intel sont chères, mais elles valent leur prix aussi (et la rom pxe doit aussi avoir un impact non-négligeable sur le prix)  
sinon au pire tu peux toujours partir sur du dlink qui est aussi pas mal en carte réseau.
mais un conseil : fuit netgear, leur cartes gigabit ont un comportement très aléatoire  

Ok, merci bcp, je vais potasser tout ca, et je te ferais un retour

La carte n'est pas si cher que ca, 35€ si ca marche nickel
Et puis pour un NAS autant avoir une carte qui tienne la route !

ouais, tu peux foncer sur de la carte réseau intel, j'en ai plein des intel, que ce soit en PCI, en PCI-express, en intégré sur mobo serveur, sur du portable, c'est du tout bon et c'est clairement bien au dessus des chip atheros d'origine de ce genre de petites mobo ou même d'un chip marvell

Bon je crois que je vais opter pour une mobo de ce genre :
http://www.rue-montgallet.com/prix [...] sb3,670531
 
6 sata, 2 e-sata (pratique pour les backup), de l'usb 3
 
par de carte video intégré mais bon j'en ai en stock

Pas de soucils, à priori le chip réseau est supporté, pour l'usb 3.0 je sais pas par contre, tu pourra faire un retour d'expérience ^^

Bon, ca y est, j'ai racheté du matos
(alim seasonic / mobo GA 880GM UDH2 / proc x2 250 / 4go ram gskill)
 
Install debian 6 terminée..
 
Par contre mon raid est un peu en vrac :

 
Je sais pas trop quoi faire (et surtout peur de faire des conneries...)

Voila l'output de mdadm --examine
 

En fait je viens de m'apercevoir que les devices indiqués dans les "mdadm --examine" ne correspondent pas à ce qui est défini sur mon système
 
(mon disque système est présentement détecté en tant que /dev/sda, alors qu'avant c'était hda)
 
bon.. je sais pas trop quoi faire
 
edit :
peut être un "mdadm --create" histoire de repartir avec les bons devices ?

Bon d'après ce que j'ai lu sur ce post http://ubuntuforums.org/archive/in [...] 10136.html, il semble que la solution puisse être d’exécuter "mdadm --create" mais il faut retrouver l'ordre original..
 
A priori on peut réessayer jusqu'a temps que ca marche mais je suis pas super confiant et j'hesite à essayer

ok, j'ai assez d'info pour t'aider, je vais jetter un oeil à tout ça ^^
 
pour l'ordre, pas de panique, ça se retrouve avec le mdadm -E (tout en bas, plan de num des disques, pour ça que moi je fous des étiquettes sur tous mes disques, exemple en image ici) et je constate que tu as effectivement mélangé tous les disques, par contre tu as contruit le raid avec les options par défaut de md (chunk size de 64K et algo 2 : left-symmetric, algo qui décalle les parités vers la gauche et qui écrit les données de façon cyclique)
et ouais, là il va faloir passer par un create, mais le mieux c'est de faire un create en mode dégradé (ça évite une reconstruction des parités, systématiquement mortelle pour les données en cas d'erreur, enfin bon là il y a peu de risques dans la mesure où tu as tout laissé par défaut)
 
Si tu me laisses un peu de temps, je peux faire des test ce soir et demain, j'ai tout ce qu'il faut pour ça
 
ah, comme si ça ne suffidait pas dans le genre casse-tête, l'ordre des disques a une certaine tendance à être chamboullé par la mobo, il faudrait noter le numéro de série de chaque disque et voir dans quel ordre ils sont assignés, parceque des fois il y a des inversions pour raisons historiques
(ordre IDE qui fait PM>SM>PS>SS au lieu de PM>PS>SM>SS et ça impact aussi le plan de num SATA même en mode AHCI) le plus souvent ça donne un branchement sur les ports sata 1>3>2>4>5>6 (par exemple) pour avoir les disque dans l'ordre pour linux, seul moyen de reco les disques, le num de série, que tu peux retrouver avec smartctl -i /dev/sdx ou encore hdparm -i /dev/sdx)
 
Pb qui ne se pose jamais avec le SCSI et le SAS  

En un seul mot : Merci!
 
Je compte par faire n'importe quoi en mode "panique" et je suis venu chercher de l'aide par ici !
 
Je voulais justement tester avec des /dev/loop pour simuler mais je manque clairement d’expérience sur mdadm..
 
Effectivement l’étiquetage des disques c'est une bonne idée, je le ferais maintenant !
 
Donc, je coupe tout et j'attends !

tests en cours, ça va être bourrin à souhait, là je vais dégager les superblock md à la main sur un des disques et en mettre un autre en faulty pour être sûr de poutrer le raid5 et reproduire à peut prêt ton scenarii (mais en pire   )
 
ça reproduit bien ton pb, je sais qu'il y a un de tes disques en retard par rapport aux autres (pas resync), c'est lui qu'il faudra absolument exclure lors d'un remontage dégradé, les autres sont bien à jour par contre.
 
Truc qu'il va faloir que tu m'explique, c'est si tu avais explicitement mis un disque en spare ou pas ? parcequ'à lire, tu avais le dernier disque de ton montage d'origine en spare, ça change complètement la tronche d'un raid 5 ça (mais à priori non tu n'as pas fais de disque de spare vu les détails de capa donc ça ressemble plus à un foirage de superblock)

ah ouai quand même !..
 
(ca fait peur inside)

t'inquiètes, à priori ça semble récupérable ^^
l'état du fs m'inquiète bien plus que le raid, il va faloir faire cracher fsck après ça je sens

Je pensais pas en etre a ce stade!
 
(C'est fou comme certaines actions ont des conséquences flippantes!)

En fait, dans l'ordonnancement des disques, tu as un #0 removed et un  #4 en spare, on peut donc déjà partir du principe que c'était le premier disque de la grappe, et qu'il y a eu foirage et passage en spare.
 
Tu verra que le plus gros du travail consistera à remettre tes disques dans le bon ordre. Trouver l'ordre absolu de disques est en soit une chose simple, la vraie difficulté, tu verra, ce sera de s'arranger pour vérifier que la mobo les détecte bien dans l'ordre que tu pense (bien souvent il y a des inversions quand on pense avoir tout branché dans l'ordre) 90% du temps l'inversion à lieu entre les ports SATA 2 et 3, mais il faut être sûr de cher sûr avant de commencer à trifouiller les superblock md  
 
ou sinon, la soluce sale (mais qui marche à coup sûr) de les remettre dans l'ordre logique sans toucher quoique ce soit sur la machine (impossible de se gourer), en reconstruisant avec les disques dans un ordre désordonné justement (mais le bon   ), au moins faire ça le temps de récup' les données ailleurs (genre 1 ou 2 gros disques externes), tout péter, tout remettre dans l'ordre et reconstruire un raid propre et ordonné  
 
 
 

Je vois a peu près
 
Bon par contre je n'est pas explicitement mis des disques en spare, ca c'est fait tout seul suite aux 2 crashs..

manip' terminée, accès aux données OK, md5 des fichiers OK, notes que j'avais aussi mélangé les disques et trouvé le moyen de les remettre dans l'ordre.
J'ai eu une petite erreur au fsck (c'était un fs ext3 écrit directement dans md0), mais rien de bien méchant. Par sécurité, il vaut mieux faire une première exec de fsck sans modif' du fs (au cas où ça tourne mal)
 
une fois que j'ai  fait repartir la grappe en mode dégradé et remonté le système de fichier, j'ai fait sauté le superblock d'origine du dernier disque et réintégré illico dans le raid pour relancer la resync

Hello !
 
Il va falloir que tu m'expliques ta proc
Je vais essayer de t'expliquer tout ce que j'ai fait (j’espère que ça sera pas trop confus)
 
J'ai relancé la machine avec mon ancien disque système (celui qui était sur la conf d'origine avec la mobo qui a cramé) avec un disque raid en moins pour éviter une re-sync automatique :
Les disques SATA sont nommés en commençant par sda : Il ne sont donc pas décalés.
 
Alors que ma nouvelle install (debian 6 - qui a surtout pour but de voir si je peux récupérer mon raid) le disque PATA système est sda et donc mon raid commence à sdb
 
J'ai aussi relevé les numéros de série de disque pour comprendre l'ordre de nommage attribué sous debian :
Sur mes deux installs, les nommage des devices suivent la logique des numéros de port SATA de la mobo, à la différence donc que :
- sous debian 5, les disques SATA et PATA sont respectivement sd* et hd* (donc 1er disque raid = sda)
- sous debian 6, les disques SATA et PATA sont tous en sd* (1er disque raid = sdb)
 
- Crois tu que sur ma debian 5 mon raid pourrait être remonté plus facilement ?
- Comment se fait-il que remonter le raid est si complexe quand les devices sont décalés ? Ca oblige a ré-écrire les superblock et donc de passer par un mdadm --create c'est cela ?
- Crois-tu que l'ordre des disques compte vraiment ? (Lors des tests  sur ma machine principale et sur le matériel de remplacement je n'y ai pas fait attention et pourtant le raid est reparti "comme ca".. Ou alors coup de bol !)
 
Merci de ton aide
 
-> J'ai bien déconné de prendre du matériel pas fiable pour voir si mes données étaient toujours là.  
C'est ça qui a causé les devices spare et faulty dans le raid (2 extinctions violentes dont une pendant un resync)
 
edit:
Je crois que j'ai compris le plan des devices de mdadm : effectivement c'est le bazar sous debian 6 :
sdb1 devrait être sdd1
sdc1 devrait être sda1
sdd1 devrait être sdb1
sde1 devrait être sdc1
 
Si on met en forme le plan des superblock ca donne ca

 
sdd1 (device sdb1) est ok pour lui même, removed pour les autres
sda1 (device sdc1) est spare pour tous
sdb1 (device sdd1) est ok pour tous
sdc1 (device sde1) est ok pour tous
 
Donc deux devices ok (sdb1 et sdc1)
sda1 en spare (comprends pas pkoi)
sdb1 removed (pareil)
Un device perdu (id 0) ?
 
oulalala galère

Bon je pense que je vais continuer sous deb 6.
Tant qu'a faire c'est pas plus mal de repartir avec un système récent.
 
Je vais acheter un nvo disque sata pour le système.
D'ici la je vais partir avec mon celui que j'ai sous deb6..

C'est pas un pb le nommage des disques.
 
Par contre l'ordre est ULTRA important vu qu'on va réécrire de façon arbitraire les superblock, la moindre erreur dans l'ordo et tu perds TOUT, d'où mon insistance sur ce point. Tout l'algo de distribution des parités et des données repose sur l'ordre. En temps normal, les disques ont une num inerne, ce qui ne pose pas de pb. Là on est dans le cas où on indique arbitrairement la numérotation des disques, donc l'ordre est primordial et surtout il faut le gérer manuellement tant que tes disques n'auront pas un nouveau jeu de superblock.
 
Les 4 grosses info pour remonté un raid cassé :
 
-Le type de raid bien sûr
-L'ordre des disques (inversion = foutu), on va le retrouver t'inquiète pas pour ça, j'ai déjà reconstitué les pièces du puzzle avec les infos que tu m'a filé.
-Le chunk size (mauvaise taille = foutu), info déjà connue : 64K
-l'algo de distribution des parités et données (2 méthodes de distribution des parités, 2 méthodes de distribution des données, ça fait 4 combinaisons en tout, mauvais algo = foutu), info déjà connue : left-symmetric
 
La sortie de ton mdadm --examine n'est pas complète,il manque le plus important : la ligne "this" qui est le point de repère pour chaque disque (et oui vu que les noms peuvent changer (d'ailleurs c'est le cas là), je me base pour l'ordre uniquement sur la numérotation absolue dans le raid et jamais sur le nom  du fichier de block du disque).
 
La 2eme info la plus importante, c'est la ligne "event" qui permet de savoir dans quel ordre les disques ont été sortis du raid, ce qui permet donc d'éjecter d'office le premier disque à avoir foiré chronologiquement, ce qui permet d'être tranquile lors de la reformation du raid. Comme tu as 3 disques sur 4 avec un event à 126, même pas peur    
 
Le seul truc que je ne pige pas dans l'ordre : tu as changé les disques de chassis ? Ou juste rebranchés en vrac ?  
 
 
parceque sinon la soluce la plus simple c'est encore de se contenter de faire un ordonancement logique sans se préoccuper du matos, mais il me faut une sortie mdadm -E complète de tous les disques pour ça, tu en as déjà posté une mais je ne sais pas si tu as apporté des modif' dans tes branchements de disques.
 
 
J'ai fait des cassages de raid très sale ce WE, vraiment TRES sales, à chaud, avec de l'écriture en court et des erreurs d' I/O en prime, j'ai tout remonté, et ça marche, j'ai réussi à chaque tenta, bon le système de fichier à été bien poutré par moment mais fsck à réussi à le rafistoler à chaque fois