RAID5 + LVM + e2fsck = Strata dat?

[Michal Balaz]

Ahoj, stala sa nam velmi neprijemna vec. Pocas poslednych zaplav sme mali caste a dlhe vypadky elektrickej energie, pricom UPS sa stihla uplne vybit a teda pri dalsich nabehoch uz trpel aj server.
Poskodil sa nam system a tak som ho len preinstaloval z Debianu na Ubuntu server (konfiguraky k LVM a mdadm som pouzil povodne). Totizto k serveru su pripojene nasledovne polia SYS particie v RAID1, backup pole RAID1, datove pole RAID5+LVM.celkoto teda 7 diskov. Vsetko v pohode okrem toho datoveho pola. RAID5 sa mi podarilo reorganizovat avsak system nevedel identifikovat ze tam bezi aj LVM, neskor sa mi aj toto podarilo vyriesit pomocou /etc/lvm/backup...

Problem s ktorym vsak nemozem pohnut je ze pri snahe o namontovanie particie(LV) hlasili ze mam pouzit e2fsck. Tak ja som samozrejme pouzil e2fsck -y :-( a teraz ked ich uz aj namontujem nic tam nie je... teda nejake data som nasiel v lost+found no nedaju sa pouzit (mimochodom ide hlavne o particiu ktora obsahuje XENsource image) a ani ich nie je tolko ako povodne cca zo 700G v lost+found ostalo asi 60G.

Nevedeli by ste mi prosim poradit z tejto zapeklitej situacie.
Dakujem pekne.

[Reklama]

[PCnity]

Pokial mas raid5 online, si este na velmi dobrej ceste to zachranit.
NEBOOTUJ DO RW!

1) Spusti system z nejakeho systemrescuecd a nasledne pomocou urob image dd= ako zalohy celeho raid5 pola.

Az potom skusaj. e2fsck ti prepisal superblock ale data tam nadalej su. Na SRCD najdes urcite nejake toolsy co by ti mohli pomoct dalej. Inak ma uz napada len ext3 undelete, ale ked si pozries postup, rozmyslis si to

[Michal Balaz]

Vdaka idem to skusit odzalohovat sice su to 2Tdat no hadam to pude. Problem vsak je v tom ze ta raid5 uz niekolko hodin nahebla v RW a stihla sa "akoze" aj recovernut.

Neviem ci sa trochu memylim ale nemam pracovat s LV  v LVM vg teda napr. /dev/vg2/part1 pretoze aj to e2fsck bezalo len na LV nie na cele pole.
aby som to teda upresnil raid5 je jedine PV pre dane poskodene LV.

Este raz vdaka

[BLEK.]

<p>
"RAID5 sa mi podarilo reorganizovat avsak system nevedel identifikovat ze tam bezi aj LVM, neskor sa mi aj toto podarilo vyriesit pomocou /etc/lvm/backup..."
</p>
<p>
Tipoval bych, že jsi ty RAID5 disky poskládal ve špatném pořadí. Teď už s tím nic nenaděláš ta resynchronizace RAID5 a fsck ti zničily data v periodických intervalech, z toho už nic smysluplného nedostaneš. Můžeš to zkusit poskládat jinak, třeba toho zachráníš víc, ale budou na tom chyby též.
</p>
<p>
Pro příště:
<ul>
<li>Když skládáme RAID5 z existujících RAID5 disků (a nefunguje autodetekce), složíme to prvně jako degradované pole --- t.j. dáme tam o disk míň. Když složíme RAID5 jako degradovaný, neproběhne synchronizace parity, čili, pokud to složíme blbě (špatné pořadí disků nebo chunk size), můžeme to ještě rozložit a zkusit poskládat jinak bez ztráty dat. Kdybychom složili úplné RAID5 pole se všemi disky, tak se automaticky resynchronizuje (a v případě špatného složení jsou data v háji).
<li>Když nám pole nerozpozná lvm nebo nejde namountovat, nesnažit se to opravovat, ale jít k předchozímu bodu a složit to jinak.
<li>fsck pouštět nejdřív s parametrem "-n", podívat se, co vlastně chce opravit (v tomto módu zobrazí chyby a nebude nic zapisovat na disk). Když je tam těch chyb moc, jedná se o špatně složené MD pole nebo špatně složené LVM, nic na to nezapisovat a zkusit jiné složení.
</ul>
</p>

[Michal Balaz]

Ahoj,

vdaka moc. Toto ma skutocne nenapadlo, teda viem ze tie disky musia byt v rovnakom poradi... ale vobec ma nenapadlo ze ubuntu mi ich inak nadetekuje a tym dojde k prehadzani.
Napriek tomu ze som na to uz spustil aj e2fsck. tak som ich teda zoradil tak ako si mi poradil. Niektore particie sa rozbehli(tie ktore som nemucil fsck) a niektore(tie ktore som mucil) som musel znovu prebehnut fsck a zda sa ze strata je "len" 4% co je celkom pozitivne kedze prave tie 4% si viem inak nahradit, dolezite data som dokazal obnovil, takze este raz velka vdaka, na toto si uz urcite dam velky pozor.

[Reklama]

[PCnity]

Hlavne ze to dobre dopadlo

[BLEK.]

Ono vlastně, když se ta parita počítá XORem, tak se to přepočítáním parity při špatném pořadí nezničí (leda to spočte XOR dat a parity a zapíše jiná data, o kterých si myslí, že je to parita) ... takže v tomto případě to pokazil jen ten fsck.

Ještě, příště, když se něco takového stane, zkus to poskládat pomocí "mdadm -A", to by si mělo načíst parametry toho pole s těch superbloků na těch discích, takže pak není potřeba uvažovat nad pořadím.

[Michal Balaz]

Presne tak, tam kde fsck neprebehlo stratovost je 0%.
Praveze mdadm --auto-detect nezabral pretoze uz spominane zapinanie a vypinanie poskodil superbloky na vacsine diskov. Tj. nabuduce len skusat poradie a samozrejme na degradovanom poli pretoze ked uz spravne trafim poradie... aj to LVM sa same rozbehne. Ale samozrejme to je incident od incidentu, univerzalny navod sa na to asi ani neda spravit.

[BLEK.]

Jako, že se ta data v superblocích fyzicky poškodila? To snad disky při výpadku proudu nedělají, aspoň ne masově.

Linux RAID-5 má ten problém, že když vypadnou dva disky, tak do těch superbloků zbývajících disků napíše, že pole je rozpadlé, a když člověk připojí všechny disky, tak už to stejně nenaběhne. Podle mě je to bug. Na to právě pomůže mdadm --assemble (nikoli --auto-detect).

Když jsem ještě neměl mdadm a používal raid-tools, tak jsem tento problém se dvěma vypadlými disky řešil editací superbloku ... netroufl jsem si to pole znovu vytvořit právě ze strachu, že kdybych to udělal špatně, tak to zničím.