Schijf uit NAS mounten in Linux na mdadm create

[Uittenbogaard]

Hallo mede-tweakers,

Ik hoop dat jullie me nog kunnen helpen. Voordat ik het ga horen: ik weet het, RAID 1 is geen fatsoenlijke backup en nee, ik had niet moeten klooien zonder terugvalscenario. Waarschijnlijk wordt dit een harde les maar misschien is nog niet alles verloren..

mijn vraag
Ik had een QNAP NAS, die heeft het loodje gelegd. Deze bevatte 2 schijven in RAID 1. Ik heb geprobeerd 1 schijf te mounten onder een bootable Linux als degraded RAID1 array en liep eigenlijk tegen exact dezelfde problemen aan als deze tweaker: harddisk uit een nas mounten onder Ubuntu

De schijf heeft 5 partities, waarvan partitie 3 de datapartitie is die ik moet hebben. Die kreeg ik simpelweg niet gemount.

Jammer genoeg heb ik dat topic niet op tijd gevonden. Stom genoeg heb ik een nieuwe array gemaakt met de besbetreffende partitie met mdadm --create. vgscan / vgdisplay laat geen volume group meer zien. Ik kom vanaf hier dus ook niet meer verder.

Relevante software en hardware die ik gebruikt heb
USB docking
Ubuntu live disk (nu een Ubuntu virtualbox gemaakt)

Wat ik al gevonden of geprobeerd heb
Teveel dus.

De schijf:

code:

Device          Start        End    Sectors   Size Type
/dev/sdb1          40    1060289    1060250 517,7M Microsoft basic data
/dev/sdb2     1060296    2120579    1060284 517,7M Microsoft basic data
/dev/sdb3     2120584 3889240109 3887119526   1,8T Microsoft basic data
/dev/sdb4  3889240112 3890300399    1060288 517,7M Microsoft basic data
/dev/sdb5  3890300408 3907007999   16707592     8G Microsoft basic data

mdstat:

code:

root@max-VirtualBox:~# cat /proc/mdstat
Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] 
md123 : inactive sdb5[0](S)
      8353780 blocks super 1.0
       
md124 : active (auto-read-only) raid1 sdb3[0]
      1943428672 blocks super 1.2 [2/1] [U_]
      bitmap: 0/15 pages [0KB], 65536KB chunk

md125 : inactive sdb2[0](S)
      530124 blocks super 1.0
       
md126 : active (auto-read-only) raid1 sdb1[0]
      530048 blocks super 1.0 [24/1] [U_______________________]
      bitmap: 1/1 pages [4KB], 65536KB chunk

md127 : active (auto-read-only) raid1 sdb4[0]
      458880 blocks super 1.0 [24/1] [U_______________________]
      bitmap: 1/1 pages [4KB], 65536KB chunk

mdadm --detail /dev/md124:

code:

root@max-VirtualBox:~# mdadm --detail /dev/md124
/dev/md124:
        Version : 1.2
  Creation Time : Tue Nov 28 01:27:01 2017
     Raid Level : raid1
     Array Size : 1943428672 (1853.40 GiB 1990.07 GB)
  Used Dev Size : 1943428672 (1853.40 GiB 1990.07 GB)
   Raid Devices : 2
  Total Devices : 1
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Nov 28 01:28:34 2017
          State : clean, degraded 
 Active Devices : 1
Working Devices : 1
 Failed Devices : 0
  Spare Devices : 0

           Name : ubuntu:2
           UUID : 981593da:d74ddea4:de732996:74ca59cc
         Events : 2

    Number   Major   Minor   RaidDevice State
       0       8       19        0      active sync   /dev/sdb3
       2       0        0        2      removed

code:

root@max-VirtualBox:~# mdadm --examine /dev/sdb3
/dev/sdb3:
          Magic : a92b4efc
        Version : 1.2
    Feature Map : 0x1
     Array UUID : 981593da:d74ddea4:de732996:74ca59cc
           Name : ubuntu:2
  Creation Time : Tue Nov 28 01:27:01 2017
     Raid Level : raid1
   Raid Devices : 2

 Avail Dev Size : 3886857382 (1853.40 GiB 1990.07 GB)
     Array Size : 1943428672 (1853.40 GiB 1990.07 GB)
  Used Dev Size : 3886857344 (1853.40 GiB 1990.07 GB)
    Data Offset : 262144 sectors
   Super Offset : 8 sectors
   Unused Space : before=262056 sectors, after=38 sectors
          State : clean
    Device UUID : 4ce2d694:a01eab31:865d1ba1:1664b916

Internal Bitmap : 8 sectors from superblock
    Update Time : Tue Nov 28 01:28:34 2017
  Bad Block Log : 512 entries available at offset 72 sectors
       Checksum : 2d846004 - correct
         Events : 2


   Device Role : Active device 0
   Array State : A. ('A' == active, '.' == missing, 'R' == replacing)

Is het nog mogelijk dat ik de array op een of andere manier zo terugkrijg zoals deze was opgebouwd uit de NAS, of is er nog een andere mogelijkheid dat ik de data in ieder geval er af kan krijgen? Ik ben niet zo heel erg bekend met Linux, laat staan mdadm (zo blijkt maar weer )

edit:
Ik zou hetgene proberen uit het gelinkte topic maar ik ben nergens meer zeker van. Anders had ik het volgende geprobeerd:

sudo losetup -ro $((262144*512)) /dev/loop0 /dev/sdb3
sudo blkid

[TommyboyNL]

Als het een RAID1 is kan je toch een kloon van je andere RAID member maken, en daarmee aan de slag?

[Uittenbogaard]

Helaas is dit de enige schijf die nog werkend is overgebleven..

[jan99999]

Weer een tip voor in het vervolg.
Maak eerst een kopie van een hd, en ga dan iets proberen.(2x).

Dus je hebt nu over je hd heen geschreven, en je wilt je oude data terug hebben.
Dus zoek recovery software, vermoedelijk die raid kent, en zoek ook met google hoe te recoveren.
of het nog gaat weet ik niet.

[Hero of Time]

Heb je al eens een mount geprobeerd op de partitie met al je data? Het lijkt wel gewoon je partities te zien, wie weet dat het volgende wel genoeg is?

mount -t ext3 -o ro /dev/sdb3 /mnt/

[Uittenbogaard]

code:

root@max-VirtualBox:~# mount -t ext3 -o ro /dev/sdb3 /mnt/
mount: /dev/sdb3 is already mounted or /mnt busy

df -h:

code:

root@max-VirtualBox:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            474M     0  474M   0% /dev
tmpfs           100M  3,6M   96M   4% /run
/dev/sda1       8,8G  4,1G  4,3G  50% /
tmpfs           496M  172K  495M   1% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           496M     0  496M   0% /sys/fs/cgroup
tmpfs           100M   48K   99M   1% /run/user/1000
/dev/sr0         58M   58M     0 100% /media/max/VBox_GAs_5.2.2

[Hero of Time]

Zit je nou met een fysieke schijf in een VM te werken? Hoe dat zo? Waarom werk je niet vanaf een fysieke installatie met de schijf, zoals een live omgeving of installatie op een 16 GB stick?

[Mijzelf]

Ik neem aan dat de array nog geassembleerd is?

mdadm --stop /dev/md124
mount /dev/sdb3 [...]

Verder denk ik dat je dieper liggende probleem in de metadata ligt. Alleen je nieuwe array heeft versie 1.2, de rest heeft 1.0. Dat betekend dat het filesysteem niet meer op de goede plek ligt. Superblok info.

[Uittenbogaard]

Omdat ik anders elke keer moest wisselen tussen een stick en deze windows bak. Maakt toch niet veel uit?

mount /dev/sdc3 geeft:

code:

mount: unknown filesystem type 'linux_raid_member'

kan ik niet de oude array herbouwen adhv de info uit de andere arrays?

[ Voor 15% gewijzigd door Uittenbogaard op 03-12-2017 22:16 ]

[Mijzelf]

Uittenbogaard schreef op zondag 3 december 2017 @ 22:15:
kan ik niet de oude array herbouwen adhv de info uit de andere arrays?

Misschien. Als die NAS alle raid arrays met dezelfde parameters maakte wel. Maar wat schiet je er mee op? Een raid1 array is niet zo spannend. Je hebt een blok sectoren met ervoor of erachter een header. Bij je huidige header zit de hij op begin+4k. De andere arrays hebben de header aan het einde. Oftewel, voor de andere arrays is het begin van de array gelijk aan het begin van de partitie. Het begin van de partitie heb je al.
Opnieuw creëren van de header heeft alleen zin als het filesysteem niet kan mounten omdat de lengte van het blockdevice niet klopt.

mount /dev/sdc3 geeft:

code:

mount: unknown filesystem type 'linux_raid_member'

Filesysteem forceren. (-t ext3)

[Uittenbogaard]

Oei die had ik natuurlijk zelf kunnen verzinnen..

Zelfde probleem als vóór het maken van de nieuwe array:

code:

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

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
root@max-VirtualBox:~# dmesg | tail -1
[ 2347.547179] EXT4-fs (sdc3): VFS: Can't find ext4 filesystem

Komt dit niet omdat de ext4 partitie in de LVM volume group zit, m.a.w. ik zou de volume group moeten mounten?

[Mijzelf]

Uittenbogaard schreef op maandag 4 december 2017 @ 11:03:
Komt dit niet omdat de ext4 partitie in de LVM volume group zit, m.a.w. ik zou de volume group moeten mounten?

Ja, zonder meer. Ik had die andere thread gelezen waar blkid zonder meer een loopdevice herkent als ext4. Maar ik zie nu dat dat een Synology is, terwijl jij een Qnap hebt. De truuks zijn dus niet 1 op 1 toe te passen.

Heb je al een vgscan/lvscan geprobeerd? Complicerend is natuurlijk dat [i]als[/a] de array v1.0 was, er nu een stuk data op begin+4k is overschreven. Dat zou zo maar eens midden in de header van de LV container kunnen zijn.

[Uittenbogaard]

een vgscan/lvscan geeft niks terug in ieder geval. Dat laatste was ik al bang voor..

[Mijzelf]

Als je tijd hebt zou je binwalk kunnen proberen. Die is in staat ext filesystemen te herkennen, zoals ik net heb geconstateerd.

$ dd if=/dev/zero of=fileext4 bs=1M count=64
64+0 records in
64+0 records out
67108864 bytes (67 MB, 64 MiB) copied, 0,0366795 s, 1,8 GB/s
$ sudo losetup -o 0x10000 -f fileext4
/dev/loop0
$ sudo mkfs.ext4 /dev/loop0 
mke2fs 1.43.4 (31-Jan-2017)
Discarding device blocks: done                            
Creating filesystem with 65472 1k blocks and 16384 inodes
Filesystem UUID: 7938952d-3b8e-4d52-ad10-702c22c9d0a1
Superblock backups stored on blocks: 
	8193, 24577, 40961, 57345

Allocating group tables: done                            
Writing inode tables: done                            
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

$ binwalk fileext4 

DECIMAL       HEXADECIMAL     DESCRIPTION
--------------------------------------------------------------------------------
65536         0x10000         Linux EXT filesystem, rev 1.0, ext4 filesystem data, UUID=7938952d-3b8e-4d52-ad10-702c22c922c9
8454144       0x810000        Linux EXT filesystem, rev 1.0, ext4 filesystem data, UUID=7938952d-3b8e-4d52-ad10-702c22c922c9
25231360      0x1810000       Linux EXT filesystem, rev 1.0, ext4 filesystem data, UUID=7938952d-3b8e-4d52-ad10-702c22c922c9
42008576      0x2810000       Linux EXT filesystem, rev 1.0, ext4 filesystem data, UUID=7938952d-3b8e-4d52-ad10-702c22c922c9
58785792      0x3810000       Linux EXT filesystem, rev 1.0, ext4 filesystem data, UUID=7938952d-3b8e-4d52-ad10-702c22c922c9

Je ziet dat binwalk in staat is om een ext filesysteem op een 'willekeurige' offset te herkennen (wat best bijzonder is. Als je met een hexeditor op die offset kijkt zijn er alleen nullen). Waarom de UUID anders is dan mkfs.ext4 specificeert weet ik niet.
De eerste offset die binwalk geeft zou je aan losetup mee kunnen geven, en zien of je de loopdevice dan kunt mounten.
Dit gaat *veel* tijd kosten, en *veel* data opleveren (binwalk gaat ook de files op de partitie herkennen). Dus waarschijnlijk kun je maar beter filteren:

sudo binwalk /dev/sdb3 | grep filesystem

Of de documentatie van binwalk lezen of je ook aan de bron kunt filteren.

[Thralas]

Mijzelf schreef op maandag 4 december 2017 @ 11:36:
Heb je al een vgscan/lvscan geprobeerd? Complicerend is natuurlijk dat [i]als[/a] de array v1.0 was, er nu een stuk data op begin+4k is overschreven. Dat zou zo maar eens midden in de header van de LV container kunnen zijn.

Ja, al je Googlet vind je output van een andere Qnap-gebruiker.

De oude RAID metadata was inderdaad 1.0. Dus de data begon gewoon op sector 0. En niet alleen de 1.2 superblock staat daar nu overheen, er is ook nog een write intent bitmap en bad block log die daarop volgt. Oeps.

In het beste geval heeft @Uittenbogaard alleen wat LVM metadata overschreven. Daar komt je waarschijnlijk wel mee weg, want de simpelste LV is gewoon lineair.

Wat voor filesystem zoeken we? ext3/4? Als je met de methode van hierboven een superblock vindt heb je in ieder geval een beginnetje, maar dat is waarschijnlijk niet het eerste superblock.

Je kunt nog met strings de eerste paar megabyte van je disk controleren op LVM metadata. Iets als:

dd if=/dev/sdb3 bs=1M count=10 | strings | grep -A 1 stripe

Als je daar een hit op hebt dan is de LV metadata nog (deels) intact en kun je berekenen waar je filesystem staat/stond.

Overigens zie ik in de gelinkte thread ook een VG met meerdere LVs, waaronder eentje van 20GB. Als die vooraan staat dan is dat vast de OS disk en is er niets aan het handje als je die overschrijft, je moet alleen de data LV dan even vinden.

Ik zou overigens ipv. binwalk als last resort gebruiken en eerst met TestDisk op superblocks scannen, anders ben je volgende week nog bezig

EDIT: Concreter

1. Check voor LVM metadata zoals hierboven beschreven
2. Werkt dat niet? Dan een superblock scan met TestDisk.

[ Voor 4% gewijzigd door Thralas op 04-12-2017 19:58 ]

[Uittenbogaard]

Thanks voor jullie input, super. Ik ga z.s.m. bezig met de door jullie geboden mogelijkheden..


We zijn in ieder geval op zoek naar een ext4 partitie. De schijf bevat nog een paar andere partities die gewoon direct mounten (in ieder geval 2), waar inderdaad het OS op staat.

[thunder7]

Als je deze schijf per se terug wil, en je je geen verdere vergissingen kan veroorlovan, koop dan een 2e schijf en maak eerst een backup (sector voor sector, dus

dd if=/dev/originele_schijf of=/dev/nieuwe_schijf

) zodat je iets hebt om op terug te vallen als je een nog een probleempje tegenkomt.

[vso]

idd ervaring leert, kopieer de data naar een andere HD

ps wist je dat synology ook een rescue pagina heeft
https://www.synology.com/...my_DiskStation_using_a_PC