Forum Datorkomponenter Lagring Tråd

Raid 5. Hittar inte filsystemet längre.

1
Skriv svar
Permalänk
Medlem
●

Raid 5. Hittar inte filsystemet längre.

Hej Jag sitter just nu och hjälper en vän med en krypterad raid 5 som har fått strul efter en flytt.
Problemet uppstod efter att alla diskar flyttat från en installation till en ny. Med ominstallation av sys os, fysisk flytt/byte av hw.
Där hittades de inte allas till en början. Utan efter div meck med agg / satakort osv så har alla diskar hittats av systemet.

Vi har lyckats låsa upp denna krypterade raid, men problemet är att han inte kommer ihåg vad för filsystem som låg på denna raid.
Vi tror det är ext4 alt xfs, hur kan vi lista ut filsystem samt superblock så vi får de att funka igen?
Systemet är Debian 8.7 med mdadmin v3.3.2

Vid mount får jag error om att den inte vet vilket superblock raiden har

“mount: wrong fs type, bad option, bad superblock on /dev/mapper/filer”
När jag kör e2fsck mot raiden när den är upplåst
e2fsck /dev/mapper/filer
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/filer
via Dumpe2fs:
dumpe2fs /dev/mapper/filer
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/filer
Couldn't find valid filesystem superblock.
Med xfs.
xfs_repair -L /dev/mapper/filer
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

fdisk:

Disk /dev/md3: 36.4 TiB, 40006508871680 bytes, 78137712640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 5242880 bytes

mdadm --detail /dev/md3
/dev/md3:
Version : 1.2
Creation Time : Sun Feb 12 16:29:46 2017
Raid Level : raid5
Array Size : 39068856320 (37258.97 GiB 40006.51 GB)
Used Dev Size : 3906885632 (3725.90 GiB 4000.65 GB)
Raid Devices : 11
Total Devices : 11
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Tue Feb 14 11:41:02 2017
State : clean
Active Devices : 11
Working Devices : 11
Failed Devices : 0
Spare Devices : 0
...

Layout : left-symmetric
Chunk Size : 512K

Jag kanske har missat något helt öppenbart, eller är vi helt rökta?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av MrHummf:

Vi har lyckats låsa upp denna krypterade raid, men problemet är att han inte kommer ihåg vad för filsystem som låg på denna raid.

Gå till inlägget

Information saknas -- vilken krypteringsmetod användes? RAID-setet verkar ju må hur bra som helst, men hur har ni "låst upp" den krypterade blockdevicen (som det troligtvis handlar om)?

Skrivet av MrHummf:

Vi tror det är ext4 alt xfs, hur kan vi lista ut filsystem samt superblock så vi får de att funka igen?

Gå till inlägget

"file -sL /dev/mapper/filer", kanske? Eller någon annan metod.

Redigera
Citera flera Citera
Permalänk
Medlem
●

Har för mig att man kan köra kommandot för att skapa ett nytt filsystem med någon dry run switch så talar den bara om vad den skulle göra, då listar den var superblock finns. Den metoden fungerar nog bara med samma version av filsystemsprogrammet och om man använder samma switches som när man skapade filsystemet.
Hittade den här sidan som beskriver en annan metod:
https://www.cyberciti.biz/faq/linux-find-alternative-superblo...

Vilket filsystem det är:
https://unix.stackexchange.com/questions/53542/how-to-determi...
Kolla med Parted eller fdisk och se om du hittar något användbart.

Vet inte hur det påverkar att det ligger på en RAID, men så länge du inte skriver någon data borde det vara lugnt.

Visa signatur

RAID is not a backup

Redigera
Citera flera Citera
Permalänk
Moderator
Festpilot 2020, Antiallo ★
●

@MrHummf: Det absolut viktigaste är att ni slutar arbeta med diskarna all information finns på om ni inte kan tänka er förlora all information.
Gör rätt och dra en image-kopia på hela diskarna om ni skall arbeta med detta. Då kan ni testa olika filsystem utan att oroa er för att allt försvinner.

Om ni inte lyckas alls så får ni skicka in originalen till företag som sysslar med dataräddning.

Visa signatur

 | PM:a Moderatorerna | Kontaktformuläret | Geeks Discord |
Testpilot, Skribent, Moderator & Geeks Gaming Huvudadmin

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av Hieronymus Bosch:

Information saknas -- vilken krypteringsmetod användes? RAID-setet verkar ju må hur bra som helst, men hur har ni "låst upp" den krypterade blockdevicen (som det troligtvis handlar om)?
"file -sL /dev/mapper/filer", kanske? Eller någon annan metod.

Gå till inlägget

Det är en LUKS kryptering. Men efter som den låste upp den utan gnäll överhuvetaget så bör det lira som den ska. Specifikt ” cryptsetup luksOpen …. ”

Får detta endast, med file..
“ file -sL /dev/mapper/filer
/dev/mapper/filer: data ”

samt mot enskild hdd.
”file -sL /dev/sdj1
/dev/sdj1: Linux Software RAID version 1.2 (1) UUID=910314a8:e92bd2dd:310a9d1f:1620ce00 name=Lian-li:3 level=5 disks=11”

Skrivet av Jpau94:

Har för mig att man kan köra kommandot för att skapa ett nytt filsystem med någon dry run switch så talar den bara om vad den skulle göra, då listar den var superblock finns. Den metoden fungerar nog bara med samma version av filsystemsprogrammet och om man använder samma switches som när man skapade filsystemet.
Hittade den här sidan som beskriver en annan metod:
https://www.cyberciti.biz/faq/linux-find-alternative-superblo...

Vilket filsystem det är:
https://unix.stackexchange.com/questions/53542/how-to-determi...
Kolla med Parted eller fdisk och se om du hittar något användbart.

Vet inte hur det påverkar att det ligger på en RAID, men så länge du inte skriver någon data borde det vara lugnt.

Gå till inlägget

Du är inne på mke2fs -n vilket visar vilka superblock den hade velat använda.
"
mke2fs -n /dev/mapper/filer
mke2fs 1.42.12 (29-Aug-2014)
mke2fs: Size of device (0x2462bd8ff blocks) /dev/mapper/filer too big to be expressed
in 32 bits using a blocksize of 4096.
"

Skrivet av DavidtheDoom:

@MrHummf: Det absolut viktigaste är att ni slutar arbeta med diskarna all information finns på om ni inte kan tänka er förlora all information. Om ni inte lyckas alls så får ni skicka in originalen till företag som sysslar med dataräddning.

Gå till inlägget

Det är en risk vi får tar, så värdefull är inte infon. Men väldigt bra synpunkt!

Hur som tack för all input. tycker redan försökt med dessa förslag redan. utan framgång. Nån mer ide?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av MrHummf:

Hej Jag sitter just nu och hjälper en vän med en krypterad raid 5 som har fått strul efter en flytt.
Problemet uppstod efter att alla diskar flyttat från en installation till en ny. Med ominstallation av sys os, fysisk flytt/byte av hw.
Där hittades de inte allas till en början. Utan efter div meck med agg / satakort osv så har alla diskar hittats av systemet.

Vi har lyckats låsa upp denna krypterade raid, men problemet är att han inte kommer ihåg vad för filsystem som låg på denna raid.
Vi tror det är ext4 alt xfs, hur kan vi lista ut filsystem samt superblock så vi får de att funka igen?
Systemet är Debian 8.7 med mdadmin v3.3.2

Vid mount får jag error om att den inte vet vilket superblock raiden har

“mount: wrong fs type, bad option, bad superblock on /dev/mapper/filer”
När jag kör e2fsck mot raiden när den är upplåst
e2fsck /dev/mapper/filer
e2fsck 1.42.12 (29-Aug-2014)
ext2fs_open2: Bad magic number in super-block
e2fsck: Superblock invalid, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/mapper/filer
via Dumpe2fs:
dumpe2fs /dev/mapper/filer
dumpe2fs 1.42.12 (29-Aug-2014)
dumpe2fs: Bad magic number in super-block while trying to open /dev/mapper/filer
Couldn't find valid filesystem superblock.
Med xfs.
xfs_repair -L /dev/mapper/filer
Phase 1 - find and verify superblock...
bad primary superblock - bad magic number !!!

fdisk:

Disk /dev/md3: 36.4 TiB, 40006508871680 bytes, 78137712640 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 524288 bytes / 5242880 bytes

mdadm --detail /dev/md3
/dev/md3:
Version : 1.2
Creation Time : Sun Feb 12 16:29:46 2017
Raid Level : raid5
Array Size : 39068856320 (37258.97 GiB 40006.51 GB)
Used Dev Size : 3906885632 (3725.90 GiB 4000.65 GB)
Raid Devices : 11
Total Devices : 11
Persistence : Superblock is persistent

Intent Bitmap : Internal

Update Time : Tue Feb 14 11:41:02 2017
State : clean
Active Devices : 11
Working Devices : 11
Failed Devices : 0
Spare Devices : 0
...

Layout : left-symmetric
Chunk Size : 512K

Jag kanske har missat något helt öppenbart, eller är vi helt rökta?

Gå till inlägget

Körde han med LVM eller motsvarande på det andra systemet?
I så fall ligger det troligen en massa LVM-info innan filsystemet börjar.

Sen är ju /dev/md3 krypterad, vad säger fdisk om /dev/mapper/files ?
Fanns det partitioner på /dev/mapper/files eller var den monterad direkt?
/etc/fstab eller motsvarande på gamla systemet kan ge ledtrådar.

Även om ext4 klarar mer än 16 TiB stora filsystem så finns det en 16TiB begränsning i äldre utilites så kolla att de stöder filsystem större än 16TiB.

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av MrHummf:

Det är en LUKS kryptering. Men efter som den låste upp den utan gnäll överhuvetaget så bör det lira som den ska. Specifikt ” cryptsetup luksOpen …. ”

Får detta endast, med file..
“ file -sL /dev/mapper/filer
/dev/mapper/filer: data ”

Gå till inlägget

Oj. Data. Det var inte mycket till hjälp. "Enheten innehåller ettor och nollor", liksom.

Skrivet av SAFA:

Körde han med LVM eller motsvarande på det andra systemet?
I så fall ligger det troligen en massa LVM-info innan filsystemet börjar.

Gå till inlägget

Det borde "file -sL" ha upptäckt. Om jag kör file -sL mot en partition som är en "physical volume" i LVMs ögon får jag

Skrivet av file -sL:

/dev/sdb1: LVM2 PV (Linux Logical Volume Manager), UUID: UgIIRX-MW2u-WxEK-kvJv-Ql1Z-UcZM-Dna5jY, size: 8001562156544

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Hieronymus Bosch:

Oj. Data. Det var inte mycket till hjälp. "Enheten innehåller ettor och nollor", liksom.
Det borde "file -sL" ha upptäckt. Om jag kör file -sL mot en partition som är en "physical volume" i LVMs ögon får jag

Gå till inlägget

Sant, det borde den sett, då kan man undra om dekrypteringen funkat, ger

hexdump -C /dev/mapper/filer | more

nånting som inte ser ut som helt slumpmässigt data?
och om inte: finns det nån backup på luks-headern?

Redigera
Citera flera Citera
1
Skriv svar
Senaste nyheterna
Hårdvara
Mjukvara
Övrigt
Nytt i forumet
Datorkomponenter
System
Ljud, bild och kommunikation
Spel och mjukvara