[RAID0] HDDs niet detecteerbaar in BIOS na stroomuitval

[sl1200]

Toen mijn PC (specs zie signature) nog een e-mail aan het verzenden was, drukte ik per ongeluk de schakelaar van mijn kastvoeding uit. PC viel uiteraard uit. Was me een keer eerder gebeurd, maar ik kon toen meteen probleemloos weer opstarten.

Nu echter, start mijn PC wel op, maar mijn 2 HDDs in RAID 0 worden niet gedetecteerd in BIOS! Paniek in de tent, want een gedeelte van de (wat nieuwer aangemaakte) data die erop staat wil ik niet kwijtraken. Ik heb daar namelijk nog geen back-up van gemaakt.

Ik heb meerdere malen de PC proberen op te starten, ook een keer met 24h pauze ertussen, maar ik krijg alleen de POST en boot-error message. HDD-lampje brandt continu, meteen vanaf het aanzetten van de PC, maar de schijven worden niet gedetecteerd.

Wat is hier aan de hand???

Aangezien ik nu een RAID 0 array op die schijven heb staan, welke van de onderstaande handelingen kan ik ondernemen ZONDER mijn data kwijt te raken:

1. De aansluitingen van SATA-kabels vervangen; dus HDD1 is nu op moederbord-aansluiting 1 aangesloten en HDD2 op 2, maar ik wil de kabel van HDD1 nu in aansluiting 2 steken en die van HDD2 in aansluitng 1 op de moederbord
2. jumper voor RAID 0 tijdelijk op Normal(?) zetten, dus geen RAID 0, maar een andere configuratie
3. HDDs zijn nu op de oranje Asus EZ RAID controller aangesloten. Kan ik de HDDs nu op mijn JMicron SATA-controller aansluiten in RAID 0?
4. 1 HDD ontkoppelen en laten detecteren?
5. iets met HDD jumpers doen?

Ik heb uit de FAQ begrepen dat je dezelfde RAID 0 config moet gebruiken om je data te kunnen benaderen.

Is een RAID 0 config op een andere SATA controller anders? Of raak ik mijn data niet kwijt zolang ik maar niets op die HDDs bijschrijf?

Ik heb ook Seagate gebeld maar die willen hooguit mijn HDDs RMA ontvangen en/of hun data-recovery service tegen vergoeding aan de slag laten gaan.

[TERW_DAN]

1. Je kunt je S-ATA kabels gewoon vervangen, of op een andere poort zetten. Je RAIDcontroller houdt wel bij welke disk waar in een array hoort. (Of hij geeft aan dat ze verkeerd zijn aangesloten).

2. RAID0 jumper? Wat bedoel je hiermee?

3. Nee, niet zonder dataloss
4. Nee, niet zonder dataloss
5. S-ATA drives hebben geen jumpers die hier verandering in kunnen brengen, hooguit een compatibility jumper.

Je kunt proberen de hdds aan een zelfde raid controller te hangen en daar de array te laten detecteren, de vraag is of dat lukt, omdat je huidige controller het ook niet snapt.

Weet je zeker dat de disks nog goed zijn? Als 1 van die dingen niet opspint, of gewoonweg defect is dan kun je het schudden en ben je je data kwijt.

[sl1200]

2. Met een RAID jumper bedoel ik de jumper op de moederbord naast de bewuste SATA-controller waarmee je kunt aangeven of je in RAID modus wilt draaien of 2 hdds los.

Jumpertje: op de modernere moederborden hoef je zelfs slechts een jumpertje te omzetten om de RAID controller om te zetten in een normale IDE controller. Zie de handleiding van het moederbord voor meer details.

3. Toch wel vreemd dat je stellig zegt "Nee, niet zonder dataloss" terwijl ik gisterenavond op GoT posts tegenkwam van mensen die hun RAID 0 opstelling ZONDER dataloss hebben kunnen migreren van 1 controller naar een andere verschillende controller. Ze zeggen wel dat ze na migratie de RAID array opnieuw moeten aanmaken en dat ze de mededeling krijgen dat daarbij alle data verloren gaat, maar desondanks alle data er nog was.
Wat wel soms problemen gaf, is dat de nieuwe controller geintegreerd was op het moederbord, waardoor Windows moeite had om te starten of om correct te draaien, maar dat had meer met oude drivers te maken die nog op de HDDs stonden.

[ Voor 12% gewijzigd door sl1200 op 01-02-2008 15:46 ]

[THE_FIREFOX]

Is je bios ook gereset na de stroomuitval ?

[TERW_DAN]

sl1200 schreef op vrijdag 01 februari 2008 @ 15:05:
2. Met een RAID jumper bedoel ik de jumper op de moederbord naast de bewuste SATA-controller waarmee je kunt aangeven of je in RAID modus wilt draaien of 2 hdds los.

Ah, op die manier. De meeste mobos doen het tegenwoordig gewoon via de bios namelijk.

3. Toch wel vreemd dat je stellig zegt "Nee, niet zonder dataloss" terwijl ik gisterenavond op GoT posts tegenkwam van mensen die hun RAID 0 opstelling ZONDER dataloss hebben kunnen migreren van 1 controller naar een andere verschillende controller. Ze zeggen wel dat ze na migratie de RAID array opnieuw moeten aanmaken en dat ze de mededeling krijgen dat daarbij alle data verloren gaat, maar desondanks alle data er nog was.
Wat wel soms problemen gaf, is dat de nieuwe controller geintegreerd was op het moederbord, waardoor Windows moeite had om te starten of om correct te draaien, maar dat had meer met oude drivers te maken die nog op de HDDs stonden.

Ik zou uitgaan van wat hier staat: RAID FAQ
dus als je het vaneen controller naar een andere zet, (ander merk) dan gaat het niet werken.

[sl1200]

THE_FIREFOX schreef op vrijdag 01 februari 2008 @ 15:10:
Is je bios ook gereset na de stroomuitval ?

Wat bedoel je hiermee? Ik run momenteel de meest recente versie van BIOS (v2406) voor mijn Asus P5W-DH en heb na de "stroomuitval" geen problemen met BIOS gehad. De eerste opstart na de stroomuitval is goed gegaan. Ik heb wel op een gegeven moment een andere SATA controller in BIOS op Enabled gezet (waar overigens geen HDDs op zijn aangesloten) waarna ik na de gebruikelijke POST een mededeling over JMicron controller kreeg. Tot een paar restarts aan toe kon ik tijdens de POST met op Del te drukken niet mijn BIOS in komen terwijl er wel "Entering BIOS setup..." in de POST werd vermeld. Na een paar restarts lukte het ineens wel. Vond ik wel vreemd.

Stel je voor dat ik mijn mobo opnieuw flash? Want dan krijg ik een foutmelding dat er al dezelfde versie op staat. Probeer ik een oudere versie dan weigert die ook.

[ Voor 13% gewijzigd door sl1200 op 01-02-2008 15:39 ]

[sl1200]

Terw_Dan schreef op vrijdag 01 februari 2008 @ 15:14:
[...]
Ah, op die manier. De meeste mobos doen het tegenwoordig gewoon via de bios namelijk.


[...]

Ik zou uitgaan van wat hier staat: RAID FAQ
dus als je het vaneen controller naar een andere zet, (ander merk) dan gaat het niet werken.

Dat laatste is dan jammer zeg! Want waar ik een beetje op hoopte is dat ik een andere geintegreerde controller van mijn Asus P5W-DH kon proberen zonder dataloss. Er bevinden zich namelijk iets van 3 SATA controllers op dat plankje. Maar wel verschillende merk (EZ Asus vs. JMicron en nog een derde)

[THE_FIREFOX]

sl1200 schreef op vrijdag 01 februari 2008 @ 15:35:
[...]

Wat bedoel je hiermee? Ik run momenteel de meest recente versie van BIOS (v2406) voor mijn Asus P5W-DH en heb na de "stroomuitval" geen problemen met BIOS gehad. Ik heb wel op een gegeven moment een andere SATA controller in BIOS op Enabled gezet (waar overigens geen HDDs op zijn aangesloten) waarna ik na de gebruikelijke POST een JMicron controller kreeg. Tot een paar restarts aan toe kon ik tijdens de POST met op Del te drukken niet mijn BIOS in komen terwijl er wel "Entering BIOS setup..." in de POST werd vermeld. Na een paar restarts lukte het ineens wel. Vond ik wel vreemd.

Of je bios checksum corrupt was en daardoor gereset is. Oftewel alles in de bios staat weer op default.

[sl1200]

THE_FIREFOX schreef op vrijdag 01 februari 2008 @ 15:38:
[...]

Of je bios checksum corrupt was en daardoor gereset is. Oftewel alles in de bios staat weer op default.

Ach zo, nee, er stonden nog wat oude instellingen in de BIOS. Het enige wat veranderd was, was het ontbreken van mijn HDDs op de "Fourth Primary IDE Master"

[TERW_DAN]

sl1200 schreef op vrijdag 01 februari 2008 @ 15:37:
[...]

Dat laatste is dan jammer zeg! Want waar ik een beetje op hoopte is dat ik een andere geintegreerde controller van mijn Asus P5W-DH kon proberen zonder dataloss. Er bevinden zich namelijk iets van 3 SATA controllers op dat plankje. Maar wel verschillende merk (EZ Asus vs. JMicron en nog een derde)

Nope, dat gaat zeker niet. Je kunt een ander mobo proberen met die raid controller (al vraag ik me af of Asus een eigen raid controller heeft ontwikkeld, of gewoon een ding gerelabeld heeft).

[sl1200]

UPDATE:

Vanavond ben ik verder met diagnosticeren gegaan en heb het volgende uitgeprobeerd/onderzocht:

• Na de crash brandde HDD LED continu vanaf het opstarten. Ik heb beide SATA-kabels ontkoppeld en PC aangezet, maar HDD LED bleef wederom continu branden. DIt was voorheen niet het geval, wat dus duidt op hoogstwsl. kapotte SATA-controller.
• Beide SATA kabels ontkoppeld en tevens de molex van 1 HDD. De andere molex liet ik in HDD 2 zitten en startte PC op met HDD 2 in mijn hand tegen mijn oor. Zo heb ik beide HDDs op geluid geinspecteerd en ze blijken allebei netjes op te spinnen en geen rare (tikkende) geluiden te maken. Wederom een aanwijzing dat het om een kapotte controller gaat.
• Met ontkoppelde HDDs de jumpers van dez controller veranderd van RAID 0 naar RAID 1 en dan opgestart (als een soort trigger voor de controller om wakker te worden). Ook nu bleef HDD LED continu branden. Daarna de jumpers weer teruggezet naar RAID 0 en mijn HDDs aangesloten. Maar nog steeds geen leven in de tent. HDD LED blijft wederom continu branden.
• BIOS opnieuw geflashed naar de (huidige) nieuwste versie. Mocht deze enigszins corrupt zijn geraakt, dan nu een verse flash. Echter, probleem blijft bestaan.

Om zeker te zijn dat het mijn controller is, zou ik een 3e SATA HDD los moeten aansluiten op de controller en kijken of die het doet. Zo niet, dan is het 100% duidelijk. Ik heb helaas geen 3e SATA HDD in huis. Ik zal er binnenkort sowieso 1 bestellen als back-up HDD om dit soort taferelen in de toekomst te voorkomen.

Controller is geintegreerd op mijn mobo en daar zit 2jr garantie op, dus het lijkt mij een gevalletje RMA. Nietwaar?

Als ik eenmaal een nieuwe identieke mobo in huis heb, zouden mijn HDDs het als vanouds moeten doen.

[TERW_DAN]

Met ontkoppelde HDDs de jumpers van dez controller veranderd van RAID 0 naar RAID 1 en dan opgestart (als een soort trigger voor de controller om wakker te worden). Ook nu bleef HDD LED continu branden. Daarna de jumpers weer teruggezet naar RAID 0 en mijn HDDs aangesloten. Maar nog steeds geen leven in de tent. HDD LED blijft wederom continu branden.

Heb je hier ook een nieuwe array gemaakt? Als je dat namelijk gedaan hebt dan kun je er nu 100% zeker van zijn dat je je data kwijt bent. Als ik jou was zou ik niet meer gaan klooien met die disks door ze van array te gaan veranderen, wil je je data nog terug kunnen vinden.
Bestel dan liever een los S-ATA diskje zoals je zelf al aangeeft (voor zo'n 30 euro heb je al een disk van een paar GB, zeker voor testdoeleinden is deze aanschaf wel te rechtvaardigen lijkt me).

[sl1200]

Terw_Dan schreef op zaterdag 02 februari 2008 @ 00:16:
[...]

Heb je hier ook een nieuwe array gemaakt? Als je dat namelijk gedaan hebt dan kun je er nu 100% zeker van zijn dat je je data kwijt bent.

Ik heb wel een nieuwe array geprobeerd (middels jumpers op mobo), maar met mijn HDDs ontkoppeld van de controller!
Daarna de array teruggezet naar RAID 0 (jumpers terug op oude plek), HDDs aangesloten, PC opgestart en gekeken of er leven in de tent was. Dat was toch niet gevaarlijk? Maar je hebt gelijk, meer risico moet ik niet nemen. Laatste test wordt dus een 3e SATA HDD erop proberen, alleen ik vraag me of ik die uberhaupt herkend kan worden in zijn eentje. De jumper settings bieden een keuze uit 3 mogelijkheden:

1. RAID 1
2. RAID 0
3. BIG (2 HDDs worden samengevoegd tot 1 zonder RAID 0 features)

[sl1200]

UPDATE:

Inmiddels is mijn mobo RMA omgeruild voor een identiek exemplaar (weliswaar met een nieuwere BIOS versie). Ik heb mijn 2 HDDs precies aangesloten zoals dat voorheen op het defecte moederbord het geval was. Toen PC voor het eerst opgestart en meteen de BIOS ingedoken.

Tot mijn grote vreugde zag ik eindelijk mijn 2 HDDs als 1 grote HDD aangegeven HDDs werden dus netjes als RAID 0 array gedetecteerd zoals voorheen dat altijd het geval was.
Dit was het bewijs dat het oorspronkelijke probleem kwam door een kapotte sata controller op mijn defecte mobo en niet door defecte HDDs. Tot zover leuk!

Vervolgens heb ik geprobeerd te booten vanaf deze RAID 0 array, maar ditmaal tot mijn grote spijt zag ik een foutmelding: "Missing operating system" Ai ai ai!!! De kapotte sata controller van mijn vorige mobo heeft blijkbaar toch de array verpest, ook al heb ik na het ontstaan van het defect niets meer met mijn HDDs gedaan

Daarna wat diagnostics gerund vanuit Windows Ultimate Boot CD en XP recovery console (chkdsk, mbrwizard e.d.) ChkDsk resultaat: er bevinden zich onherstelbare fouten op het volume. MBRwizard kon de oude MBR wel detecteren (gelukkig was er toch iets van de oude meuk te vinden ) en in deze MBR stond aangegeven dat ik 3 partities op mijn RAID 0 array had draaien (klopt!) en de groottes ervan klopten ook. Mooi, maar om het boot-probleem op te lossen, durfde ik echter geen fixmbr commando uit te voeren (volgens instructies van OM FAQ) want ik ben bang dat ik mijn RAID 0 array helemaal verknal door uberhaupt iets op die schijven weg te schrijven! Of zie ik dat verkeerd?

Volgende stap die ik deed was: extra aangeschafte HDD in mijn kast gehangen op de Intel ICH7R controller (een andere controller dan die waarop RAID 0 draait. Extra HDD is trouwens een Samsung Spinpoint 750GB 7200rpm 32MB; errrg lekkere HDDtje overigens: snel, stil en niet warm ) Ik heb op die Samsung schijf XP geinstalleerd en geprobeerd mijn RAID 0 array daarvandaan te benaderen. In Verkenner zie ik de 3 partities staan, maar erop klikken levert een foutmelding op:"het volume is niet geformateerd. Nu formateren?" Ze zien er dus leeg uit. In Schijfbeheer zie ik de partities ook staan (als NTFS) er verder geen bijzonderheden (vroegere opstart-partitie is nog steeds Active, maar ik kan niet ervan booten).

Nu ben ik met een paar data recovery tooltjes, die ik in XP op mijn aparte Samsung HDD draai, aan het proberen om de data terug te krijgen van de RAID 0 array. R-Studio scan leverde niks op (heleboel onzin files) en nu ben ik GetDataBack for NTFS aan het runnen. Binnen dit pakket zit ook een RAID reconstructor tool bij (via OM FAQ gevonden). In dat programma moet ik de 2 losse HDDs aanwijzen die voorheen deel uitmaakten van de broken RAID 0 array, alleen deze 2 HDDs worden door die tool als 1 schijf gezien, want ik draai ze momenteel in RAID 0. Ik durf niet om mijn 2 HDDs uit de RAID 0 array te halen en in de Normale modus te laten draaien om met deze tool de RAID 0 array te reconstrueren. Wat moet ik doen?

[Verwijderd]

Dit programma zou kunnen helpen als de partitietabellen op je RAID0 niet helemaal lekker zijn: http://www.cgsecurity.org/wiki/TestDisk_Download

De Silicon Image chip (EZ-Raid) kan ook gebruikt worden om maar 1 schijf op aan te sluiten. De drie SATA poorten vlak daar boven zijn volgens mij van de ICH7R, en de eSata en de poort vlak bij je CPU van de Jmicron chip. Een van de IDE poorten is van de Jmicron en een van de ICH7R. Kijk in de manual als je meer zekerheid wilt over de verschillende RAID mogelijkheden.

In de ICH7R RAID manager (CTRL-I) tijdes opstarten, kun je ook een RAID-array aanmaken tussen een schijf op de EZ-Raid en de ICH7R. Kijk dus heel goed uit welke schijf je waarop hebt zitten, ik heb zo al bijna 300GB gewist (had gelukkig backup).

[sl1200]

TheMajor, bedankt voor je tip! Ik zal dat tooltje deze week proberen. De indeling van controllers op mijn Asus P5W DH heb je goed beschreven, hoor. En ik had (en heb nu ook weer) mijn 2 RAID0 HDDs dus op die Silicon Image EZ_RAID controller aangesloten. Mijn nieuwe Samsung HDD (3e schijf) heb ik nu op de rode SATA-poort van de Intel ICH7R aangesloten.

Gisterennacht was het scannen van mijn RAID0 array door GetDataBack for NTFS tool dan eindelijk klaar. In tegenstelling tot R-Studio progje, zag ik nu wel mijn bestanden terug. De namen van de directories en files waren correct en hun groottes ook (ook al weet ik ze niet tot op de byte nauwkeurig natuurlijk). Echter, de recoverde bestanden die ik op mijn 3e HDD eerst had weggeschreven, zijn corrupt. Tekstfiles bevatten alleen maar vreemde tekens, foto's kunnen niet geopend worden, etc.

Kortom, ik ben inmiddels weer een stap dichterbij, maar nog niet helemaal. Aangezien de mappen en bestandsnamen wel correct te traceren zijn, beteknt dit dat ik mijn RAID 0 array dus eigenlijk niet kwijt ben geraakt, maar dat er alleen de FAT-indeling o.i.d. corrupt is?

[Verwijderd]

sl1200 schreef op woensdag 27 februari 2008 @ 13:39:

Kortom, ik ben inmiddels weer een stap dichterbij, maar nog niet helemaal. Aangezien de mappen en bestandsnamen wel correct te traceren zijn, beteknt dit dat ik mijn RAID 0 array dus eigenlijk niet kwijt ben geraakt, maar dat er alleen de FAT-indeling o.i.d. corrupt is?

Ik denk eerder andersom. Je FAT/MFT lijkt in orde, maar de bestanden zijn niet of moeilijk te herstellen.

[sl1200]

Broken array dus...

Ik heb Testdisk geprobeerd:
- in MBR worden de afzonderlijke partities gezien
- na een volledige scan is er echter geen 1 partitie te vinden (=raar, want met GetDataBack kon dat wel)
Met PhotoRec (hoort bij Testdisk) een recovery gedaan van de partities (deze tool kon de partities ook wel vinden), maar bijna alle gerecoverde bestanden waren corrupt.

Ik heb ook met Knoppix 5.1.1 CD2007 geprobeerd te booten en van daaruit de partities te benaderen, maar die kunnen niet worden gelezen.

Momenteel denk ik aan de volgende stap (volgens OM FAQ):
Met RAID Reconstructor is een .vim file aan te maken die de layout van de ooit werkzame array beschrijft. Deze file kan worden ingelezen in GetDataBack om vervolgens een recovery te doen vanaf de array waarbij de bestanden niet corrupt worden gerecoverd.

1 probleem: ik weet niet wat de gegevens zijn van de RAID0 array die de Silicon Image 4723 SATA controller standaard aanmaakt wanneer je de jumper op mijn Asus P5W DH Deluxe mobo op RAID0 zet. -> ik ga Google-en

EDIT:
Na wat ge-Google kwam ik erachter dat ik toch mijn 2 HDDs uit de RAID0 array moet halen en aansluiten in bijv. RAID1 moet zetten zodat ze als aparte HDDs worden gedetecteerd. Dan pas kan ik met de RAID Reconstructor en GetDataBack een recovery van een broken array doen.
Ik ben echter bang dat er hierbij data verloren zal gaan of denken jullie dat de volgende stappen probleemloos kunnen verlopen:
- zet de jumper van RAID0 op RAID1
- boot vanaf een 3e HDD met XP erop
- maak een RAID array file aan mbv. RAID reconstructor op basis van de 2 HDDs die nu apart worden gezien
- doe een scan van de 2 HDDs met de RAID0 array gegevens aangemaakt in RAID reconstructor
- recover de bestanden die nu hopelijk niet meer corrupt zijn.

Tijdens al deze stappen zal er (als het goed is) geen data worden weggeschreven op 1 van de 2 HDDs die voorheen in RAID0 zich bevonden.

[ Voor 33% gewijzigd door sl1200 op 02-03-2008 00:02 ]

[Verwijderd]

Niet in RAID1 zetten. RAID1 maakt van de twee schijven een exacte kopie. Als je een RAID1 array aanmaakt ben je of alles kwijt, of je hebt nog maar de inhoud van 1 van de schijven, maar dan dubbel. Ik denk dat bedoelt wordt de schijven ieder apart in je PC te hangen. Doe maar eentje op de JMicron, en de ander op de ICH7R, dan kun je niet per ongeluk een RAID aanmaken.

[ThaHandy]

met R-Studio heb ik mijn raid 10 (raid 0) kunnen recontructueren dmv een virtual raid array te maken (ook doordat er plotseling de spanning er af ging )

maar je bent wel ff zoet met de juiste stripe size en blok indeling te zoeken én de disks in de juiste volgoorde staan

mijn silicon image had een stripe van 32 (default gelukkig ) en een "stripe-block-indeling row count" van 2 ( disk-A 1, disk-B 2)

[ Voor 34% gewijzigd door ThaHandy op 05-03-2008 10:05 ]

[sl1200]

Bedankt voor de tips, daar kan ik zeker mee spelen

Wat ik gedaan heb:

1. toen mijn HDDs nog op de Silicon Image controller in RAID0 waren aangesloten: image van array op mijn 3e HDD gemaakt (byte by byte method of backup), mocht ik in de onderstaande stappen nog iets meer verklooien dan heb ik tenminste nog deze backup
2. vervolgens HDDs losgekoppeld van de Silicon Image controller en beide aangesloten op Intel ICH7R controller (JMicron kon ook, maar het maakt hier verder niets uit)
3. in XP werd 1 HDD netjes herkend in Deze Computer (zie hieronder)
   
   
   
   
   
   Maar mijn 2e HDD niet (zie hieronder)
   
   
   
   
   
   Desalnittemin kon ik in R-Studio en GetDataBack beide schijven selecteren om testjes mee te doen.
4. Vervolgens ging ik spelen met de RAID Reconstructor, omdat dit tooltje automatisch zoekt naar de beste instellingen voor de broken RAID array om deze te herstellen en het dus niet nodig is om deze instellingen handmatig in te voeren.
   
   Ik selecteerde hierboven mijn 2 HDDs en drukte op Analyze om de onderstaande settings automatisch te testen:
   
   
   
   Helaas, ik kreeg steeds het onderstaande resultaat:
   
   
   
   En dat houdt het onderstaande in:
   
   
5. Ik wilde om die reden niet verder gaan met de RAID Reconstructor, maar met R-Studio: (overigens, ik zie bij HDD1 een C partitie en ook nog Partition 1 en Partition 2. De groottes kloppen niet!...hmmmm)
   
   Nou betreft mijn vraag het onderstaande onderdeel:
   
   Wat zijn allemaal variabelen waarmee ik kan spelen???
   • volgorde van HDDs (rechtsboven aan te geven)
   • block size (ThaHandy had dus 32 kb in zijn geval)
   • row count (bovenstaand plaatje laat 2 rows zien, dus 4 blokken (links aangegeven met 1, 2, 3 en 4), maar ik kan deze dus veranderen naar bijv. 1 row count waarna ik alleen getallen 1 en 2 links zie.).
   • block order (Als ik op die grote getallen links dubbelklik, kunnen ze veranderen van volgorde; dus nu staat van links naar rechts: 1,2,3 en 4, maar je kunt dus ook kiezen voor bijv. 2,1,4 en 3.)
   • nog iets meer??? (offset in seconden: rechtsboven naast de HDD lijst, etc.)

Ik heb een willekeurige set aan variabelen geprobeerd voor de virtual stripe set en daarna een data recovery gedaan van die scan. Ik was toch wel blij te zien dat ik bijv. (delen) van foto's kon herstellen De vraag is dus of het nut heeft om heel veel tijd in te steken in het maken van heleboel langdurige scans van al die mogelijke virtual stripe sets om erachter te komen welke nou eigenlijk de juiste is??? Tot zover zijn namelijk alle pogingen van mij net niet geweest, zeg maar. Daarlijk ben ik misschien onnodig dagen bezig met scannen terwijl het toch gedoemd is te mislukken.

Hebben jullie daarom enige suggesties voordat ik morgen met een grote serie scans begin???

[Verwijderd]

Zorg dat je niet naar je schijf schrijft, kale schijven opstarten in windows zou ik zelf absoluut niet doen. Wellicht dat de journaling al voor veel schade (corruptie) heeft gezorgd.

Bij striping RAID is van belang: disk volgordge, offset, metadata sector inhoud en exacte locatie. Als je hulp met recovery wilt, raad ik je aan dit eens te lezen.

[ Voor 15% gewijzigd door Verwijderd op 05-03-2008 04:03 ]

[ThaHandy]

btw: met stripe-block-indeling bedoelde ik dus row count = 1 (het is al een tijde geleden nl )

Ik had ongeveer 5 scans (~30Min/scan, 74GB raptors) nodig voordat ik de juiste instellingen had en een goeie scan had. (check log)
Daarna had een juiste "enties" (2 groene, 2 partities) en ik zag mijn directory structuur weer.

De scan testen door een groot plaatje te recoveren en zien of i opent zonder artifacts.

mijn recovery was 99.9%. dus het kan wel!!

suc6

/edit
volgens je mobo handleiding pag. 5-62 default stripe size = 64

nu is het de kwestie van juiste volgoorde en de rowcount

[ Voor 50% gewijzigd door ThaHandy op 05-03-2008 10:07 ]

[Verwijderd]

Gefeliciteerd met je recovery! 99.9 zeg je, dus sommige bestanden waren wel gecorrupteerd?

[sl1200]

ThaHandy schreef op woensdag 05 maart 2008 @ 09:45:
btw: met stripe-block-indeling bedoelde ik dus row count = 1 (het is al een tijde geleden nl )

Ik had ongeveer 5 scans (~30Min/scan, 74GB raptors) nodig voordat ik de juiste instellingen had en een goeie scan had. (check log)
Daarna had een juiste "enties" (2 groene, 2 partities) en ik zag mijn directory structuur weer.

De scan testen door een groot plaatje te recoveren en zien of i opent zonder artifacts.

mijn recovery was 99.9%. dus het kan wel!!

suc6

/edit
volgens je mobo handleiding pag. 5-62 default stripe size = 64

nu is het de kwestie van juiste volgoorde en de rowcount

Dat is de default stripe size van de ICH7R controller, maar het hoeft niet dezelfde te zijn van de Silicon Image waarop mijn HDDs eerst in RAID0 waren aangesloten.

Ik heb gisterenavond 4,5h lang een scan gedraaid van die 640GB grote RAID0 array en toen na afloop R-Studio de bestanden wilde "opbouwen" zodat ik ze kan bekijken, liep het programma vast. En dat is me al veel vaker gebeurd.

@Enlightenment bedankt voor je link; die bewaar ik als mijn laatste redmiddel