Bonjour à tous,
 
 
Windows 7 peut-il directement écrire sur un lecteur de RAID 0 déconstruit ?
 
 
Contexte de départ :
- un lecteur C: correspondant à un Windows 7 installé sur un SSD
- un lecteur D: DD de stockage
- un lecteur E: correspondant à un RAID 0 de 2 DD
- un fichier d'échange unique et les variables systèmes (windows temp, user temp) configurés sur le lecteur E (le raid, donc)
 
 
J'ai trop précipitamment mis le bios de ma carte mère à jour (en fait je n'ai changé que le logo... mais sans percuter que c'est tout le bios qui allait être "mis à jour" !), en oubliant totalement que ça briserait mon RAID (la première fois j'avais bien pensé à le débrancher)...
 
 
Le problème étant qu'après le reboot j'ai remarqué le RAID brisé (statut FAILED, avec l'un des 2 DD marqué comme non-membre) mais le démarrage s'est tout de même poursuivi jusqu'à l'écran d'accueil (login) de Windows, avant que je l'éteigne.
 
 
Mon but est de reconstruire ce RAID pour restaurer ma config en conservant les données qu'il contient.
 
 
 
La question est donc de savoir si l'un des DD (le toujours membre et le désormais non-membre) du RAID devient le lecteur E et s'il est visible et accessible, ou si comme je l'espère la partition est inaccessible par Windows sous cette forme. ?
 
 
En cas d'accès possible, j'aimerais aussi savoir si Windows 7 utilise, lit, écrit, accède au fichier d'échange et aux temporaires windows avant qu'une session utilisateur ne soit ouverte. ?
 
 
Tout ça pour savoir s'il y a un risque que l'intégrité des données du raid ait été compromise par une écriture sur l'un des DD.
 
 
 
A ce stade, j'ai débranché les DD du RAID, démarré le PC, lancé windows, déplacé le fichier d'échange et les variables environnement sur le lecteur D, puis reboot.
 
 
Maintenant, et bien j'attends des réponses éclairées avant de tenter une reconstruction.
   
 
Merci d'avance, c'est très important.

en remettant simplement RAID dans la bios, ca repart
 

Merci pour la réponse.
 
Mais dans le bios la configuration est toujours en RAID, et durant le démarrage la page du contrôleur RAID Intel indique ARRAY FAILED, ainsi que le second DD de la batterie en tant que Non-Membre.
 
Je pensais simplement recréer le RAID par ce biais (Ctrl+I) mais j'ai peur que des accès précédents au raid empêchent sa bonne reconstruction et une récupération des données...

J'ai bien une méthode de récupération "expérimentale" de données sur un RAID pété (qui fonctionne en lecture, et qui réécrit les données sur un autre disque en accès direct par exemple, après remontage du volume, backup, puis recréation du raid et recopie dans l'autre sens), mais bon le pb c'est que j'ai prévu ça pour linux donc il faut toucher un minimum (cad avoir les bases).
un RAID0 à 2 disques c'est celui qui utilise la procédure la plus simple, par contre il faut connaître le chunk size et l'ordre des disques pour espérer récupérer quelques chose
Parceque le gros pb avec le RAID0, c'est que c'est un niveau qui ne gère pas les rebuild, justement, si tu fais un rebuild ça va te recréer complètement le RAID0 tu risques de tout perdre sans possibilité de récup', après le truc, c'est que je sais pas précisément comment les fake-raid intel gèrent leur init (même si à priori l'init consiste juste à écrire les metadata raid à la fin des disques)

Merci à toi.

D'après ce que j'ai lu, l'effacement et recréation du raid intel (avec effectivement les mêmes paramètres) n'affecte pas les données.
Il y aurait ensuite une dernière étape à faire avec TestDisk pour réécrire la FAT.

ça ce n'est pour l'instant pas le problème. Je cherche déjà à savoir si un DD unRAIDed est reconnu, considéré et affiché comme un lecteur (AHCI) par Windows, avec sa lettre, visible dans l'explorateur et accessible en lecture/écriture, bref si sa partition est "normale". C'est peut-être une question idiote, mais je préfère être sûr. Je ne voudrais pas que windows écrive dessus lorsque je le lancerai pour utiliser testdisk. Ou pire, qu'il l'ait déjà fait suite au premier reboot décrit plus haut.

Le RAID 0 n'a aucune redondance par définition.
Avec un seul disque tu ne peux pas récupérer tes données puisque la moitié des écritures se font sur chaque disque.
Avant de partir dans des manips sans fin, lis simplement :
 
http://fr.wikipedia.org/wiki/RAID_ [...] par_bandes
En particulier les 2 dernières lignes...
 
Ton seul espoir serait que le disque marqué "failed" en rouge dans ton Bios soit reconnu à nouveau.
Les logiciels comme Raid Recontructor ne sont pas efficaces si le statut est failed car il a besoin d'avoir accès aux deux disques.

Merci.
 
En fait, ce n'est pas le disque qui est FAILED mais le ARRAY. Le disque secondaire a été pour ainsi dire exclu du RAID, il est donc marqué "Non-Member".
 
En effaçant le ARRAY et en le remontant avec des paramètres strictement identiques au précédent, il devrait être à nouveau lisible sans perte de données.
 
Bon, je n'ai pas de réponse claire. Je ne suis pas certain de la réponse à ma question mais j'en déduis qu'aucune donnée n'est inscriptible sur les DD membres et non-membres d'un RAID en cas de ARRAY FAILED...
 
J'espère que c'est une bonne déduction, sinon...

Je te suis, mais ne comprends pas qu'à la suite d'un upgrade Bios un disque ait sauté (ok si RAID BIOS pas activé), mais une fois le RAID Bios activé et un reboot tu aurais dû retrouver ton array intact.
 
Si tu as construit ton RAID avec les options par defaut, tu dois avoir un stripe de 128Ko et le disque en rouge retrouver sa place, sauf si la piste zéro / Fat a été modifiée par un logiciel, cad Windows qui voit un disque avec des erreurs et fait au boot un checkDisk ..
Si c'est le cas , c'est foutu. Sinon il aurait du rentrer dans l'array.

Ah merci, enfin une réponse pertinente !

Je dirais que si la FAT a été modifiée, les données n'ont pas été touchées et sont toujours à leur place. La reconstruction du raid suivi de TestDisk, pour faire ce que je comprends comme une réécriture de la fat du raid paramétré, devrait ne pas être perturbé par la fat modifiée par windows.

Me trompe-je ?

Ce qui poserait tout de même l'autre question qui me taraude : Avec la fat réécrite par windows, a-t-il du coup accès au DD et surtout, au point de la page d'ouverture de session windows (puisque j'ai reboot à ce niveau) peut-il avoir écrit des données dans le fichier d'échange (mémoire virtuelle) ou les temporaires ? Ou bien la mémoire virtuelle et les temporaires ne sont-ils utilisés par windows qu'une fois la session ouverte ?

C'est là ma principale interrogation, qui m'a amené à poster ici avant de tenter la reconstruction

Bonjour,
 
 
avec un raid 0 windows ne vois que la capacité des 2 dd. Pour la fat, c'est de l'epoque des anciennes partitions fat16, 32, apres il y a eu le ntfs. Il est sans doute question de la MFT

Il faut oublier la "reconstruction" avec un Raid 0.
Si tu as bien lu l'article de Wiki , tes données -Par secteurs du strip size - sont placées par moitié sur chaque disque. Donc le disque A ne sait pas ce qui a été écrit sur le disque B et inversement.
La FAT est commune aux deux disques quelle soit NTFS ou FAT32 ou autre, donc aussi divisée entre les 2.
Si elle a été touchée sur un disque unique, il n'y a pas de sauvegarde comme sur un disque simple. La MFT évoquée par Jean Pierre est elle aussi divisée par le strip size.

C'est la raison pour laquelle le RAID 0 ne s'utilise que pour faire du traitement plus rapide mais avec une sécurité Zéro.

Maintenant, si ton disque non membre ne veut pas rentrer dans la grappe tu peux t'amuser avec les logiciels genre Raid reconstructor ou autres. Mais n'espère pas un miracle.

Pour info:
http://forum.hardware.fr/hfr/Hardw [...] 3930_1.htm

Merci

Bon dans l'interface Intel (Ctrl+I) j'ai fait un "Reset Disks to non-RAID" puis un "Create RAID volume" avec les mêmes paramètres. La grappe est maintenant au statut "Normal", et "Bootable: Yes".

Sous Windows, le lecteur n'est pas reconnu dans l'explorateur. Une bonne chose si cela veut dire que Windows n'a pas pu y accéder lorsqu'il était "Failed".

J'aurais préféré que tout soit directement comme avant, mais l'étape TestDisk semble incontournable pour cela.

Prie...

EDIT:

- Déjà, le lecteur est reconnu par testdisk (v6.14 win64) et la capacité est conforme (1863GiB soit 2x 931.5GiB). Un bon début...

EDIT:

- Toutes mes données sont lisibles ! Par sécurité je suis en train de les récupérer avant de tenter une réécriture de la MFT.

A toute fin utile, je détaillerai les manipulations effectuées.