Dotaz: Zachrana dat z RAID1 disku (odesel NAS server)

[Costra]

Zdravim,

odesel mi domaci NAS Patriot Valkyrie, kde jsem mel dva disky v RAID1, zformatovane s ext3.

Koumam, jak disk primountovat, abych z neho mohl stahnout data, ale nedari se.

Par vypisu mych pokusu:

# disktype /dev/sdb                                                                                    ~
--- /dev/sdb
Block device, size 1.819 TiB (2000398934016 bytes)
DOS/MBR partition map
Partition 2: 125.5 MiB (131604480 bytes, 257040 sectors from 7614810)
  Type 0x83 (Linux)
  Ext2 file system
    UUID EB984F69-2F2B-42AA-A30E-40363D57CB34 (DCE, v4)
    Volume size 125.5 MiB (131604480 bytes, 128520 blocks of 1 KiB)
Partition 3: 1.816 TiB (1996365934080 bytes, 3899152215 sectors from 7871850)
  Type 0x83 (Linux)
  Ext3 file system
    UUID 581C5B39-DC69-4037-8FE5-DBA5A63D32E6 (DCE, v4)
    Volume size 1.816 TiB (1996365824000 bytes, 487394000 blocks of 4 KiB)
  Linux RAID disk, version 0.90.1
    RAID1 set using 2 regular 0 spare disks
    RAID set UUID 7DEAC3DA-B350-C634-DA6E-228695D568CA (MS GUID)
Linux swap, version 2, subversion 1, 4 KiB pages, little-endian
  Swap size 2.000 GiB (2147467264 bytes, 524284 pages of 4 KiB)

# fdisk -l

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
hlav: 255, sektorů na stopu: 63, cylindrů: 30 400, celkem 488 378 646 sektorů
Jednotky = sektory po 1 * 4096 = 4 096 bajtech
Velikost sektoru (logického/fyzického): 4096 bajtů / 4096 bajtů
Velikost I/O (minimální/optimální): 4096 bajtů / 4096 bajtů
Identifikátor disku: 0x00000000

Zařízení Zavádět   Začátek       Konec    Bloky    Id  Systém
/dev/sdb1               0     7614809    30459240   82  Linux swap/Solaris
/dev/sdb2         7614810     7871849     1028160   83  Linux
/dev/sdb3         7871850  3907024064  2711706972   83  Linux
Pozor: velikost sektoru je 4096 (nikoliv 512)

Disk /dev/sdb1: 31.2 GB, 31190261760 bytes
hlav: 255, sektorů na stopu: 63, cylindrů: 474, celkem 7 614 810 sektorů
Jednotky = sektory po 1 * 4096 = 4 096 bajtech
Velikost sektoru (logického/fyzického): 4096 bajtů / 4096 bajtů
Velikost I/O (minimální/optimální): 4096 bajtů / 4096 bajtů
Identifikátor disku: 0x00000000

Zařízení Zavádět   Začátek       Konec    Bloky    Id  Systém
/dev/sdb1p1               0     7614809    30459240   82  Linux swap/Solaris
/dev/sdb1p2         7614810     7871849     1028160   83  Linux
/dev/sdb1p3         7871850  3907024064  2711706972   83  Linux

# mdadm --examine --scan /dev/sdb3
(nevrati nic)

# mdadm --assemble --no-degraded --force /dev/md0 /dev/sdb2                                            ~
mdadm: no recogniseable superblock on /dev/sdb2
mdadm: /dev/sdb2 has no superblock - assembly aborted

# vgchange -a y                                                                                        ~
  No volume groups found

---

---

Odpovědi

[Milan Roubal]

mount -o ro /dev/sdb3 /mnt

[Costra]

diky za tip, ale bohuzel:

# mount -o ro /dev/sdb3 /mnt
mount: musíte zadat typ systému souborů

# mount -o ro /dev/sdb3 -t ext3 /mnt
mount: chybný typ SS, chybný přepínač, chybný superblok na /dev/sdb3,
       chybí kódová stránka nebo pomocný program nebo jiná chyba
       V jistých případech lze najít potřebné informace v systémovém
       protokolu – zkuste například „dmesg | tail“

# dmesg |tail
[19128.355323] EXT2-fs (sdb3): error: can't find an ext2 filesystem on dev sdb3.
[19128.407290] EXT4-fs (sdb3): VFS: Can't find ext4 filesystem
[19128.486623] mount: sending ioctl 5310 to a partition!
[19128.486633] mount: sending ioctl 5310 to a partition!
[19128.487916] hfs: unable to find HFS+ superblock
[19136.892125] EXT3-fs (sdb3): error: can't find ext3 filesystem on dev sdb3.

[Milan Roubal]

zkus poslat vypisy

parted -l

kompletni

dmesg

aby byla videt kompletni detekce toho disku vcetne partition. Normalne ma oddil se software raidem typ fd.

[Costra]

# dmesg
[20846.112999] usb 2-1.2: new high speed USB device number 4 using ehci_hcd
[20846.385268] usbcore: registered new interface driver uas
[20846.403490] Initializing USB Mass Storage driver...
[20846.404080] scsi2 : usb-storage 2-1.2:1.0
[20846.404479] usbcore: registered new interface driver usb-storage
[20846.404487] USB Mass Storage support registered.

# parted -l
Chyba: Neplatná tabulka oddílů - rekurzivní oddíl na /dev/sdb.            
Ignorovat/Ignore/Zrušit/Cancel? Ignore                                    
Chyba: Nemohu mít oddíl mimo disk!  

[Milan Roubal]

no vypada to ze ta partition tabulka dostala docela zabrat a pravdepodobne obsahuje docela dost nesmyslu. Zkus na ten disk spustit testdisk, ten by mel ukazat skutecnou pozici toho ext3 oddilu.

[Costra]

# testdisk
Disk /dev/sdb - 2000 GB / 1863 GiB - CHS 30400 255 63
Current partition structure:
     Partition                  Start        End    Size in sectors

 1 P Linux Swap               0   0  1   473 254 63    7614810
No EXT2, JFS, Reiser, cramfs or XFS marker
 2 P Linux                  474   0  1   489 254 63     257040
 2 P Linux                  474   0  1   489 254 63     257040
No EXT2, JFS, Reiser, cramfs or XFS marker
 3 P Linux                  490   0  1 243200 254 63 3899152215
 3 P Linux                  490   0  1 243200 254 63 3899152215
No partition is bootable

[Milan Roubal]

tak nejprve bych zazalohoval partition tabulku

dd if=/dev/sdb of=part_table_backup bs=4096 count=1

a pak

fdisk /dev/sdb

smazat oddil 3 a vytvorit ho znova na celou zbyvajici velikost disku.

Pro znovunacteni tabulky disku muze byt potreba restart, on uz si system rekne. Pak vyzkousej znovu

mount -o ro /dev/sdb3 /mnt

a

mdadm --examine /dev/sdb3

[pavlix]

tak nejprve bych zazalohoval partition tabulku

dd if=/dev/sdb of=part_table_backup bs=4096 count=1

Podle čeho dáváš tu velikost čtyři kilobajty?

[Milan Roubal]

velikost jednoho sektoru na disku. Teoreticky by melo stacit zalohovat tech konkretnich 64 bajtu. Je pravda, ze predpokladam MBR a nikoliv GPT. Zadny disk s GPT jsem jeste v ruce nedrzel, takze ani netusim, jak by tam ta partition tabulka vypadala.

[pavlix]

velikost jednoho sektoru na disku.

\

Ale odkud tu informaci o velikosti jednoho sektoru na disku rovného 4kB bereš?

Teoreticky by melo stacit zalohovat tech konkretnich 64 bajtu.

Tak já v takovýchto případech obvykle zálohuju MBR.

Zadny disk s GPT jsem jeste v ruce nedrzel, takze ani netusim, jak by tam ta partition tabulka vypadala.

Tak v takovém případě bych zálohoval buď celou (mnohem větší) oblast, nebo použil nástroj pro export a import té tabulky.

[Milan Roubal]

Ale odkud tu informaci o velikosti jednoho sektoru na disku rovného 4kB bereš?

V prvnim prispevku je napsano:

Velikost sektoru (logického/fyzického): 4096 bajtů / 4096 bajtů

Pro moji informaci, jak jednoduse z vypisu prikazu

fdisk -l

poznat, ze se jedna o GPT? Jak by takovy vypis vypadal?

[lertimir]

jste si jist, že informace které získáte programem testdisk můžete spolehlivě použít pro opravu partition table na takovémto disku?? A jak?

Moje námitky (nebo spíše podezření jsou díky tomu, že ve výpisu, který poslal tazetel na Váš podnět je.

1. Počítání sektorů v Cylinder-head-size formátů, které nevím jak moc jsou příslušné
2. Když se podíváte na čísla, která se tam objevují (součet sektorů je cca 4*10^9) tak jasně jsou to počty sektorů pro velikost sektor 512b a ne pro velikost sektoru 4096b

Jaké informace zapsat do partition table?

[Milan Roubal]

jste si jist, že informace které získáte programem testdisk můžete spolehlivě použít pro opravu partition table na takovémto disku?? A jak?

Moje námitky (nebo spíše podezření jsou díky tomu, že ve výpisu, který poslal tazetel na Váš podnět je.

1. Počítání sektorů v Cylinder-head-size formátů, které nevím jak moc jsou příslušné
2. Když se podíváte na čísla, která se tam objevují (součet sektorů je cca 4*10^9) tak jasně jsou to počty sektorů pro velikost sektor 512b a ne pro velikost sektoru 4096b

Jaké informace zapsat do partition table?

No kdyz se podivas na vypisy disktype, fdisk a testdisk a pouzijes kalkulacku, tak hodnoty pro partition 1 a 2 jsou ve vsech 3 vypisech shodne, ale pro partition 3 ukazuji disktype i testdisk jako konec partition az ke konci disku, zatimco fdisk ukazuje nekam doprostred. Podle meho nazoru je tedy potreba opravit konec treti partition v MBR a podle meho nazoru by pak melo jit tu partition primountovat, pokud nema jeste nejaka dalsi poskozeni.

[Milan Roubal]

Velikost posledni partition ve vypisu fdisk by mela byt podle moji kalkulacky start 7871850 end 3907024064 size blocks 15596608860

Tedy velikosti partition v Bytech 3898782720 + 131604480 + 1996365934080 = 2000396321280 z celkove kapacity 2000398934016

Mam nekde ve vypoctech chybu?

[Milan Roubal]

A kdyz jsme uz u toho pocitani, tak mi pripada tedy ta velikost tech partition dost vymluvna. Muj domaci NAS ma tedy na prvnim miste linuxovou partisnu velikosti par GB, pak nasleduje maly SWAP ve velikosti stovek MB a pak zbytek disku datovy oddil. Pripada mi to, jako by bylo oznaceni tech partition obracene - ze /dev/sdb1 je typ 83 linux a /dev/sdb2 je typ 82, tedy swap. Neda se tedy ta vec primountovat?

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

[pavlix]

V prvnim prispevku je napsano:

Díky za odpověď. Mě to jen překvapilo, protože když chci zálohovat MBR, zálohuju 512.

poznat, ze se jedna o GPT? Jak by takovy vypis vypadal?

GPT obsahuje MBR, ze kterého lze GPT poznat. Věřím, že i přes linuxový fdisk.

[Costra]

bohuzel nezabralo

# fdisk /dev/sdb
Pozor: velikost sektoru je 4096 (nikoliv 512)

Příkaz (m pro nápovědu): p

Disk /dev/sdb: 2000.4 GB, 2000398934016 bytes
hlav: 255, sektorů na stopu: 63, cylindrů: 30 400, celkem 488 378 646 sektorů
Jednotky = sektory po 1 * 4096 = 4 096 bajtech
Velikost sektoru (logického/fyzického): 4096 bajtů / 4096 bajtů
Velikost I/O (minimální/optimální): 4096 bajtů / 4096 bajtů
Identifikátor disku: 0x00000000

Zařízení Zavádět   Začátek       Konec    Bloky    Id  Systém
/dev/sdb1               0     7614809    30459240   82  Linux swap/Solaris
/dev/sdb2         7614810     7871849     1028160   83  Linux
/dev/sdb3         7871850   488378645  1922027184   83  Linux


mount: chybný typ SS, chybný přepínač, chybný superblok na /dev/sdb3,

# dmesg

[27540.544261] EXT3-fs (sdb3): error: can't find ext3 filesystem on dev sdb3.
[27540.601731] EXT2-fs (sdb3): error: can't find an ext2 filesystem on dev sdb3.
[27540.653574] EXT4-fs (sdb3): VFS: Can't find ext4 filesystem
[27540.776933] mount: sending ioctl 5310 to a partition!
[27540.776942] mount: sending ioctl 5310 to a partition!
[27540.778251] hfs: unable to find HFS+ superblock
[27540.805464] FAT-fs (sdb3): bogus number of reserved sectors
[27540.805475] FAT-fs (sdb3): Can't find a valid FAT filesystem

[lertimir]

Jen pár nápadů. Pokud jste poslal skutečně úplné výpisy tak je tam pár problémů:

1. Choval bych se nesmírně opatrně a připojoval bych ho když tak až za běhu systému. Hlavně bych se bál nekonzistence v /dev/sdb1 hodnota "bloky" je mnohem více než je rozdíl mezi začátek a konec takže možná je něco s partition table. A vzhledem k tomu že je to swap tak by mě to mohlo přepisovat další kusy disku když to systém opravdu vezme jako swap.
2. Také disktype neuvádí swap jako samostatnou partition
3. vypadá to, že sdb2 bude systém, zkusil bych ho napřímo mountnout a zkusit najít na něm konfigurace.
4. sdb3vypadá jako ten vlastní raid takže ten bych zkusil připojovat a assemblovat

[Costra]

dekuji za tipy, bohuzel nelze primountovat ani sdb2 ani sdb3, vice viz ma predchazejici odpoved kolegovi. :(

[dustin]

V úvodním dotazu píšeš:

# mdadm --examine --scan /dev/sdb3
(nevrati nic)

To mi taky nic nepíše. Ale když odstraním to --scan, které hledá disky dle mdadm.conf, pak mi zahlásí

root@sara:~# mdadm --examine  /dev/sda1
mdadm: No md superblock detected on /dev/sda1.

IMO tam to --scan být nemá, pokud chceš prohlížet sdb3.

Dále z výpisu disktype je vidět, že součástí raidu je sdb3, ale do raidu se snažíš natlačit sdb2, které samozřejmě žádný superblock nemá.

mdadm --assemble --no-degraded --force /dev/md0 /dev/sdb2                                            ~
mdadm: no recogniseable superblock on /dev/sdb2
mdadm: /dev/sdb2 has no superblock - assembly aborted

[Costra]

píšeme mi to totéž na sdb3 i sdb2

[lertimir]

ve výpisech o sdb2 není ani slovo. je to jen o sdb3

[Lukas]

Já jsem se taky jednou pokoušel dostat data z RAID ale spíš sem to zhoršil. Zkus Datarecovery pokud tam máš opravdu choulostivá data a nechceš o ně přijít

[Bluebear]

IMO nemá smysl používat assemble, jestliže jsou to RAID1.

Jestliže je to RAID1 a aspoň jeden disk je v pořádku, tak ten disk, který neselhal, by měl obsahovat správnou kopii. Mělo by stačit namountovat.

Pokud shnily oba, tak jsou oba narušené a assemble nemá na čem pracovat; pak nabídnout modlitbu tvému bohu a pokusit se čarovat s využitím toho, že na discích byla původně identická data (asi bych začal dd_rescue a vytvořil obrazy obou disků, ale nevím přesně, jak je dát dohromady)

[Max]

RAID1 normálně připojíš jako klasický fs jen v případě starších verzí metadat. Pokud vytvořil pole s metadaty 1.1 nebo 1.2, tak to tak lehce připojit nepůjde
Důvod je jednoduchý, u novějších verzí metadat jsou metadata umístěny na začátku partition, nikoli na konci jako u starších verzí. Tím pádem mount neprojde.
Zdar Max

[lertimir]

tedy interní strukturu RAIDu jsem nestudoval, ale někde musí být informace o tom že to je raid a že uvnitř toho raidu je nějaký fielsystém Tedy že raíd je jako by kontejner a filesystém je až uvnitř něj. mdadm také pozná, že oddíl je raid v miroru a ne přímý filesystém a někde to musí mít v oddíle zapsáno. Takže o přímém přimountování bych trochu pochyboval.

[Max]

Metadata verze 0.90 a 1.0 mají data na konci oddílu, mount tedy projde v klidu (a je doporučován ro mount, protože by rw mount mohl poškodit metadata a bylo by po poli). Metadata 1.1 a 1.2 jsou na začátku a je problém.
Zdar Max

[dustin]

Je to přesně tak.

[vasek]

Nešel by při mountu použít offset v případě metadat 1.1? U 1.2 to už asi nepůjde, ale u 1.1 by to mohlo projít.

[Brumla01]

Nedavno jsem resil neco podobneho na debianu a pomohlo mi vytvorit nove pole s funkcnim diskem a parametrem missing pro druhy. Pole slo nasledne normalne pripojit.

[dustin]

+1

[Pedro]

taky +1, je treba to sestavit s MISSING v degradovanem modu, jinak to nepripojis, navesti linux autoraid te nepusti na klasicky mount....

[blb]

Nez zacnete cokoli delat:

- doporucuji zkopirovat obsah celeho disku nekam jinam a pokusy delat na teto kopii.

- poskozeny disk zapinejte jen minimalne

- pokud muzete, kupte stejny disk a vykopirujte ten spatnej na tento novy disk

- na novem disku pak muzete delat pokusy.Treba diskutujicimi zminovany testdisk pomaha velmi casto.

Zajimave je, ze pokud to byl softwarovy RAID1 (jen ma domnenka), tak ten fdisk vam to o nem nem nepise. Namisto "83 Linux" by melo byt "fd Linux raid autodetect". Na samotny obsah svazku to samozrejme vliv nema, ale myslim, ze je to duvod proc vam ten disk kernel neslozi.

Pokud znate puvodni layout disku (napr. mate k dispozici starsi logy bootu, kde by to mohlo byt), zkuste porovnat co je tam vs. to co pise fdisk. Pokud je fdisk jiny oproti ocekavani, muzete zkusit rekonstruovat patition table. Je vsak na zvazenou kolik a jaka data na tom poli byla a podle toho zvolit uroven zachrany.

[Milan Roubal]

Nez zacnete cokoli delat:

- doporucuji zkopirovat obsah celeho disku nekam jinam a pokusy delat na teto kopii.

plne souhlasim. V tomto pripade, kdy data jsou diky RAID1 na dvou discich, lze akceptovat pokusy na jednom z nich, nebot data jeste existuji na tom druhem

- poskozeny disk zapinejte jen minimalne

opet souhlasim, ale zde byl poskozeny NAS stroj a nikoliv disk.

- pokud muzete, kupte stejny disk a vykopirujte ten spatnej na tento novy disk

podle popisu problemu neni chybny disk, jinak opet plny souhlas.

- na novem disku pak muzete delat pokusy.Treba diskutujicimi zminovany testdisk pomaha velmi casto.

Zajimave je, ze pokud to byl softwarovy RAID1 (jen ma domnenka), tak ten fdisk vam to o nem nem nepise. Namisto "83 Linux" by melo byt "fd Linux raid autodetect". Na samotny obsah svazku to samozrejme vliv nema, ale myslim, ze je to duvod proc vam ten disk kernel neslozi.

Pokud znate puvodni layout disku (napr. mate k dispozici starsi logy bootu, kde by to mohlo byt), zkuste porovnat co je tam vs. to co pise fdisk. Pokud je fdisk jiny oproti ocekavani, muzete zkusit rekonstruovat patition table. Je vsak na zvazenou kolik a jaka data na tom poli byla a podle toho zvolit uroven zachrany.

no diky tomu, ze ten NAS server odesel, tak asi nebudou ani logy (mozna budou, ale nekde na tom disku, pravdepodobne na te druhe partition). Nejvice zarazejici na tomto rozdeleni disku v tomto NAS serveru je ta SWAP partition zacinajici na sektoru 0. To jsem jeste nikdy nevidel a pripada mi to jako ruska ruleta, kdy se ceka na zapis, ktery prepise tabulku oddilu. Ten zapis muze prijit za minutu a taky nikdy.

[mr.key]

skus este disk preskenovat programom r-studio

[Costra]

http://www.r-studio.com/

necelých $80 mě už zachránilo prdel u nejednoho "solo" disku, nebo disku v RAIDu...

a hlavně nedělej další blbosti jak ti tu píší!!!

pravidlo první, když se mi posere disk, tak jej okamžitě odpojím (fyzicky odeberu), připojím k dokovací stanici a udělám image 1:1, pak jej vypnu a dál si "hraju" jen s image.

Tu připojím, pustím na ní R-Studio a nastavím příslušné parametry. Víc neřeším, vysaje mi všechno co tam nalezne a někdy i něco na víc z historie

[JMP]

pro extra paranoidni je lepsi hrat si s kopii toho image, at je k cemu se vracet , jinak souhlas...