Raid 1 data terug halen

[esak]

Hallo allemaal, ik heb een vervelend probleem: Ik kan mijn data die ik opgeslagen heb in een raid 1 array niet bemachtigen...

De situatie is wat ingewikkeld maar ik zal het toch goed proberen uit te leggen.
Wij hebben thuis een NAS (Qnap 219p+) en daar heb ik ingesteld om een raid 1 volume te maken met 2 disk's. Dit heeft altijd goed gewerkt. Maar door bepaalde redenen moest ik tijdelijk een van de twee schijven leeg maken om zo een NAS herstel te doen. Ik dacht slim te zijn om eerst nog een dubbele check te doen door een van de twee schijven aan te sluiten op een computer door alle data over te kopiëren naar een 3e schijf voor als er iets mis gaat bij het mirroren van de twee schijven als ik alles weer heb ingesteld. Maar toen ik een schijf uit de NAS trok en de NAS daarna weer aanzetten bleek dat de volledige configuratie weg was dus hij wist niet meer dat die twee schijven een raid 1 opstelling zijn.
Ik denk "Ach maakt niet uit, ik sluit zo een schijf wel even aan op een computer, kopieer de bestanden en kan alles gewoon opnieuw instellen". Maar nu blijkt dat ik beide schijven niet zo maar aan de computer kan aansluiten omdat ze een raid 1 partitie hebben en die blijkt niet te mounten in ubuntu als je slechts 1 schijf aangesloten hebt.

Dus in het kort:
- Ik heb twee schijven in raid 1 configuratie
- Op de NAS is de raid 1 configuratie weg en kan ik die ook niet in de web interface herstellen.
- Een van de twee schijven aangesloten op een computer blijkt niet te kunnen worden gemount.

Wat ik al geprobeerd heb:
- In ubuntu gewoon proberen een schijf te mounten (blijkt niet te kunnen)
- Een gparted live cd restart maar ook daar blijk ik het niet te kunnen mounten. Wel geeft hij aan dat 700/1000 GB in gebruik is wat gewoon klopt.
- als ik beide schijven weer in de NAS gooi zit er nog wel een Raid 1 configuratie maar die staat als "non active" aangeschreven met daar onder een herstel knop maar als ik daar op druk gebeurd er gewoon niets.

Wat ik nog zou kunnen proberen is om beide schijven weer in de NAS te hangen, 1 schijf volledig te formatteren en dan kijken of hij zich goed kan mirroren. Dit doe ik liever niet want als het niet werkt heb ik een grotere kans dat ik nooit meer bij mijn data kom.

Heeft iemand enig idee hoe ik dit rommeltje kan herstellen? In principe is er geen data verloren gegaan maar kan ik het gewoon niet mounten. Er zit een hoop belangrijke data op (heb niet voor niets raid 1 gekozen)...

[sl1000]

als je teamviewer installeert, en mij de toegangsgevens stuurt via dm, wil ik wel even met je meekijken en de boel herstellen. Ik ken de Qnaps van binnen en van buiten...

[sl1000]

hmmm dit ziet er absoluut niet goed uit. De topicstarter geeft aan dat hij het systeem meerdere keren heeft gereboot met 1 of meerdere drives, en daarbij ook de drives heeft gewisseld van volgorde in de slots. Dit in een poging zijn vermiste data terug te vinden. De hierna ontstane situatie is config technisch in de QNAP door mij wel te herstellen, maar de raidset is zo beschadigt dat ik even niet meer weet hoe het beste verder te gaan.

Zijn hier wat mdadm guru's die met me mee willen denken?

QNAP's raidset is een doodgewone mdadm raid config, zonder spannende lvm dingen enzo.
QNAP hakt een drive altijd in 4 stukken en de 3e partitie wordt al dan niet in raid voor user data gebruikt.
zodra deze layout niet gevonden wordt op een drive, dan wordt een ingestoken drive automatisch opnieuw gepartitioneerd in de juiste layout.

onderstaande een fdisk -lu van beide drives:

code:

~] # fdisk -lu /dev/sda /dev/sdb

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *          63     1060289      530113+  83  Linux
/dev/sda2         1060290     2120579      530145   82  Linux swap / Solaris
/dev/sda3         2120580  1952507969   975193695   83  Linux
/dev/sda4      1952507970  1953503999      498015   83  Linux

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1              40     1060289      530125   83  Linux
/dev/sdb2         1060296     2120579      530142   83  Linux
/dev/sdb3         2120584  1952507969   975193693   83  Linux
/dev/sdb4      1952507976  1953503999      498012   83  Linux

Om 4k sector drives beter te supporten heeft men een tijd terug de layout aangepast, waarbij de partities aligned zijn op 4k boundries. Dit zie je ook aan drive sdb, deze heeft een nieuwe layout, terwijl de 1e nog een oude heeft. Voor mij een indicatie dat de nas de 2e drive opnieuw heeft partitioneerd, omdat de oude partitie ongeldig was.

Een mdadm --examine bevestigd dit vermoeden, er staat geen raidconfig op.

code:

[~] # mdadm --examine /dev/sdb3                                                
mdadm: No md superblock detected on /dev/sdb3.

Normaliter geen probleem, we assemblen /dev/md0 met de partitie /dev/sda3, en van daaruit kunnen we de data recoveren, of remirroren naar /dev/sb3. een examine van /dev/sda3 laat echter zien dat deze geen healty raidconfig heeft, en wordt gezien als spare. zie onder:

code:

[~] # mdadm --examine /dev/sda3
/dev/sda3:
          Magic : a92b4efc
        Version : 00.90.00
           UUID : 4fef8842:c1353c99:4b1c583b:392b3f76
  Creation Time : Wed May 19 20:34:47 2010
     Raid Level : raid1
  Used Dev Size : 975193600 (930.02 GiB 998.60 GB)
     Array Size : 975193600 (930.02 GiB 998.60 GB)
   Raid Devices : 2
  Total Devices : 2
Preferred Minor : 0

    Update Time : Sat Sep 10 16:24:01 2011
          State : active
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1
       Checksum : 131795d7 - correct
         Events : 0.344


      Number   Major   Minor   RaidDevice State
this     2       8        3        2      spare   /dev/sda3

   0     0       0        0        0      removed
   1     1       8       19        1      active sync   /dev/sdb3
   2     2       8        3        2      spare   /dev/sda3

Een (forced) assemble van de raidset wordt dan ook geweigerd, het is geen suitable drive om een raidset mee te starten. Logisch... waarschijnlijk is de drive halverwege een rebuild losgetrokken, of de nas gereboot of i.d.

Nu zit ik dus met de puzzel: Hoe hier nog data af te halen?
a. raidconfig wipen van /dev/sda3 en een nieuwe wegschrijven. Daarna hopen dat ik het filesystem kan mounten. (kleine kans)
b. Niets doen en de topicstarter de drive met iets van testdisk of een andere recovery tool proberen te behandelen en zo (wat) data proberen te recoveren
c. Handmatig de oude partitielayout van de /dev/sdb drive proberen te herstellen en dan daar de 3e partitie van proberen te assemblen en te mounten (heel weinig kans dat dit werkt, daar de 1e 2 partities onderdeel van raid 1 systeem partities zijn, en daarom ook daadwerkelijk informatie hebben overschreven.

Een bijkomend "probleem" is dat de smart informatie van /dev/sda3 laat zien dat er toch wel wat dingen ernstig mis aan het gaan zijn met deze drive. (verklaard w.s. ook waarom de drive als "spare" stond aangemerkt?)
zie bv de Current_Pending_Sector waarde, en de Offline_Uncorrectable, en Multi_Zone_Error_Rate waarden.

code:

1   Raw_Read_Error_Rate 200 200 051 426 OK
3   Spin_Up_Time    135 132 021 6250    OK
4   Start_Stop_Count    096 096 000 4250    OK
5   Reallocated_Sector_Ct   200 200 140 0   OK
7   Seek_Error_Rate 200 200 000 0   OK
9   Power_On_Hours  086 086 000 10402   OK
10  Spin_Retry_Count    100 100 000 0   OK
11  Calibration_Retry_Count 100 253 000 0   OK
12  Power_Cycle_Count   100 100 000 27  OK
192 Power-Off_Retract_Count 200 200 000 23  OK
193 Load_Cycle_Count    180 180 000 60750   OK
194 Temperature_Celsius 110 103 000 37  OK
196 Reallocated_Event_Count 200 200 000 0   OK
197 Current_Pending_Sector  200 200 000 14  OK
198 Offline_Uncorrectable   200 200 000 7   OK
199 UDMA_CRC_Error_Count    200 200 000 0   OK
200 Multi_Zone_Error_Rate   200 200 000 9   OK

Een smart test vanuit de NAS mislukt, maar dat kan zijn omdat de config zo vernaggelt is momenteel.
Ik heb zelf weinig hoop meer, en ben bang dat het uithuilen en overnieuw beginnen wordt.
Toch hoor ik graag nog tips om eventueel data van de schijf te halen, of de partitie te herstellen.

[KnoxNL]

Misschien is het handiger even terug te vallen op de backup. Ik weet natuurlijk niet wat TS doet en hoe belangrijk de data is, maar veel kun je dan niet missen toch?

[sl1000]

Hij heeft geen back-up...

[KnoxNL]

sl1000 schreef op zondag 11 september 2011 @ 01:54:
Hij heeft geen back-up...

Ah...

In dat geval succes. Wel mooi om te zien dat tweakers elkaar zo helpen.
Ik kan je verder helaas niet van advies voorzien en aan je post te zien weet je waar je het over hebt.
En ik wbt Qnaps wat mimder

@ TS het spijt me zeer maar Raid 1 is ge.. ...... Suc6!

[Jormungandr]

Beste kans gaat imo de recovery software zijn. De kans dat je met MDADM gefoeter nog verder van huis geraakt is reëel.

[Skinkie]

Jormungandr schreef op zondag 11 september 2011 @ 02:08:
Beste kans gaat imo de recovery software zijn. De kans dat je met MDADM gefoeter nog verder van huis geraakt is reëel.

dd'tje doen naar disk van 2TB, even even gaan klooien.

Kan me overigens absoluut niet voorstellen dat die mdadm parameter zo ingewikkeld zijn dat ze niet geprobed kunnen worden. Het is per slot van rekening een embedded apparaat...

[Erik Jan]

Het mdadm superblock (versie 0.90 i.i.g.) staat aan het einde van de partitie, dus met raid1 kan je die gewoon overslaan en de partitie (readonly) mounten, alsof er niets aan de hand is:

code:

mount -o ro -t ext2 /dev/sda3 /tmp/mountpoint

Wel moet je dus even expliciet het fs type opgeven, om een mdraid autodetect mechanisme (als extra beveiliging) te omzeilen.

Mijn gok gaat uit naar sda, het lijkt er inderdaad op alsof sdb een onvrijwillige rebuild heeft ondergaan.

Bovenstaande is redelijk risicoloos, maar een dd'tje zoals Skinkie voorstelt, kan natuurlijk nooit kwaad.

[sl1000]

@erik Jan: dank! Dat heb ik me nooit gerealiseerd, als TS op mijn DM reageert zal ik even kijken.
Verder heb ik na een nacht slaap nog een slim idee gekregen, om misschien toch nog data van disk b te kunnen trekken. 'ns kijken of we dit kunnen fixen.

Word vervolgt indien TS dat wil

[RobTweaks]

@Erik Jan: Zo voor de hand liggend en toch zo geniaal! Ik was er niet opgekomen i.i.g.

@sl1000 Klinkt goed, mogen wij meegenieten van het plan?

[ Voor 12% gewijzigd door RobTweaks op 11-09-2011 11:26 ]

[sl1000]

Mijn 2e plan was om /dev/sdb3 realignen en 4 blokjes oprekken naar links. dan klopt de partitie weer exact met de oude partitie. QNAP wiped nooit echt de data, maar schrijft gewoon een nieuwe partitietabel over de oude disk heen. de nieuwe partitie zou daarna weer mountable moeten zijn als het goed was.

Maar gelukkig was deze actie niet eens nodig. Erik Jan's simpele idee werkte prima. TS is nu via WINSCP bezig zijn data van de drive te kopieren. (wel ff ext4 mounten)

Dank voor het meedenken allemaal

[esak]

Inderdaad, ik en nu bezig om alles te backuppen (helaas met ~1000kB/sec over een gigabit netwerk). Morgen zal alles wel klaar zijn en ga ik de NAS helemaal opnieuw instellen (dus ook beide disks).

Echt hartstikke bedankt voor jullie hulp, en speciale dank aan sl1000 die eigenlijk alles voor mij geregeld heeft via teamviewer en ssh.