Stroj běží bez potíží, takže nevyžaduje žádnou péči, kromě pravidelného archivování záloh na různá média. Taky občas kouknu na stav procesu mdadm či na smart data disků, i když mám oba démony nakonfigurované na posílání mailů při potížích. Takže věřím, že, pokud se něco stane s polem nebo s diskem, server mi o tom pošle info. Protože však tato situace ještě nenastala, je to vskutku jen víra…

Měla jsem možnost levně koupit jedno 1T SSD, tak jsem si řekla, že bych vyzkoušela cestu, vyměnit disk v runtime stroje. Při minulé výměně disků za větší jsem neměla ještě backplane podporující hotswap, takže jsem používala přímé připojení disků do SATA portů na základní a rozšiřující desce, stroj jsem pro operaci fyzické výměny disku raději vypínala, ačkoliv hotswap je už podporován v samotném standardu SATA.

Tentokrát jsem si chtěla projít cestu základní užití pro případ skutečného selhání nějakého disku, zda vše zafunguje podle očekávání.

Nejdříve se poli nahlásí selhání disku příkazem -f (fail). Takže

mdadm /dev/md0 -f /dev/sdX

V tuto chvíli server poslušně poslal mail:

A Fail event had been detected on md device /dev/md/0.
It could be related to component device /dev/sdX.
Faithfully yours, etc.

Pěkné. Následovalo odebrání starého disku z pole:

mdadm /dev/md0 –remove /dev/sdX

Nyní jsem z backplanu vyjmula příslušný starý disk, čehož si všimnul smart deamon, který mi napsal:

The following warning/error was logged by the smartd daemon:
Device: /dev/sdX [SAT], unable to open ATA device
Device info:
ADATA SU800, S/N:1NNSKBABEA552, WWN:7.6267666ah666, FW:02K0S86D, 512 GB

Taky dobré, že nemusím těm démonům už jen věřit, vím, že ty maily skutečně chodí. Nedalo mi, a zkontrolovala jsem, zda server v tomto stavu degradovaného pole stále bez potíží funguje. Samozřejmě fungoval 🙂

Starý, ovšemže zcela funkční disk s mírně zvýšením wear-levelingem jsem vyšroubovala z rámečku, připevnila tam disk nový, a rámeček jsem zasunula do šuplíku backplane.

Mimochodem – disky do mdadm polí lze vkládat zcela nové, bez partitions, samozřejmě nenaformátované, mdadm si vše potřebné zařídí sám. Při tomto způsobu používání disků v raid poli je ovšem riziko, že nějaký drzý Bios přepíše Luks hlavičku a nastane problém, který by při použití oddílu nenastal. Tohle se mi skutečně jednou stalo, když jsem ladila náš školní server. Potřebovala jsem server restartovat a trochu se porýpat v nastavení biosu, a zabloudila jsem i do stránek SAS controlleru. Ten si hlavičky olízlnul a zmršil je, pole jsem pak sestvovala ještě jednou.

Pokud je nad raid polem šifrovaný kontejner, celé se to automaticky pochopí, stačí jen disk (nebo oddíl) přidat do pole:

mdadm /dev/md0 -a /dev/sdX

Předtím je je ale dobré se ujistit, že systém vidí nový disk, případně, že jej namapoval pod písmenem starého disku.

Po přidání náhradního disku do pole spustil mdadm proces rebuildu, který trval přibližně 30 minut.

Takže o starost méně, až jednou dostanu mail o skutečné poruše disku, můžu se spolehnout na to, že lze provést v runtime stroje.