Hulp gezocht: 2 schijven in raid0 messed up

[Renault]

Wel ontopic: ik heb hier zelf geen ervaring mee.
Maar zo mee lezende meen ik dat je onder Linux de meeste kans hebt op het correct detecteren van je RAID-vorm. Wellicht eens eenLinux Mint versie (die draai je vanaf USB-stick of CD) naar die schijven laten kijken?

[Varkzor]

Ben nu bezig met de stellar proefversie op aanraden van Boermansjo.
Linux mint nog niet getest, wel Ubuntu, helaas in ubuntu toont hij meerdere schijven, zonder logisch gevolg. Toont ook de main 2 drives als "group" ipv stripe. Is mij niet duidelijk waarom.
In de bios toont hij dat de raid ok is met blocks van 128 bits.

[jvanhambelgium]

Alternatief is eventueel software gebruiken :

> RAID0 recovery van disk-internals, wel duur. Met de "free licent" kan je alvast de RAID0 terug assembleren en de bestanden bekijken die gevonden zijn. Voor het RECOVEREN... $$$ (240 USD)

http://www.diskinternals.com/raid-recovery/


> Goedkoper is deze (68 USD) of

https://www.easeus.com/datarecoverywizard/buynow.htm

https://www.r-studio.com/data_recovery_linux/


Dus ... als je er met Linux niet helemaal uitkomen, is dit mischien een betaalbaar alternatief in functie van hoe belangrijk die data is.

[Varkzor]

Stellar laat niks gratis recovery toe, dacht online 1GB te zien, maar enige dat hij doet is online sturen, offline werkt het niet.
Nu paar andere tools aan't draaien.
wel al wat "previews" gezien van foto's, maar de recovery is zeeeeer mager, mss 1% van de foto's die hij recovert...

Beetje met de handen in het haar, vraag mij nog steeds af of er geen re-intiate van de stripe & block definition mogelijk is zonder echt de data te verliezen, zolang de blocks gelijk blijven dunkt mij nog steeds dat dit zou moeten werken (op zijn minst om daarna meer successvolle recovery te kunnen doen)?

Als er nog mensen zijn met ervaring, alle input welkom!

[Mijzelf]

Het eerste antwoord op deze vraag suggereert dat een JMicron hardware raid zijn header aan het einde van de schijf zet.
Als dat zo is dan begint de payload dus netjes aan het begin. Met mdadm --build (en dus niet --create of --assemble) kun je verschillende block sizes proberen.

[Thralas]

Varkzor schreef op zondag 13 september 2020 @ 13:04:
Nu paar andere tools aan't draaien.
wel al wat "previews" gezien van foto's, maar de recovery is zeeeeer mager, mss 1% van de foto's die hij recovert...

Dan gaat er evident wat fout. Je moet ook niet de fout maken om generieke 'data recovery' tools te gebruiken, je probleem is RAID striping, iedere tool die dat niet snapt is bij voorbaat waardeloos.

Het gesuggereerde Stellar RAID recovery kan het zo te zien prima, maar dat kost €199, lijkt me geen optie.

Beetje met de handen in het haar, vraag mij nog steeds af of er geen re-intiate van de stripe & block definition mogelijk is zonder echt de data te verliezen, zolang de blocks gelijk blijven dunkt mij nog steeds dat dit zou moeten werken (op zijn minst om daarna meer successvolle recovery te kunnen doen)?

Volgens mij ben je dan het verkeerde probleem aan het oplossen. Je zegt dat je BIOS de RAID gewoon herkent; je probleem is dat je OS er geen raad mee weet. Fakeraid heeft OS support (een driver) nodig om de RAID metadata te interpreteren en de schijf als één te interpreteren. Voor Windows lijkt me dat die er gewoon is?

Linux ondersteunt volgens mij niet zoveel fakeraid metadata (alleen Intel Matrix RAID/VROC), maar dat hoeft geen probleem te zijn: RAID 0 is supersimpel, dus je kunt de array gewoon handmatig proberen te assembleren zoals @Mijzelf voortstelt. Informatie uit je BIOS over de array is daarvoor nuttig. Je hebt het over '128 bits': ik vermoed dat je 128 kB bedoelt - dit zal de chunk size zijn. Enige wat je dan niet weet is de volgorde, maar gelukkig zijn er maar twee mogelijkheden.

Doe wat @Mijzelf zegt - met als hint dat je chunk size waarschijnlijk 128kB is. Als je er zeker van wilt zijn dat je de data op de disks niet perongeluk wijzigt terwijl je met mdadm aan het klooien bent: maak eerst even twee loop devices aan.

Zoek je disks met:

blkid

Dan tweemaal:

losetup -Prf <disk>

Nogmaals blkid (of losetup -a) geeft twee readonly /dev/loop* devices die je daarna kunt gebruiken met mdadm of wat dan ook.

---

Trouwens, FreeBSD ondersteunt zo te zien JMicron RAID out of the box: md_jmicron.c. Weet alleen niet hoe BSD met NTFS is.

[Varkzor]

Windows toont indeed de drive, maar vraagt om format.

[Varkzor]

Foto via progs tonen dit -soms nog minder

[Varkzor]

Ben eerlijk gezegd minder savvy in linux ubuntu. Wat is mdadm en kan ik dat vanop usb bootable draaien (dit leek niet te lukken gisteren). Lukt dit enkel bij full install van ubuntu?

[Varkzor]

[Varkzor]

[Varkzor]

[Mijzelf]

Varkzor schreef op zondag 13 september 2020 @ 17:00:
Foto via progs tonen dit -soms nog minder[Afbeelding]

Als het progamma niets van raid0 weet kan dat. Het heeft de header van een plaatje gevonden, maar het plaatje is groter dan 128kB, en past dus niet in een chunk. Het word dan aangevuld met random data uit de volgende chunk, omdat het programma niet weet dat hij data van de andere schijf moet invoegen.

Varkzor schreef op zondag 13 september 2020 @ 17:01:
Ben eerlijk gezegd minder savvy in linux ubuntu. Wat is mdadm en kan ik dat vanop usb bootable draaien (dit leek niet te lukken gisteren). Lukt dit enkel bij full install van ubuntu?

mdadm is een command line tool om raid arrays te managen. (creeren, assembleren, members toevoegen/verwijderen, ...). Het zou prima moeten draaien van een usb stick, maar misschien moet je het nog installeren

sudo apt update
sudo apt install mdadm

Na een reboot is het weer weg, omdat Live Linux het op een ramdrive installeert.

[Varkzor]

en sudo kan ik gewoon draaien in de command van Ubuntu? Ik heb dat gisteren geprobeerd maar ging precies niet. Ik probeer nog even en probeer een screen te sturen.

Alvast allemaal super bedankt voor de hulp en de moeite en alle input van iedereen. Heb gezien dat er nog fotos zijn van onze hond vroeger en die wil ik graag wel terug.

Grtz

[Varkzor]

[Varkzor]

Losetup permission denied helaas

[Varkzor]

Loops gelukt denk ik. Vanuit root ging het. Maar nu. Stel dat ik iets messed up doe met mdadm what then?

[Varkzor]

Weet niet helemaal wat te doen nu om te rebuilden of wat te doen als het mislukt. Kan iemand een voorbeeld mdadm --build command geven?
Als het resultaat niet klopt. What then?

[Varkzor]

Voorbeeld gevonden enige vraag die blijft is: die --level=0 doet dat iets?

Sudo Mdadm --build /dev/md0 --chunk=128 --level=0 --raid-devices=2 /dev/sda /dev/sdb

Sudo mount -t ntfs-3g /dev/md0 /media/raid

Zoiets? En kan iemand wat verduidelijken of dit OK is?

[Mijzelf]

Varkzor schreef op zondag 13 september 2020 @ 18:44:
Loops gelukt denk ik. Vanuit root ging het. Maar nu. Stel dat ik iets messed up doe met mdadm what then? [Afbeelding]

Zoals @Thralas schreef is de loopdevice read-only. Dus zolang je mdadm alleen op de loop devices gebruikt, en niet op de 'rauwe' disks, kan er niets mis gaan. Er kan niets geschreven worden naar de loopdevices.

Als sudo niet werkt, kun je de commando's intypen in een root prompt. Dat is (bijna) hetzelfde.

Jij lijkt nu twee loopdevices te hebben, /dev/loop6 en /dev/loop7 die naar je twee array members wijzen. /dev/loop6 lijkt een partitie tabel te bevatten, dus dat is waarschijnlijk member 0.

Het commando om dit te assembleren zou kunnen zijn:

mdadm --build /dev/md0 --chunk=128 --level=0 --raid-devices=2 /dev/loop6 /dev/loop7

Hierna zou je blkid mogelijk een /dev/md0p1 (de eerste partitie op de array) kunnen zien, die gemount kan worden.

[Mijzelf]

Varkzor schreef op zondag 13 september 2020 @ 18:58:
Voorbeeld gevonden enige vraag die blijft is: die --level=0 doet dat iets?

Sudo Mdadm --build /dev/md0 --chunk=128 --level=0 --raid-devices=2 /dev/sda /dev/sdb

Sudo mount -t ntfs-3g /dev/md0 /media/raid

Zoiets? En kan iemand wat verduidelijken of dit OK is?

--level=0 doet zeker iets. Het definieert raid0. En Linux is case-sensitive, dus zowel sudo als mdadm moet met kleine letters.

Overigens kun je beter sda en sdb niet direct gebruiken, zoals boven uitgelegd.

[aawe mwan]

Onder welk OS heb je destijds de schijf op RAID ingericht: was dat met Windows of met Linux?

JMicron chips hebben de reputatie dat ze niet altijd zo goed werken onder Linux, vandaar de vraag.

[Varkzor]

Yep fixed en lijkt ook te werken. Ik zie nu /dev/mdp01 partuuid="...."

[Varkzor]

Destijds opgezet met windows

[Varkzor]

[Varkzor]

Failed to mount.. invalid argument dev md0..

[Varkzor]

Moet md0p1 zijn?

[Varkzor]

Md0p1 werkt ook niet.
-t en ntfs-3g argument incorrect?

[Varkzor]

@Mijzelf Any idea? Jij lijkt dit allemaal goed te kennen :-)

[Varkzor]

"ntfs signature is missing".?
<staring out in front of me - like a nublar> :-)

[Mijzelf]

Varkzor schreef op zondag 13 september 2020 @ 19:07:
Md0p1 werkt ook niet.
-t en ntfs-3g argument incorrect?

/dev/md0p1 bedoel je? Wat is het commando, en wat is de foutmelding?

[Varkzor]

@Mijzelf in de foto hierboven zie je het command & de foutmelding.

[Mijzelf]

Ik zie alleen de foutmelding op het mounten van /dev/md0, niet /dev/md0p1. Mis ik iets?

[Varkzor]

met md0p1 proberen mounten is het net hetzelfde.
Ik probeer nog eens en neem foto.

[Varkzor]

[Ben(V)]

Je kunt wel met mdadm aan de slag gaan maar dat draait niet onder Windows dus die raidset van jouw kan oorspronkelijk nooit met mdadm gemaakt zijn.
En je kun niet zomaar een raidset die met iets anders gemaakt is even fixen met mdadm onder linux.

[Varkzor]

Zowel met type ntfs en ntfs-3g zelfde melding

[Varkzor]

@Ben(V) Dus enige oplossing ligt in Windows? Maar raid herbouwen in windows. Zonder formatteren/data verliezen. Kan dat?
Ik weet ook nietmeer zekee of ik 1 of 2 partities op die raid had

[Mijzelf]

Hm. Met

cat /proc/partitions

kun je de block device zien. Zijn /dev/loop6 en ..7 even groot als /dev/sda en /dev/sdb? Is /dev/md0 dubbel zo groot?

Het zou natuurlijk kunnen dat de chunksize van 128kB niet klopt. Je zou een andere kunnen proberen.

mdadm --stop /dev/md0
mdadm --build /dev/md0 ...

@Ben(V) Fixen kan inderdaad niet. Maar mounten en data veiligstellen wel.

[Ben(V)]

Ik betwijfel of dat lukt.
mdadm maakt een heel ander structuur dan Windows raid dus ik vrees dat die er niets van zal snappen.

Ik zou eerst maar eens in Windows kijken bij disk management wat Windows ziet.

[Ben(V)]

Misschien heb je hier wat aan:
http://www.freeraidrecovery.com/library/raid0-recovery.aspx

[Varkzor]

[Varkzor]

@Ben(V) thanks - kan straks eens herstarten en proberen in windows met die tool die je refereert. Enige ervaring mee of hij freeware is?

[Mijzelf]

/dev/md0 heeft de juiste maat, maar /dev/md0p1 lijkt me veel te klein. Je zou even naar de partitie tabel kunnen kijken

fdisk -p /dev/md0

[Varkzor]

[Varkzor]

Klopt inderdaad iets niet. Gezien die partitie maar 465G is

[Mijzelf]

Het zou natuurlijk kunnen dat een van jouw tooltjes de partititie tabel 'gerepareerd' heeft op basis van een enkele disk?

In dat geval zou een extra loopdevice kunnen helpen.

sudo losetup -fo 1048576 /dev/md0

Dat maakt een loopdevice op /dev/md0, op 2048 * 512 bytes vanaf het begin. Die begint dus op dezelfde plek als de partitie, maar is niet ingekort. Daarna kun je proberen de nieuwe loopdevice te mounten. Dat zal wel /dev/loop8 zijn.

[Varkzor]

Als je de terminal sluit is die md0 weg? Zie em nietmeer staan. Command gedaan maar heeft geen loop8 aangemaakt

[Varkzor]

Wel nog md0p1

[Varkzor]

Mogelijks toch gelukt. Nu nog proberen mounten

[Varkzor]

Helaas mount lukt niet van loop8 of 9

[Varkzor]

[Varkzor]

[Thralas]

Zeg, zo te zien heb je helemaal geen JMicron RAID, maar gewoon een-of-ander Intel-formaat (isw_raid_member). Zou al helemaal moeten werken onder Windows.

Sterker nog, Linux pikt hem ook op gezien de /dev/mapper/isw_hdicdcbgf_Volume0. Dat is blijkbaar met dmraid ipv. md (omdat het oud is?). /dev/mapper/isw_hdicdcbgf_Volume0 zou gewoon je RAID volume moeten zijn, maar het zorgelijke is dat het geen valide NTFS lijkt.

Wat laat dmraid -r zien?

Waarom bevat een van de disks een partitietabel van 465 GB? Heb je in Windows perongeluk op format gedrukt? In combinatie met de RAID volume die wel gedetecteerd lijkt is dat vrij zorgelijk: als je een van de disks perongeluk opnieuw geformatteerd hebt met NTFS dan is het een verloren zaak.

[Varkzor]

ik ben vrij zeker dat ik niet geformateerd heb.
Ik heb wel de intel controller software vandaag in windows geinstalleerd die bij het mobo komt.

Bij opstart in de bios staat er JMICRON controller. ik heb een oude Maximus Gene II mobo.

Als 1 van de 2 drives formatted is dan zou dat enkel kunnen door de mbr te proberen herschrijven. heb nooit geformat absoluut never.
Wat wel nog kan. maar gezien de leeftijd ontgaat het mij, is dat ik dat bvb ooit in 100gb en 900gb heb opgesplitst. Maar dat is meer dan 10 jaar geleden dus herinner het mij echt nietmeer helaas.

[Varkzor]

dus die 465 GB zou bvb nog kunnen dat er ergens ooit iets van 930GB en +- 70 GB heeft bestaan. Maar like said herinner me dat voor geen meter.

[Varkzor]

van de specs van geneII: Extra SATA (RAID) controller JMicron JMB363

[Varkzor]

Ben nu aan het kijken met ReclaiMe maar moet fan de drives unmounten van de raid. Dat laatste kan ik verzekeren dat nooit gebeurd is. Heb die alleszins nooit via bios gereinitialiseerd

[Varkzor]

Vraag me dan wel af als ik dat doe. Of dat niet nog meer miserie teweeg brengt en of ik bvb een disk iso kan maken om op die basis reclaime te draaien? Maar heb daar dus ook weer geen ervaring mee helaas.

[Thralas]

Varkzor schreef op zondag 13 september 2020 @ 23:34:
Als 1 van de 2 drives formatted is dan zou dat enkel kunnen door de mbr te proberen herschrijven. heb nooit geformat absoluut never.

Dan ben ik wel benieuwd hoe groot het ntfs filesystem is wat je op /dev/md0p1 hebt staan.

ntfsinfo -m /dev/md0p1

Post ook nog even de output van dmraid -r.

[Gman]

Varkzor schreef op zondag 13 september 2020 @ 23:34:
Bij opstart in de bios staat er JMICRON controller. ik heb een oude Maximus Gene II mobo.

PATA (RAID) controller: JMicron JMB363
Bron

Maar ff over een andere boeg, als ik deze foto zie:


Dan is er zeker nog wel hoop hoor! je raid werkt. Pas als er een disk echt stuk is houdt het op.
In de andere screenshots zie je dat de disk NTFS geformatteerd is, dus onder windows aangemaakt.
Ik zou stoppen met linux en de volgende methoden onder windows proberen:

Je kan proberen om de MBR te fixen:
https://neosmart.net/wiki/fix-mbr/#Fix_the_MBR_in_Windows_7

of https://www.online-tech-t...b-drive-ipod-and-sd-card/
Dat gaat over USB disks maar werkt hetzelfde, methode 1, 3 5 en 6 zijn bruikbaar.

Als je er écht niet uitkomt dan kan je altijd nog (methode 6) een quick format doen, dat is eng want dan lijkt alles weg, maar er is nog niks overschreven, enkel de index is opnieuw aangemaakt. De data staat nog op de disks en die kan je eruit trekken met een recovery tool. Dat moet je dus wel onder windows doen.
Maar dat is echt de last resort!

[Varkzor]

Ik ga morgen verder moeten kijken. Ben aant zien in windows of ik daar iets zou knn aanvangen met een eerdere suggestie van ReclaiMe. Maar dan moet ik de raid uitzetten. Tenzij ik mss de drives via usb controllers aansluit als ik al ben opgestart. Dan moet ik aan mn bios niet komen en kan ik makkelijk terug via sata aansluiten zonder veel gevaar aan instellingswijzigingen. Ik kom er morgen op terug Thralas. Bedankt ook om mee te helpen. Is nu de 5de dag dat ik ermee bezig ben. Of beter gezegd ermee aan het zweten ben.

[Gman]

raid niet uitzetten, die werkt nog, enkel je partitie is niet lekker.

[Varkzor]

@Gman thanks voor de input! Ik probeer morgen verder. Disks zijn zeker niet stuk hardcore RE2 drives van WD :-) Is echt puur ergens een config issue of reinit issue dunkt mij.
Aller slechtste geval is er toch 1 van de 2 formatted..... maar los hiervan ben ik 100%zeker dat dat nooit een deep format was. Ik herinner zelfs geen format. Enkel dat ba heraansluiten de drives nietmeer werkten en windows niet opstartte en ik ook nit kon recoveren of herinstalleren.
Maar is lang geleden. Dus niet 100%zeker dat ik toen geen fout heb gemaakt.

[Thralas]

Gman schreef op maandag 14 september 2020 @ 00:01:
Als je er écht niet uitkomt dan kan je altijd nog (methode 6) een quick format doen, dat is eng want dan lijkt alles weg, maar er is nog niks overschreven, enkel de index is opnieuw aangemaakt.

Dat moet je nooit doen. Helemaal als je probleem (hopelijk) een RAID-puzzel is.

Last resort of niet: het wordt er niet beter van. Het helpt ook niets met recoverytools die files proberen te carven: die geven altijd beroerd resultaat.

Wat overigens ook nog zou kunnen ten aanzien van de 465GB-partitietabel is dat je de schijven simpelweg in de verkeerde volgorde hebt geassembleerd, en dat je daardoor de oude (originele) partitietabel van de tweede disk te zien krijgt (die wordt immers niet zomaar overschreven als hij op +128 kB begint binnen de array).

Ik zou je aanraden om de stappen van mij en @Mijzelf nog eens te doorlopen, met de array ook in omgekeerde volgorde en de output van de genoemde commando's. Allerlei andere tools (die meestal niet gratis zijn) lijken me minder productief.

[ Voor 12% gewijzigd door Thralas op 14-09-2020 00:23 ]

[Varkzor]

[Varkzor]

Disk toont wel RAW niet NTFS

[Varkzor]

Heb even de volgorde vab raid 7 en 6 omgedraaid in de create en krikg het volgende

[Varkzor]

[Varkzor]

[Varkzor]

Maar vind geen drives in file manager

[Varkzor]

[Koenoe]

Misschien dat chkdsk commando's onder Windows nog het eea kunnen fixen. Maar dat zou ik eerst even checken bij de echte kenners.

[DataGhost]

Kan je eens iets doen als (evt loop6 en loop7 aanpassen naar wat het hoort te zijn)

dd if=/dev/loop6 of=/home/ubuntu/begin6.bin bs=10M count=1
dd if=/dev/loop7 of=/home/ubuntu/begin7.bin bs=10M count=1
chown ubuntu /home/ubuntu/begin[67].bin

en beide bestanden ergens uploaden? Ik gok, zoals Thralas al zegt, dat je waarschijnlijk toch een van de schijven hebt geformatteerd want die partitie toevallig even groot als slechts één van de schijven is toch behoorlijk verdacht in een RAID0-set. Aangezien je zelf duidelijk de kennis niet hebt om dit in je eentje te herstellen (is niet erg, maar nu niet echt bepaald handig) lijkt het me handiger als ik of iemand anders hier met kennis van zaken op de een of andere manier naar die twee bestanden kan kijken (de eerste 10 MB van elke disk) of er überhaupt iets te redden valt.

@hierboven: chkdsk kan je lekker laten varen, die kan hier helemaal niks mee. Pas op het moment dat Windows uberhaupt een schijf ziet die 'ie niet direct wil formatteren kan chkdsk er iets mee, maar dat zou ik in een scenario als dit zeker niet doen. Je wilt op geen enkele manier iets naar de disks schrijven voordat je alle data hebt veiliggesteld.

Edit: Waarschijnlijk geeft dit al behoorlijk wat nuttige info:

fdisk -l /dev/loop[67]

dus "min kleine L", maar een minnetje, geen twee

[ Voor 5% gewijzigd door DataGhost op 14-09-2020 02:34 ]

[Varkzor]

Maar vind geen drives in file manager

[Varkzor]

Moet er na die bs= nog iets komen? Is dat de 128 block size of is dat de size van wat je naar de outputfile wil schrijven?

[Mijzelf]

bs is de blockgrootte waarmee gekopieerd gaat worden. Dat heeft alleen iets met snelheid (van kopiëren) te maken.

Die partitie tabel op loop7 lijkt mij ruis. Dat type 'HPFS/NTFS/exFAT' lijkt heel specifiek, maar is in feite één byte die toevallig de juiste waarde heeft. De start- en eindsectors zijn er niet erg betrouwbaar uit. Op grond van de partititie tabellen zou ik denken dat loop6 toch echt eerst moet.

Buiten alle andere goede raad die je al gekregen hebt, je zou de array weer kunnen bouwen als eerst (loop6, loop7 chunk=128) en testdisk vragen om partities te zoeken. Deze kan hij niet wegschrijven want de array is read only, maar als hij met een goede suggestie komt kun je met wat loop magic de partitie(s) wel benaderen. Testdisk moet je waarschijnlijk nog wel installeren.

[Varkzor]

Op eerdere vraag de 2 files van loop 6 en 7:

https://drive.google.com/...alnnVuyU/view?usp=sharing

https://drive.google.com/...L5dDC8a7/view?usp=sharing

[Varkzor]

Ik kan md0 niet stoppen zegt busy te zijn kan ik dat ergens toch forcen?

[Varkzor]

Als ik em kan stoppen start ik opnieuw met rebuild.

[DataGhost]

Haal de bestanden maar weer weg. Het ziet er behoorlijk gaar uit dus recovery zal niet supertriviaal zijn. Op loop6 heb je een geldige partitietabel die over data heen is geschreven maar die maar 1 schijf groot is (tenzij je 1k sectors hebt maar dat heb ik alleen nog maar gezien bij een heel specifiek apparaat, geen PC), en het ziet er *bijna* uit alsof het de tweede disk was uit een JBOD (dus geen RAID0) omdat er direct na de partitietabel gewoon data staat. Op loop7 zie ik wederom een geldig MBR alleen slaan de entries in de partitietabel nergens op (tekst). Als ik zou moeten gokken was dat de eerste disk maar ik snap nog niet hoe die dan in die staat is gekomen, het lijkt bijna alsof die over een partitie heen is geschreven ipv een disk. Kan je eens posten wat

losetup -l

(ook weer min kleine L) laat zien? Is er misschien een mogelijkheid dat je drie disks achter elkaar hebt geplakt in plaats van twee? Of weet je heel zeker dat het er maar twee (die twee) waren? Want volgens mij zag ik nog eenzelfde schijf in je computer zitten.

Edit: weet je ook heel zeker dat het die twee schijven waren? Ik zie bijv. in begin6 een Firefox-licentietekst die wordt afgeknipt op een 128k-grens (dus waarschijnlijk wel 128k blocksize) maar de rest van die tekst zie ik niet op begin7 terug.

Edit2: begin7 ziet eruit alsof het een NTFS-partitie was, maar er is een MBR overheen gekwakt door GMBLDR van BTTR software. Die disk *lijkt* alsof 'ie nooit onderdeel is geweest van een RAID-set maar het zou wel kunnen.

[ Voor 20% gewijzigd door DataGhost op 14-09-2020 11:29 ]

[Varkzor]

Hi, zijn zeker 2 disks in raid, 2 maal WD500RE2 type.
Heb ik ooit raid0 op gemaakt, wel denk ik met 2 partitions, een c schijf en dan een 'small data' schijf denk ik.
Ik zie af en toe "small data II" staan en herinner me zoiets vaag van +- 15 jaar geleden.... ^^.

Ik post losetup-l in a sec.

[Varkzor]

[Varkzor]

Gezien die zegt dat die disks "busy" zijn, hoe kan ik ze droppen?

[DataGhost]

Small data II zie ik nu ook staan, 1MB in begin6. Daar houdt het ook weer op met de RAID-blokjes die ik daarvoor wel zag, dus die lijkt eroverheen geschreven te zijn.

[Varkzor]

Ik denk dat de MDR mogelijks messed up is.
Ik had gehoopt dat ik de disks kon herinitieren qua instellingen zodat hij wel de rest van de drives terug herkent. aar mogelijk is dat dan dus nietmeer mogelijk?

Ik had wel gehoopt dat dit mogelijk was. Ik vermoed dat het met de MBRs, of door bvb ooit de raid niet te herkennen en slechts 1 van de 2 disks, dat hij de mbr messed up heeft..

Volgens mij staat desondanks alle data er wel nog op, maarja, als ik ze niet herkenbaar kan maken ben ik er weinig mee

[Varkzor]

Zou ReclaiMe via Windows meer success hebben?
Als ik de drives ontkoppel en via USB aansluit buiten de jmicron raid config?

Just wondering... Iemand ervaring mee?

[DataGhost]

Geen enkel datarecovery-ding kan hier iets mee als je niet weet hoe het opgezet was. Het is lang geleden zeg je zelf ook al. Bovendien lijken ze onafhankelijk overschreven te zijn door andere dingen.
Wat ik hier kan zien op basis van die 10MB van elke disk en dus gok:
begin6 is ooit deel geweest van een RAID0 met 128k blocksize. Hier zie ik wat bestanden en e-mails uit ongeveer 2013, lijkt op 128k afgeknipt te zijn. De andere helften kan ik echter niet in begin7 vinden. Maar, hier *overheen* is een nieuwe partitietabel gemaakt met 1 partitie ter grootte van 1 disk (dus geen RAID) en inderdaad, op 1MB begint "Small Data II", precies zoals de partitietabel aangeeft. Dit lijkt een gewone NTFS-partitie te zijn die niet is opgeknipt in 128k-blokjes.
begin7 was ooit een NTFS-partitie "Small Data I". Er was dus geen partitietabel. Het lijkt niet alsof deze deel heeft uitgemaakt van een RAID-set. Over de NTFS-header is een nieuw MBR geschreven.
Ik denk dus niet dat ze op het laatste moment dat je er gebruik van hebt gemaakt in RAID hebben gestaan. In JBOD kan, maar dan verwacht ik nog een extra entry in de partitietabel van begin6.

De disk met Small Data II zou gewoon nog leesbaar moeten zijn, los dus niet in RAID. Er staat een geldige partitietabel op en de partitie begint ook daadwerkelijk op de plek die die tabel aangeeft.
De disk met Small Data I zou een recovery-programma iets mee moeten kunnen, ook los. Nogmaals, dit is wat ik gok op basis van de kleine stukjes disk die ik gezien heb.

[Varkzor]

Hmmmmm.
Maar dan zou ik toch verwachten dat de recovery tools er wat meer af moeten kunnen halen, en van wat ik zie is echt alles 'afgekapt'. Foto's laden 10-30% en rest is grey...

Wat ik dan vermoedelijk wel kan doen is alles loskoppelen, opstarten in win, via usb aansluiten en zien of er gewoon iets leesbaar is met aparte verbinding?

Just thinking out loud... Dan zou dus 1 van die drives moeten werken en ik daar al veel zonder 'damage' op moeten terugvinden?

Kan dat kloppen?

[DataGhost]

Nja, als het twee losse, onafhankelijke filesystems waren (niet in RAID) dan zijn die zonder RAID prima leesbaar of recoverable. Op het moment dat je ze in RAID0 zet zie je letterlijk beide filesystems dwars door elkaar heen, dus het zou prima zo kunnen zijn dat foto's dan "afgekapt" worden.

[Varkzor]

Alright, dan probeer ik wat ik denk, via usb aansluiten en eens zien wat er gebeurt, who knows

[DataGhost]

Zolang je maar geen chkdsk / controle / format doet zou er nog een behoorlijke kans kunnen zijn op redelijk wat herstel.

[Varkzor]

blijkbaar dus geen raid....... <hoe belachelijk van me>

Sorry beste mede-tweakers, 1 schijf werkt al zonder enig probleem via usb connector.
Al mn foto's beschikbaar... Goed nieuws dus!

No wonder the reinstall never worked.

Mijn excuses voor iedereen die er tijd aan gespendeerd heeft.
I owe you guys one!!!

[Varkzor]

@Mijzelf @DataGhost @Ben(V) @Thralas @Gman
Edit: Forgot to add: @Boermansjo @Zalmanman @jvanhambelgium

SUPER!BEDANKT!!!!!!

Ben echt mega blij, de raid is gewoon geen raid meer, het is ooit naar regular drives herbuilt!
Dat was ik duidelijk al lang vergeten!...

Nogmaals sorry voor jullie tijdverlies, maar dankzij jullie heb ik wel alles terug!

Nog eens super super super bedankt!
Kan ik jullie hier via Tweakers een review schrijven of zo?
Jullie verdienen allemaal een pluim van een review om spontaan te helpen! :-)

[ Voor 6% gewijzigd door Varkzor op 14-09-2020 16:39 ]

[Zalmanman]

Mag ik je een knurft spuit11 noemen? Natuurlijk wel op de meest attente manier.
Mooi dat het gelukt is, fijn dat je je data terug hebt! En (hopelijk) heb je ook nog wat geleerd van alle fdisk/mdadm spreuken in dit topic

[ Voor 3% gewijzigd door Zalmanman op 14-09-2020 16:49 ]

[Varkzor]

Lol, terecht dat ik dit zelf had moeten uitvogelen. Maar had eerlijk gezegd schrik als ik naar niet raid converteerde dat ik data kwijt zou zijn...

Dus dan maar een knurft of een spuit11 :-P

Indeed het een en ander bijgeleerd over Ubuntu en disk related commands.
Interesting stuff!
P.S. ben nu voor de 20ste keer of zo data recovery aan't runnen, maar dan op de 2de schijf, want die is wel ergens geradijsd op de een of andere manier...

Grtz
Varkzor

[Ben(V)]

Misschien heb je in het verleden enkel een disk van de raidset weer een enkelvoudige disk gemaakt en met de andere niks gedaan.
Die bevat dan de helft van een stripset waar je dus helemaal niets meer mee kunt.
Je kunt dan misschien steeds een datablock lezen maar het volgende blok staat dan op de andere disk, maar die is uit de raidset gehaald.

[DataGhost]

Ben(V) schreef op maandag 14 september 2020 @ 20:15:
Misschien heb je in het verleden enkel een disk van de raidset weer een enkelvoudige disk gemaakt en met de andere niks gedaan.
Die bevat dan de helft van een stripset waar je dus helemaal niets meer mee kunt.
Je kunt dan misschien steeds een datablock lezen maar het volgende blok staat dan op de andere disk, maar die is uit de raidset gehaald.

Voor zover ik kon zien stond op de tweede disk gewoon een NTFS-partitie waar een of andere tool een MBR overheen gepleurd heeft zonder het partitietabel-gedeelte noemenswaardig aan te passen, dus eigenlijk alleen de eerste 512 bytes zijn een beetje verkracht. Of dat verder nog veel kapot heeft gemaakt weet ik niet, maar ik gok van niet. Van striping was niet veel te zien. De namen van de NTFS-volumes suggereren ook dat er geen striping meer aan de hand was, "Small Data I" en "Small Data II". Waarschijnlijk is die disk te herstellen door een nieuwe NTFS-header te maken die past bij de disk maar dat leek me buiten de scope van wat TS kan. Aangezien hij al datarecoverysoftware had kon die waarschijnlijk veel beter aan de slag met de data die er nog op stond.

Ik heb hier met een hex-editor naar gekeken dus.

[Gman]

Tof dat het gelukt is!
En ik ben erg blij dat we van die Raid 0 ellende af zijn (m.a.w. SSD's zijn zo snel dat het niet meer nodig is)

[ Voor 71% gewijzigd door Gman op 15-09-2020 15:28 ]

[Varkzor]

Agreed, ik was er duidelijk zelf al van afgestapt jaren geleden wegens safety precautions.
Wellicht toen eerste ssd gekocht en andere drives re-installed als data drives..

Nogmaals dikke merci aan iedereen.
zeker 15 gig foto's en familie movies terug! :-D HUrrah!