Jak jsem chtěl prodat Arecu a místo toho rozebral její RAID

dnes 13:14 | Přečteno: 158× |

Ahoj!
Po zhruba šesti letech jsem si řekl, že bych mohl zase něco napsat. A jak už to tak bývá, nezačalo to žádným velkým plánem, ale úklidem.

Válela se mi tu externí RAID krabice Areca ARC-5020. Chtěl jsem ji dát od koruny na Aukro, protože neuměla rozumně iSCSI, používala proprietární RAID formát a obecně zabírala místo. Před prodejem jsem ji ale samozřejmě musel otestovat. A při tom jsem si řekl, že se na to nefunkční iSCSI ještě jednou podívám.

To byla chyba.

iSCSI se totiž nakonec podařilo zprovoznit. Tím vznikl nový problém: najednou se mi pole už nechtělo tolik prodávat. Jenže stále používalo vlastní RAID formát a pokud by krabice umřela, byl by přístup k datům přinejmenším dost nepříjemný. Takže z krátkého testu před prodejem vzniklo reverzní inženýrství formátu na discích a nakonec i nástroj pro obnovu dat.

Výsledek je tady:

https://github.com/Salamek/areca-arc5020-recovery

Co je vlastně ARC-5020

ARC-5020 je starší externí diskové pole pro čtyři SATA disky. Umí RAID0, RAID1, RAID1+0, RAID3 a RAID5, má USB, eSATA, Ethernet a webové rozhraní, které vypadá přesně tak, jak byste od storage krabice z přelomu nultých a desátých let čekali.

Můj kus běží na firmwaru V1.50 2012-03-05. Zajímavé je, že poslední firmware, který se mi podařilo najít na oficiálním webu, je verze 1.46 z roku 2009. Netuším, odkud jsem tehdy 1.50 vzal. Dost možná jsem už před lety podnikl první neúspěšný pokus iSCSI rozchodit a pak na to úspěšně zapomněl.

Samotné pole fungovalo. Problém byl, že při iSCSI discovery Linux pouze oznamoval:

iscsiadm: No portals found

Webové rozhraní přitom žádnou položku „exportovat přes iSCSI“ nenabízelo. Bylo v něm jen přiřazení Volume Setu na kanál a číslo disku. Nakonec se ukázalo, že je potřeba zvolit kanál USB a číslo disku 8 až 15. Ano, USB. Stejný rozsah firmware používá i pro síťové targety.

Po přiřazení Volume Setu na USB/8 se konečně objevil target:

192.168.1.235:3260,1 iqn.2000-01.com.abc.xyz:group-08

Takže iSCSI celou dobu fungovalo. Jen bylo schované za volbou, u které by mě nenapadlo jej hledat.

Funguje! Tedy skoro

Přihlášení proběhlo, Linux našel blokové zařízení a na něm šel vytvořit ext4. Malé zápisy fungovaly. Pak jsem na disk začal kopírovat desetigigabajtový soubor.

Po chvíli se objevilo něco jako:

invalid R2T with data len 12288 at offset 1044480
detected conn error (1006)
I/O error, dev sdi
Aborting journal on device sdi1-8
EXT4-fs: Remounting filesystem read-only

Takže ne, ještě jsme nevyhráli.

Starý target posílá při větších požadavcích neplatné iSCSI R2T rozsahy. Výsledkem jsou resety spojení, I/O chyby a v mém případě i odstřelený ext4 journal. Po několika pokusech se podařilo najít konzervativní nastavení, se kterým jsou dlouhé zápisy stabilní:

cmds_max = 16
queue_depth = 1
MaxBurstLength = 131072
FirstBurstLength = 65536
max_sectors_kb = 128

Ano, queue_depth = 1 není zrovna cesta k rekordům v IOPS. Ale u zařízení, které má USB 2.0 a před chvílí bylo na pomezí mezi popelnicí a aukrem za "kačku", mě to příliš netrápí. Jedno- i desetigigabajtový test pak proběhl bez chyby. V repozitáři je areca_iscsi.sh, který target přihlásí, zjistí přiřazené blokové zařízení a omezení nastaví.

Mimochodem, pole hlásí zapnutou write cache a neumí FUA. Kopírování proto může na první pohled skončit podezřele rychle, zatímco sync ještě nějakou dobu pracuje na pozadí. Před vypnutím je opravdu dobrý nápad počkat.

Proprietární RAID, aneb co je na těch discích

Když už iSCSI fungovalo, zbývala druhá část problému. Co se stane, když odejde samotná Areca?

Jednotlivý disk z RAID1 se po připojení k Linuxu nehlásil jako normální partition. Filesystem na něm ale očividně někde být musel. Na začátku disku se ukázala metadata se sympaticky nenápadnými signaturami:

LBA 1: $RaidSD$
LBA 2: $VolumE$

To už vypadalo nadějně. V metadatech byl počet členů, index konkrétního disku, velikost RAID setu, název Volume Setu, RAID level i velikost stripe. Samotná data prvního Volume Setu začínala na LBA 520, tedy 266240 bajtů od začátku fyzického disku.

U RAID1 stačilo vytvořit loop zařízení s tímto offsetem a ext4 se normálně objevil. Kontrolní součty jedno- i desetigigabajtového souboru seděly. Tím se potvrdilo, že Areca u RAID1 nedělá nic exotického: před běžný obsah jen přidá vlastní metadata.

To byl samozřejmě okamžik, kdy bylo možné projekt prohlásit za hotový a jít dělat něco užitečného.

Takže jsem místo toho vytvořil RAID1+0.

Jak zjistit rozložení RAIDu s jednou USB redukcí

Pro experimenty vznikl jednoduchý deterministický vzor. Každý logický sektor obsahuje mimo jiné své LBA, takže po zápisu vzoru přes iSCSI lze fyzický disk odpojit, připojit přímo k Linuxu a okamžitě poznat, které logické sektory na něm skončily.

Praktická část vypadala asi takto:

1. vytvořit pole a počkat na inicializaci;
2. zapsat přes iSCSI desítky nebo stovky MiB testovacího vzoru;
3. korektně pole vypnout;
4. vyndat jeden disk;
5. připojit jej přes jedinou USB–SATA redukci;
6. prohlédnout metadata a posloupnost LBA;
7. disk vrátit a pokračovat dalším členem.

Bylo to trochu pomalé a postupně jsem získal velmi dobrý přehled o tom, "co patří do které díry". Na druhou stranu je podobný black-box test docela příjemný: nemusíte hádat, co firmware asi dělá. Na discích přímo vidíte, co skutečně udělal.

Postupně se podařilo ověřit následující:

RAID	Ověřené rozložení
RAID0	běžný round-robin stripe přes čtyři disky
RAID1	dvě úplné kopie dat
RAID1+0	mirror páry 0+1 a 2+3, stripe mezi páry
RAID3	členy 0 až N−2 jsou data, poslední člen je vyhrazená XOR parita
RAID5	čtyřdiskový left-symmetric layout s rotující paritou

RAID1+0 byl otestovaný s 32 i 64KiB stripe a nástroj velikost čte z metadat. RAID3 používá pevný 4KiB chunk. U RAID3 i RAID5 prošla rekonstrukce se všemi disky i s každým jednotlivým chybějícím členem.

Zajímavé bylo i zjištění, že jeden Raid Set může obsahovat několik Volume Setů. Metadata pro ně jsou namačkaná do 128bajtových záznamů a jejich začátek na jednotlivých členech lze spočítat jako:

520 + allocation_offset * 512 sektorů

Pro jistotu jsem tedy znovu vytvořil všechny podporované typy polí, tentokrát se dvěma různě velkými Volume Sety, zapsal do nich rozdílné vzory a znovu přehazoval disky. Číslování stripů i paritních řádků začíná pro každý Volume Set znovu. Aktuální nástroj proto umí svazek vybrat jménem nebo indexem.

Co z toho vzniklo

Původní hromada jednorázových skriptů se časem změnila na malou Python knihovnu a několik příkazových nástrojů. Nemají externí Python závislosti.

Metadata jednoho disku lze prohlédnout takto:

./areca_member.py /dev/sdc

Nástroj nepředpokládá, že /dev/sdc je první člen. Pořadí bere z indexu uloženého přímo v Areca metadatech.

Pole lze z členů automaticky rozpoznat:

./areca_raid.py inspect --json /dev/sdc /dev/sdd

Nebo zrekonstruovat do obrazu:

./areca_raid.py reconstruct recovered.img member0 member2

Pro RAID1 a RAID1+0 lze vytvořit také živé read-only blokové zařízení přes device mapper:

sudo ./areca_raid.py create-dm arc5020-recovery \
    /dev/sdc /dev/sdd

Pak se s /dev/mapper/arc5020-recovery pracuje jako s normálním diskem. U RAID3 a RAID5 se zatím rekonstruuje do image nebo jiného výstupního zařízení; device-mapper neumí potřebnou XOR logiku rozumně vyjádřit.

Zápis do složeného pole není cílem projektu. Šlo by jej implementovat, ale u recovery nástroje má write support výborný poměr rizika k téměř nulovému praktickému užitku. Vstupní disky se proto otevírají read-only a neznámé nebo nekonzistentní kombinace metadat nástroj raději odmítne.

Součástí repozitáře je i testovací sada. Testy si generují vlastní malé syntetické členy, takže v GitHub CI nepotřebují skutečné obrazy disků ani čtyři terabajty testovacího železa. Zdrojové kódy jsou pod GPLv3+.

Test ohněm

Syntetické testy jsou fajn, ale chtěl jsem ověřit přesně ten scénář, kvůli kterému celý projekt vznikl.

Vytvořil jsem tedy nové čtyřdiskové RAID1+0 s 64KiB stripe, přes iSCSI na něm udělal ext4 a zkopíroval dvougigabajtový soubor. Po sync a vypnutí pole jsem k Linuxu připojil dva fyzické disky z různých mirror párů.

Shodou okolností se připojily v jiném pořadí, než jaké měly v poli. To ničemu nevadilo, protože parser na jednom našel index 2 a na druhém index 0. areca_raid.py create-dm z nich vytvořil read-only zařízení a Linux na něm okamžitě poznal ext4:

/dev/mapper/arc5020-recovery:
UUID="9727026c-21da-4152-8fb4-f3b87d150a7b"
BLOCK_SIZE="4096"
TYPE="ext4"

Filesystem jsem připojil read-only bez replaye journalu a SHA-256 dvougigabajtového souboru sedělo.

A pak jsem z takto poskládaného pole pustil film. Protože jestli něco projde unit testy, kontrolním součtem a ještě se z toho dá plynule přehrávat video, je to podle mého názoru dostatečně vědecká metoda.

Co zůstává neznámé

Všechny závěry vycházejí z jednoho ARC-5020 s firmwarem 1.50 a z konkrétních otestovaných konfigurací. Jiné modely Areca, jiné počty členů nebo jiné verze firmwaru mohou používat odlišný formát. Nástroj se je nesnaží sebevědomě „nějak“ poskládat.

Pokud někdy budete skutečně zachraňovat data, pořád platí nudná, ale důležitá pravidla: nejdřív udělat obrazy disků, originály nechat být, filesystem připojovat read-only a nevěřit výsledku jen proto, že vypadá uvěřitelně.

Takže ARC-5020 nakonec na Aukru neskončila. Místo toho mám zase jednu krabici navíc, několik desítek stran poznámek a recovery nástroj pro případ, že jednou odejde.

Stačilo se na to před prodejem ještě jednou podívat.

Při vývoji bylo použito LLM Codex (GPT-5.6-Sol)        

Komentáře

[vencour]

Děkuji, dobrá práce :)
🐧 +1