Linux MDADM crash.

[y_boonstra]

Wie kan mij helpen om de juiste stappen te bepalen om bestanden te recoveren van mijn MDADM raid 5 ?

Mijn zelfbouw nas was toe aan hardware vervanging en heb daarvoor een nieuwe U-NAS case, motherboard, xeon en ecc geheugen besteld en samengebouwd.

Na wat drempels was het gelukt om OMV op een M2 met NVMe te installeren.
Tijd om dus mijn schijven van mijn oude nas te verhuizen naar de nieuwe setup.

Helaas kwam de raid niet vanzelf online, wat met een eerdere verhuizing wel het geval was. Na wat info op te vragen van de schijven kwam ik er achter dat van de 5x 3tb raid5 setup bij de 3 oudere schijven mijn superblocks verdwenen was .

Geprobeerd de raid geforceerd opnieuw op te starten zonder resultaat. en om alles erger te maken heb ik in een verstands verbijstering per ongeluk de opdracht gegeven na veel proberen er een nieuwe journal op te zetten.

hierna ben ik gestopt en de schijven er uitgehaald en opgestuurd naar een professioneel recovery bedrijf te sturen. in een team view sessie heb ik gezien dat bestanden terug te halen zijn (ik heb dit o.a gecontroleerd door vele foto's te openen).

voor onderzoek moest ik een x bedrag betalen waarna ze een offerte zouden maken wat de recovery kosten zouden worden (wat ze eigenlijk al gedaan hadden). dit was vrijblijvend.

Het bedrag was dusdanig hoog dat ik er op dat moment van af heb gezien en graag mijn schijven terug wilde hebben met het idee dat dit altijd nog kan.

ondertussen heb ik voor de zekerheid thuis de schijven gekloond en met deze schijven wil ik zelf trachten de bestanden te herstellen.


Ik heb een parted magic distributie liggen waar ik photorec / testdisk wil gebruiken om te laten zoeken,
maar hoe nu verder.
Ik weet de volgorde van de schijven in de raid niet op 2 schijven na.

wordt het een kwestie van diverse raid volgordes forceren en dan scannen?

root@DARK-VAULT:~# mdadm --examine /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 78601ff4:5022822d:40ae7e71:1794c4d6
Name : openmediavault:0
Creation Time : Sat Jan 5 23:58:39 2013
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 08c8efa3:e8b07613:0a79598e:521e0a25

Update Time : Sat Jul 1 20:40:48 2017
Checksum : d4655f24 - correct
Events : 57494

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 4
Array State : AAAAA ('A' == active, '.' == missing)
root@DARK-VAULT:~# mdadm --examine /dev/sdc
/dev/sdc:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
root@DARK-VAULT:~# mdadm --examine /dev/sdd
/dev/sdd:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
root@DARK-VAULT:~# mdadm --examine /dev/sde
/dev/sde:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)
root@DARK-VAULT:~# mdadm --examine /dev/sde1
mdadm: No md superblock detected on /dev/sde1.
root@DARK-VAULT:~# mdadm --examine /dev/sdf
/dev/sdf:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 78601ff4:5022822d:40ae7e71:1794c4d6
Name : openmediavault:0
Creation Time : Sat Jan 5 23:58:39 2013
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f7fdb09f:f7b15921:2152c830:c11fb3d3

Update Time : Sat Jul 1 20:40:48 2017
Checksum : 2f2170a6 - correct
Events : 57494

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 0
Array State : AAAAA ('A' == active, '.' == missing)
root@DARK-VAULT:~# mdadm --examine /dev/sdf
/dev/sdf:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 78601ff4:5022822d:40ae7e71:1794c4d6
Name : openmediavault:0
Creation Time : Sat Jan 5 23:58:39 2013
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : f7fdb09f:f7b15921:2152c830:c11fb3d3

Update Time : Sat Jul 1 20:40:48 2017
Checksum : 2f2170a6 - correct
Events : 57494

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 0
Array State : AAAAA ('A' == active, '.' == missing)
root@DARK-VAULT:~# mdadm --examine /dev/sdb
/dev/sdb:
Magic : a92b4efc
Version : 1.2
Feature Map : 0x0
Array UUID : 78601ff4:5022822d:40ae7e71:1794c4d6
Name : openmediavault:0
Creation Time : Sat Jan 5 23:58:39 2013
Raid Level : raid5
Raid Devices : 5

Avail Dev Size : 5860271024 (2794.40 GiB 3000.46 GB)
Array Size : 11720540160 (11177.58 GiB 12001.83 GB)
Used Dev Size : 5860270080 (2794.39 GiB 3000.46 GB)
Data Offset : 262144 sectors
Super Offset : 8 sectors
State : clean
Device UUID : 08c8efa3:e8b07613:0a79598e:521e0a25

Update Time : Sat Jul 1 20:40:48 2017
Checksum : d4655f24 - correct
Events : 57494

Layout : left-symmetric
Chunk Size : 512K

Device Role : Active device 4
Array State : AAAAA ('A' == active, '.' == missing)
root@DARK-VAULT:~# mdadm --examine /dev/sdc
/dev/sdc:
MBR Magic : aa55
Partition[0] : 4294967295 sectors at 1 (type ee)

[Mijzelf]

Iemand of iets heeft bij 3 van de 5 schijven er een protective MBR opgezet. Deze neemt 1 sector in beslag.
Als het hierbij blijft, zou het superblock er nog moeten zijn, aangezien die op offset 8 zit:

Super Offset : 8 sectors

Ik denk dat de eerste 8 sectors worden geacht leeg te zijn. Je zou kunnen proberen om die protective MBR gewoon te wissen, of die te overschrijven met een 'goede sector':

dd if=/dev/zero of=/dev/sdc bs=512 count=1

of

dd if=/dev/sdb of=/dev/sdc bs=512 count=1

Als er meer is geschreven dan alleen een MBR, bijvoorbeeld een complete GTP, dan zijn de superblocks overschreven. Volgens mij is de aangewezen weg dan om de array opnieuw te creëren met de vlag '--assume-clean', waarbij je de gegevens uit de header specificeert voor zover mogelijk om te voorkomen dat de nieuwe mdadm andere defaults gebruikt.

Hierbij is het wel van belang dat de volgorde van de schijven hetzelfde is als oorspronkelijk. (Zoals je ze aanbied aan mdadm. De fysieke volgorde is niet belangrijk). Weet je de oorspronkelijke volgorde nog?