Přeskočit na obsah
RAID · server · HP ProLiant · Dell PowerEdge · PERC · Smart Array · LSI MegaRAID · VMware · VMFS · RAID 5 · RAID 6 · záchrana dat · enterprise

Záchrana dat ze serveru — obnova RAID, HP ProLiant, Dell PowerEdge

Záchrana dat ze serveru s hardwarovým RAID řadičem: HP Smart Array, Dell PERC, LSI MegaRAID, Foreign Config, selhaný rebuild RAID 5/6 a VMware VMFS.

Miroslav Jaroš ·

Odpověď hned: Pokud váš server HP ProLiant, Dell PowerEdge nebo jiný stroj s hardwarovým RAID řadičem spadl do stavu „Degraded” nebo „Offline”, okamžitě jej vypněte. Nepokoušejte se naslepo importovat „Foreign config” po výměně řadiče, nespouštějte rebuild degradovaného pole a rozhodně neinicializujte nový virtuální disk. Každý pokus o zápis nebo obnovu konfigurace zásadně snižuje šanci na záchranu dat, protože proprietární metadata řadičů jako HP Smart Array nebo Dell PERC se přepisují na milisekundy. Šance na záchranu je při okamžitém odstavení serveru a správném postupu v laboratoři vysoká, i když pole hlásí „Failed” nebo když selže řadič sám. Diagnostika je u nás vždy zdarma a cenu sdělíme předem, takže nic neriskujete.

U serverového RAIDu je zrádné, že administrace často nabízí jednoduchou volbu: importovat konfiguraci, spustit rebuild, vytvořit nový virtuální disk. Jenže ve chvíli, kdy pole už hlásí Degraded, Offline nebo Foreign Config, není jisté, jestli řadič ještě čte původní mapu správně. To, co vypadá jako rutinní servis, se během jednoho potvrzení může změnit v přepsaná metadata a ztracený VMFS datastore.

Záchrana dat ze serverového RAID pole v laboratoři ITHOPE Brno — rackový server, SAS disky v šachtách a RAID řadič mimo server
Enterprise záchrana začíná tím, že se od řadiče úplně odpojíme: každý disk se klonuje zvlášť, sektor po sektoru, a pole se skládá až offline z kopií. Nikdy nepracujeme s originály.

Rychlá orientace podle hlášky na serveru

Když server hlásí Foreign Config, Virtual Drive Offline nebo nedostupný VMware datastore, nejde jen o disky. Řeší se současně řadič, pořadí šachet, RAID metadata a souborový systém virtualizace.

  • Foreign Configuration: neimportovat ani nečistit bez analýzy. Nejprve označit disky a zjistit, proč se konfigurace tváří jako cizí.
  • Virtual Drive Offline / Failed: server vypnout. Opakované rebooty mohou spustit inicializaci nebo další zápisy do metadat.
  • Unconfigured Good po výměně řadiče: neznamená, že jsou disky prázdné. Znamená to, že nový řadič nevidí původní konfiguraci.
  • Rebuild failed u RAID 5/6: další pokus typicky zatíží stejné disky znovu. Bez sektorových klonů je to hazard.
  • VMware VMFS datastore inaccessible: neklikat na Format, Resignature ani vytvoření nového datastore. Ztrácí se tím struktura virtuálních strojů.

Bezpečný postup je stejný u HP Smart Array, Dell PERC i LSI MegaRAID: zachovat fyzické pořadí disků, odpojit pole od zápisů, naklonovat každý disk zvlášť a teprve z kopií ověřit, jak bylo pole složené.

1. Proč je hardwarový RAID na serveru jiná liga

Zatímco u levných NASů nebo softwarových polí se pracuje s relativně standardizovanou hlavičkou, enterprise servery používají dedikované RAID řadiče s vlastní logikou a uzavřenými metadaty. To je zásadní rozdíl, který mění záchranu dat v detektivní práci na úrovni bitů.

Proprietární metadata a past jménem „Foreign Config”

Řadiče jako HP Smart Array (řady Pxxx), Dell PERC (H710, H730, H740), Broadcom/LSI MegaRAID nebo Adaptec/Microsemi si na discích vytvářejí vlastní konfigurační sektory, které obsahují informace o úrovni RAID, stripe size, pořadí disků a pozici v rámci pole. Tato metadata nejsou přenositelná mezi výrobci, často ani mezi různými generacemi řadičů od stejné firmy. Pokud řadič po startu nevidí očekávanou konfiguraci, ohlásí „Foreign Configuration”. Následná volba „Import Foreign” nebo „Clear” bez hluboké znalosti situace zapisuje na disky a může přepsat poslední známou dobrou mapu pole.

Virtualizace nad RAID: neviditelný další stupeň

Enterprise servery typicky neukládají soubory napřímo. Na hardwarovém RAID svazku je nahozen hypervizor — nejčastěji VMware ESXi s datastory VMFS, nebo Microsoft Hyper-V s formátem VHDX. Když pole spadne, nepřicházíte jen o souborový systém, ale o celý kontejner s virtuálními servery. Laboratorní rekonstrukce tedy nesmí skončit u poskládání bloků, ale musí jít hlouběji: najít a opravit strukturu VMFS, ověřit jeho tabulky a vyextrahovat virtuální disky. Toto je zásadní kontext, který odlišuje server od jednoduchého externího boxu.

2. Typické scénáře selhání serverového pole

Hardwarový RAID na serveru je robustní, ale jeho selhání mívají specifický průběh, který končívá fatálním offline stavem.

Degradovaný RAID 5 a kaskádový výpadek

Nejčastější scénář. RAID 5 snese ztrátu jediného disku. Správce si všimne blikající oranžové diody, objedná nový disk a spustí výměnu. Problém je v tom, že všechny zbylé disky v poli jsou zpravidla stejného stáří, ze stejné výrobní šarže a mají za sebou totožný počet motohodin. Plný rebuild, který trvá desítky hodin, představuje extrémní zátěž. Pokud se na jiném disku objeví byť jen jeden vadný sektor, na kterém se rebuild zasekne, pole přechází z Degraded rovnou na Failed. U RAID 6 je situace s dvěma parity disky lepší, ale i tam platí nulová tolerance během rebuildu — viz reálný případ s 20 disky níže.

Selhání řadiče a „Foreign Config”

Hardwarový řadič není nesmrtelný. Může odejít kvůli přepětí, zkratu na backplane, nebo prostě po letech provozu. Pokud vezmete disky a přepojíte je do jiného serveru (nebo jiného slotu), řadič zahlásí cizí konfiguraci. Importovat naslepo bez znalosti původního stripe offsetu, zarovnání a verze firmwaru znamená riziko, že řadič zapíše nová metadata špatně — obzvlášť pokud se mezi generacemi řadičů změnila geometrie rozložení dat. Prosté přehození disků z jednoho serveru do druhého tak může skončit promazáním mapy pole.

Serverové SAS disky označené podle slotů a RAID řadič vyjmutý ze serveru při řešení chyby Foreign Config v laboratoři ITHOPE Brno
U serverového RAIDu je pořadí šachet stejně důležité jako samotný řadič. Při hlášce „Foreign Config" se disky nejdřív označí a klonují; import konfigurace bez analýzy může přepsat poslední použitelnou mapu pole.

Poškozený VMFS datastore a výpadek expandéru

Zvlášť zákeřné jsou výpadky napájení nebo momentální poruchy SAS expandéru (backplane). Backplane může na milisekundu odpojit několik disků najednou. Hardwarový řadič je okamžitě vyhodnotí jako mrtvé a označí je za „Failed”. K žádné fyzické vadě přitom nedošlo, ale pole je rozbité. Stejně tak nešikovný zásah do ESXi (např. vytvoření nové partition tam, kde byl datastore) udělá z VMFS nečitelnou změť metadat.

3. Co NESMÍTE dělat se serverovým RAID řadičem

Toto je naprosto zásadní. Předejte to prosím svým IT kolegům — jde o kroky, které likvidují poslední šanci na záchranu.

  • Neimportujte „Foreign Configuration” bezhlavě. Dokud nevíte, proč se konfigurace tváří jako cizí, je Import časovanou bombou. Zvláště pokud byl měněn řadič nebo došlo k přehození disků.
  • Neinicializujte nový virtuální disk. Pokud server nereaguje na starý VD, nikdy nevolte „New Volume / New Logical Drive” na stejných fyzických discích. Tento krok přepíše hlavičku pole a s jistotou zničí mapu oddílů.
  • Nespouštějte rebuild, pokud vidíte dva a více vadných disků. Jakmile jste u RAID 5 ve stavu, kdy je problémů víc, nejde o údržbu, ale o záchranu. Každá sekunda zátěže čtením při rebuildu zabíjí zbylé disky (viz kaskádový výpadek).
  • Nepřepojujte disky mezi pozicemi metodou pokus-omyl. Hardwarový řadič identifikuje sloty. Pokud je před vytažením neoznačíte, ztrácíme čas a zvyšujeme riziko.
  • Neupgradujte firmware řadiče ani hypervizoru na rozbitém poli. Pokus opravit nefunkční pole flashnutím novější verze Smart Array / PERC firmwaru může změnit způsob čtení metadat.
  • U ESXi nevytvářejte nový datastore. Když vCenter hlásí „Inaccessible”, neklikejte na „Format” ani „Resignature”. Dejte to k nám.

4. Jak záchranu serverového pole řeší laboratoř

Tajemství je přestat spoléhat na logiku řadiče a začít pracovat se surovými daty.

  1. Sector-level klonování. Každý jednotlivý disk (SAS i SATA) přesuneme na specializované klonovací stanice (PC-3000, DeepSpar Disk Imager). Cílem je sektor po sektoru vyčíst veškerá čitelná data dřív, než se disky rozsypou. Vadné sektory řešíme hardwarově, ne softwarovým timeoutem řadiče. Disky s poškozenými hlavami putují do laminárního boxu.
  2. Offline analýza proprietárního layoutu. Z klonů vyextrahujeme binární metadata. Zde láme HP Smart Array jiný chleba než Dell PERC. Hledáme parametry: stripe size, rotaci parity (left/right, synchronní/asynchronní) a hlavně skutečné pořadí disků a offset začátku dat (některé řadiče nechávají před daty rezervu). Nic neodhadujeme — vše potvrzujeme proti struktuře souborového systému.
  3. Virtuální rekonstrukce pole. Na našem výpočetním úložišti (staging 120 TB SATA RAID 10) poskládáme klony do virtuálního blokového zařízení. Nepoužíváme originální serverový řadič. Pokud na poli běží VMware, přichází klíčová fáze: rekonstrukce VMFS tabulek — superblock, alokační pointery, napojení VMDK a VHDX.
  4. Extrakce na staging. Výsledná data (často desítky TB) extrahujeme na ověřený filesystém. Pokud zákazník potřebuje jen konkrétní virtuální stroj, vytáhneme jen jeho VMDK soubor.

5. Reálný případ: enterprise rekonstrukce 20diskového RAID 6

Přesně v duchu výše popsaných nástrah probíhala záchrana pro projekční firmu v Brně. Šlo o 160TB pole s 20 disky v RAID 6, ale situace je dokonale přenosná na jakýkoli velký server s hardwarovým RAID.

V pondělí selhal disk #7. Administrátor objednal náhradní a spustil náročný rebuild. V úterý selhal disk #12 — pole se dostalo do kritického stavu, ale pořád běželo (dvě parity to měly zvládnout). Jenže po 30 hodinách se rebuild zasekl na vadném sektoru „zdravého” disku #5. Chybový sektor vylezl právě kvůli brutální zátěži při rebuildu a v tu ránu mělo pole tři problémová místa — rekonstrukce parity selhala, pole spadlo offline. Řešení vyžadovalo naklonovat všech 20 disků, offline najít proprietární stripe offset a pořadí, a data extrahovat na náš staging. Trvalo to 11 dní, výsledek byl 100 % všech dat. Detaily: 20-diskový RAID 6.

Často se ptáte

Řadič je mrtvý, přijdu o celé pole?

Ne. Pokud je mrtvý jenom řadič (a disky jsou mechanicky v pořádku), data na plotnách zůstávají. Řešíme to tak, že disky naklonujeme a pole poskládáme softwarově podle proprietárních metadat, která na discích zůstala. Nepotřebujeme nutně identický náhradní řadič, což je klíčové, protože starší HP nebo Dell modely už nejdou sehnat. Obecně platí: čím dřív to vypnete, tím lépe. Více o pravidlech pro RAID viz Záchrana RAID a NAS.

Po výměně řadiče server hlásí „Foreign Config”. Co teď?

Vypnout, označit pozice disků a nedělat vůbec nic v BIOSu řadiče. Když pošlete pole k nám, z diskových klonů načteme starou konfiguraci offline a ověříme ji proti struktuře souborového systému. Volba „Import Foreign” je hazard, protože nevíte, jestli má nový řadič stejné zarovnání a logiku čtení jako ten starý.

Můžu disky z HP ProLiant zapojit do jiného serveru a pole importovat?

Důrazně nedoporučujeme. V laboratoři to sice děláme, ale čistě pro čtení na hardwaru, který na disky nezapisuje. Jiný server při bootu může začít se synchronizací nebo rovnou hodit disky do stavu „Unconfigured Good” a tím smazat metadata RAIDu.

Běží na tom VMware ESXi — jde zachránit jen jeden virtuální stroj?

Ano. Jakmile virtuálně zrekonstruujeme celý VMFS datastore, můžeme selektivně extrahovat jen vybrané virtuální disky (VMDK). Není nutné zachraňovat datastore jako celek, což se hodí zvlášť při omezené kapacitě na vaší straně.

RAID 5 na Dellu a selhal jeden disk — musím hned řešit záchranu?

Pokud se pole dostalo jen do stavu Degraded, je čas na zálohu, ne na paniku — ale za podmínky, že se nespustí rebuild a data se začnou okamžitě kopírovat ven. Pokud je to vaše primární storage a nemáte zálohu, vypnutí serveru a předání disků nám je bezpečnější než doufat, že roky staré vedlejší disky vydrží mnohahodinový rebuild.

Jak dlouho záchrana serverového pole trvá?

Přesnou dobu ovlivní kapacita a rozsah poškození. Standardní pole o 4–8 discích řešíme v řádu jednotek pracovních dní. Masivní rekonstrukce desítek terabajtů (viz 20-diskový RAID 6) může vyžádat i dva až tři týdny. Přesný odhad dostanete po diagnostice.

Co dělat teď

  1. Okamžitě vypněte server. Pokud nestartuje, odpojte napájení. Nepokračujte v rebootech a nepokoušejte se o opravu vestavěnými nástroji.
  2. Fyzicky označte disky. Před manipulací si zapište jejich pozice (slot 1, slot 2…). U HP a Dell serverů s hot-swap šachtami je pořadí zásadní. Vyfoťte i zadní připojení, pokud je odkryté.
  3. Nepouštějte na to běžného ajťáka bez zkušeností s laboratorní záchranou. Standardní IT technik zpravidla nemá instruktáž k tomu, aby do pole nezasahoval a naslepo neimportoval konfiguraci.
  4. Kontaktujte naši laboratoř. Volejte NONSTOP na +420 775 556 063 nebo využijte naši nezávaznou konzultaci. Domluvíme svoz nebo bezpečný transport disků do Brna.
  5. Počítejte s diagnostikou zdarma. V laboratoři disky posoudíme, ověříme, zda se na nich nezapisovalo, a řekneme přesnou cenu za kompletní obnovu. Platíte až po úspěšně odvedené práci, po zobrazení seznamu zachráněných souborů.

Shrnutí v bodech

  • Hardwarové řadiče (HP, Dell, LSI) používají proprietární metadata; výměna řadiče „kus za kus” často selže a končí ztrátou konfigurace.
  • Kaskádový výpadek během rebuildu je u starších disků v RAID 5/6 hlavní příčinou fatálního selhání — pole se nesmí dál zatěžovat.
  • Při hlášení „Foreign Config” je jakýkoli import bez offline analýzy rizikem přepsání mapy pole.
  • Virtualizace přidává další vrstvu: po složení bloků musí laboratoř opravit VMFS/NTFS struktury a vypreparovat virtuální disky (VMDK/VHDX).
  • Netgear ReadyNAS (X-RAID) i velkokapacitní enterprise boxy vyžadují stejný přístup — klon disku, rozklíčování parity a offline rekonstrukci.
  • Laboratoř ITHOPE pracuje se SAS i SATA klonovacími stanicemi, v čistém prostředí a se stagingem 120 TB — a hlavně offline, bez jediného zápisu na originální disky.

Spadl vám server do stavu Degraded nebo Offline? Nespouštějte rebuild a neimportujte cizí konfiguraci — každý pokus snižuje šance. Nezávazná konzultace · Diagnostika zdarma · Kontakt · +420 775 556 063 (NONSTOP)

Viz též: Záchrana dat z RAID pole · Synology NAS · QNAP NAS · Záchrana RAID a NAS (služba) · Case study: 20-diskový RAID 6


O autorovi

Ing. Miroslav Jaroš je majitel a senior technik ITHOPE s.r.o. v Brně. Záchraně dat se věnuje od roku 2008 — za 18 let prošlo laboratoří přes 2 500 zakázek, od jednotlivých disků po enterprise RAID pole a NAS. Článek prošel odborným fakt-checkem (Tomáš Kopřiva) proti reálné praxi laboratoře ITHOPE. Popsaný případ 20-diskového RAID 6 vychází z reálné anonymizované zakázky.

Zavolat Kontakt