Mounten van een RAID 1 partitie met nog enkele disk

[Montaner]

Ik had een CH3MNAS van Conceptronics met daarin 2 schijven, waarbij ik een partitie had aangemaakt van 500GB in RAID1 zodat ze gemirrored werden over de 2 schijven. Deze NAS heeft een lange tijd stil gestaan, verhuisd, en mogelijk wat butsen gehad. Zodanig dat de NAS zelf niet meer werkt, 1 schijf echt de geest heeft gegeven maar de andere schijf nog 'prima' herkend wordt.

Nu wil ik dus toegang tot deze partitie. Ik heb de schijf aan m'n PC gehangen, in de hoop er eenvoudig bij te kunnen. Niet dus. Met een beetje Googlen naar de oude NAS verwacht ik dat het een ext2 partitie is. Hiermee ben ik aan de slag gegaan in Windows Subsystem for Linux om de schijf toegankelijk te krijgen.

Tot zover geen succes.

code:

lsblk

geeft op dit moment het volgende resultaat

code:

NAME      MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda         8:0    0   256G  0 disk
sdb         8:16   0 339.8M  1 disk
sdc         8:32   0   256G  0 disk  /
sdd         8:48   0   1.4T  0 disk
├─sdd1      8:49   0 517.7M  0 part
├─sdd2      8:50   0   502M  0 part
├─sdd3      8:51   0   466G  0 part
│ └─md127   9:127  0 465.9G  0 raid1
├─sdd4      8:52   0     1K  0 part
└─sdd5      8:53   0 930.3G  0 part

Waarbij sdd3/md127 de genoemde partitie is.

Het huidige raid array is aangemaakt met

code:

sudo mdadm --create --assume-clean /dev/md/md_test --level=1 --raid-devices=2
/dev/sdd3 missing
mdadm: /dev/sdd3 appears to contain an ext2fs file system
       size=488640960K  mtime=Tue Jan 13 22:55:59 2015
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90
Continue creating array? y
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md/md_test started

Waarbij het vermoeden van ext2 wel bevestigd lijkt te worden.

Het proberen te mounten hiervan geeft het volgende resultaat

code:

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/md127, missing codepage or helper program, or other error

code:

dmesg

Geeft

code:

[12836.685484] EXT4-fs (md127): VFS: Can't find ext4 filesystem

Wat mij logisch lijkt.. maar

code:

mount -t ext3 of mount -t ext2

geeft geen enkel verschil in de melding noch dat er gepoogd wordt ext3 te gebruiken of ext2 (twijfel of ext2 sowieso als support in de kernel zit).

Al met al is het bij elkaar gegoogled.. en wie weet al meer kapot gemaakt dan gerepareerd. Maar zit nu echt vast..

[ Voor 6% gewijzigd door Montaner op 30-03-2022 22:12 ]

[thunder7]

Simpelste oplossing lijkt me

1) trek een fysieke kopie van deze schijf, zodat je een backup hebt
dd if=/dev/sdd of=backup_image.dat

dit duurt lang, verwacht ik, en doe het in een directory met voldoende (1.5 Tb?) ruimte

2) koop een wel werkende ch3mnas

https://www.marktplaats.n...ch3mnas-met-wd-1tb-schijf

voor weinig geld, steek deze disk er in en hoop dat hij het doet.

[ Voor 7% gewijzigd door thunder7 op 31-03-2022 07:02 ]

[Montaner]

Goed alternatief om in het achterhoofd te houden, maar ik vermoed dat ik inmiddels de indeling daarvoor om zeep heb geholpen waardoor de CH3MNAS, welke al niet het slimste apparaat is, de disk als incompatible ziet en wil formatten.

Edit: ik heb de disk in een CH3MNAS gestoken, zoals ik helaas vermoedde geeft deze enkel de disk info, geen partitie info en enkel de optie tot herformatteren.

[ Voor 25% gewijzigd door Montaner op 31-03-2022 17:31 ]

[Thralas]

Montaner schreef op woensdag 30 maart 2022 @ 22:03:
Het huidige raid array is aangemaakt met

code:

sudo mdadm --create --assume-clean /dev/md/md_test --level=1 --raid-devices=2

[...]

Al met al is het bij elkaar gegoogled.. en wie weet al meer kapot gemaakt dan gerepareerd. Maar zit nu echt vast..

Als je nou eens niet --create had gebruikt. Daarmee heb je het inderdaad wel aardig kapotgerepareerd, doordat je daarmee nieuwe RAID metadata schrijft (nergens voor nodig). Voor een bestaande RAID array bestaat de assemble-actie. Meestal gaat dat vanzelf, behalve als er een schijf ontbreekt. Handmatig assemblen is dan de oplossing.

Je originele NAS gebruikte 0.90 metadata, terwijl je 1.2 hebt weggeschreven. Eerstgenoemde staat aan het einde van de disk, terwijl 1.2 op 4k van het begin van het block device staat. Daarmee heb je nu je filesystem gedeeltelijk overschreven met de 1.2 metadata.

Hoe stuk is de andere schijf? Als hij enkel bad sectors heeft kun je daar de sectoren die je nu hebt overschreven nog wel vanaf halen. Anders is de enige optie het fscken van je filesystem en hopen dat er niet al te veel corrupt is. Je kunt het beste de partitie imagen voor je daarmee aan de slag gaat, zodat je altijd nog terugkunt.

En die fsck/mount kun je direct op sdd3 (of liever: image ervan) uitvoeren - omdat 0.90 RAID metadata aan het eind van de disk staat kun je een RAID1-partitie gewoon mounten alsof er helemaal geen sprake is van RAID (mits je hem daarna nooit meer als array member gebruikt).

[Montaner]

Thralas schreef op vrijdag 1 april 2022 @ 22:33:
[...]


Als je nou eens niet --create had gebruikt. Daarmee heb je het inderdaad wel aardig kapotgerepareerd, doordat je daarmee nieuwe RAID metadata schrijft (nergens voor nodig). Voor een bestaande RAID array bestaat de assemble-actie. Meestal gaat dat vanzelf, behalve als er een schijf ontbreekt. Handmatig assemblen is dan de oplossing.

Je originele NAS gebruikte 0.90 metadata, terwijl je 1.2 hebt weggeschreven. Eerstgenoemde staat aan het einde van de disk, terwijl 1.2 op 4k van het begin van het block device staat. Daarmee heb je nu je filesystem gedeeltelijk overschreven met de 1.2 metadata.

Hoe stuk is de andere schijf? Als hij enkel bad sectors heeft kun je daar de sectoren die je nu hebt overschreven nog wel vanaf halen. Anders is de enige optie het fscken van je filesystem en hopen dat er niet al te veel corrupt is. Je kunt het beste de partitie imagen voor je daarmee aan de slag gaat, zodat je altijd nog terugkunt.

En die fsck/mount kun je direct op sdd3 (of liever: image ervan) uitvoeren - omdat 0.90 RAID metadata aan het eind van de disk staat kun je een RAID1-partitie gewoon mounten alsof er helemaal geen sprake is van RAID (mits je hem daarna nooit meer als array member gebruikt).

Geeft de volgende melding

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem. If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
e2fsck -b 8193 <device>
or
e2fsck -b 32768 <device>

Is er een optie om voor de superblock switch een grootte te achterhalen?

[Thralas]

Wat is het exacte commando dat je hebt uitgevoerd?

Wat geeft dumpe2fs /dev/sdd3? En file /dev/sdd3?

Hij zou vanzelf een backup superblock moeten vinden meen ik. Als ik je issue naboots (ext2 filesystem overschrijven met v1.2 RAID metadata) dan levert dat ook geen problemen op hier.

Suggereert dat er toch nog iets anders aan de hand is.

[Mijzelf]

Thralas schreef op zondag 3 april 2022 @ 23:45:
Als ik je issue naboots (ext2 filesystem overschrijven met v1.2 RAID metadata) dan levert dat ook geen problemen op hier.

Had je daarbij ook dat filesystem aangemaakt op een v0.9 array? Ik neem aan dat de superblock gevonden wordt als functie van de de grootte van het blockdevice, wat een probleem zou kunnen zijn.

[Thralas]

Mijzelf schreef op dinsdag 5 april 2022 @ 10:07:
Had je daarbij ook dat filesystem aangemaakt op een v0.9 array? Ik neem aan dat de superblock gevonden wordt als functie van de de grootte van het blockdevice, wat een probleem zou kunnen zijn.

Geen verkeerde suggestie, maar ik denk dat die locaties fixed zijn (volgens mij zijn het bepaalde machten) en alleen het aantal een functie is van de grootte. Heb het nog een keer herhaald:

# mkfs.ext2 /dev/md0
mke2fs 1.46.4 (18-Aug-2021)
Creating filesystem with 122160224 4k blocks and 30547968 inodes
Filesystem UUID: 83af191a-5067-4c8d-a3d4-5cafa714fb69
Superblock backups stored on blocks: 
	32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 
	4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 
	102400000

# mdadm --create  -l 1 -n 2 /dev/md0 /dev/loop3 missing
mdadm: /dev/loop3 appears to contain an ext2fs file system
       size=488640896K  mtime=Thu Jan  1 01:00:00 1970
mdadm: /dev/loop3 appears to be part of a raid array:
       level=raid1 devices=2 ctime=Tue Apr  5 21:50:09 2022
mdadm: Note: this array has metadata at the start and
    may not be suitable as a boot device.  If you plan to
    store '/boot' on this device please ensure that
    your boot-loader understands md/v1.x metadata, or use
    --metadata=0.90

Wat wel opvalt is dat ik nog expliciet gewaarschuwd wordt voor de bestaande array, wat ik bij TS niet terugzie. Doet afvragen of er niet nog iets anders aan de hand is, bijvoorbeeld als TS een USB-SATA adapter heeft gebruikt icm de bekende logical/physical sector size mismatch.

[Montaner]

Thralas schreef op zondag 3 april 2022 @ 23:45:
Wat is het exacte commando dat je hebt uitgevoerd?

Wat geeft dumpe2fs /dev/sdd3? En file /dev/sdd3?

Hij zou vanzelf een backup superblock moeten vinden meen ik. Als ik je issue naboots (ext2 filesystem overschrijven met v1.2 RAID metadata) dan levert dat ook geen problemen op hier.

Suggereert dat er toch nog iets anders aan de hand is.

dumpe2fs /dev/sdd3

code:

dumpe2fs 1.45.5 (07-Jan-2020)
dumpe2fs: Input/output error while trying to open /dev/sdd3
Couldn't find valid filesystem superblock.

en
file /dev/sdd3

code:

/dev/sdd3: block special (8/51)

Waar het leek dat deze schijf nog functioneerde is dat dus niet zo. e2fsck loopt inmiddels al meer dan een dag en blijft errors op blocks geven of ontzettend lang hangen op sommige blocks.

[DataGhost]

En je weet zeker dat je niet op de verkeerde schijf bezig bent in plaats van met de "werkende"?
Verder is het wel te verwachten dat als je twee identieke schijven uit waarschijnlijk dezelfde batch dezelfde workload geeft, dat ze ongeveer tegelijk kapot gaan. Tenminste, die kans is een stuk groter dan met verschillende schijven/leeftijden.

[ Voor 55% gewijzigd door DataGhost op 06-04-2022 15:04 ]

[Montaner]

DataGhost schreef op woensdag 6 april 2022 @ 15:03:
En je weet zeker dat je niet op de verkeerde schijf bezig bent in plaats van met de "werkende"?
Verder is het wel te verwachten dat als je twee identieke schijven uit waarschijnlijk dezelfde batch dezelfde workload geeft, dat ze ongeveer tegelijk kapot gaan. Tenminste, die kans is een stuk groter dan met verschillende schijven/leeftijden.

Helaas wel van de andere schijf wordt nog een volume van 8gb gezien, van de 2TB...

[ Voor 7% gewijzigd door Montaner op 06-04-2022 15:12 ]

[Thralas]

Montaner schreef op woensdag 6 april 2022 @ 14:59:
[...]

dumpe2fs /dev/sdd3

code:

dumpe2fs 1.45.5 (07-Jan-2020)
dumpe2fs: Input/output error while trying to open /dev/sdd3
Couldn't find valid filesystem superblock.

Ehhhh

code:

dumpe2fs: Input/output error while trying to open /dev/sdd3

Waarom is dat? Heb je al in de kernel logs gekeken? SMART?

En sorry, daar waar ik zei file bedoelde ik file -s

e2fsck loopt inmiddels al meer dan een dag en blijft errors op blocks geven of ontzettend lang hangen op sommige blocks.

Nog een extra aanwijzing om eens naar de kernel logs/SMART te kijken. Dat hoort niet zo lang te duren, de disk heeft niet toevallig een handvol bad sectors?

[ Voor 5% gewijzigd door Thralas op 06-04-2022 19:55 ]