Dotaz: RAID5, ano nebo ne?

[Czlovek]

Chtěl bych si postavit takový domácí server, včetně většího úložiště. Naplánoval jsem si koupit 4x WD Red 4 TB a zapojit je do RAID5 (softwarový mdadm). Jenže na RIAD5 jsem slyšel různé názory, ne vždy pozitivní. Vím že RAID není záloha, tu budu samozřejmě realizovat jinak, ale chtěl bych to použít hlavně na data typu filmy apod. která jsou v nejhorším postradatelná a nezálohují se, ale tím RAID5 bych se chtěl trochu pojistit, že i při smrti jednoho disku o to teoreticky nepřijdu, a navíc takhle budou všechny disky rovnoměrně zatížené, kdybych je měl jako samostatné, tak přirozeně budou zatížené dost nerovnoměrně.

Odpovědi

[Lukfi]

Problém s RAIDem 5 je v tom, že zatímco kapacita pevných disků roste, chybovost média zůstává podobná - 1 bit ku 10^12 až 10^15, což odpovídá zhruba 1 bitu na jednotky až desítky TB. V podstatě, v momentě, kdy ti umře jeden disk ze čtyř a měl bys je plné, potřebuješ přečíst celkem 12 TB dat a tam už je dost velká šance, že to některá data nepřečte. Ale jestli může někdo potvrdit, že v takovém případě to řadič nebo SW raid v Linuxu překousne a přijdeš jen o ten soubor, ve kterém nastala chyba, tak to na filmy asi tolik nevadí a je to lepší než samotné disky. http://www.high-rely.com/blog/why-raid-5-stops-working-in-2009-not/

[Czlovek]

Tak to by mě právě taky zajímalo, jestli při chybě se rekonstrukce vůbec nezdaří, nebo jestli je možné vynutit aby byl daný bit/sektor přeskočen. Jeden špatný bit u filmu by ani nikdo nepoznal, jeden sektor by v tom místě způsobil rozkostičkování, tj. nic až tak hrozného (u filmu/hudby, u jiných dat by to byl problém).

[pavlix]

Platí tahle teorie i pro formáty s variable bitrate?

[Petr Tomášek]

Asi jak kdy.

Zřejmě bude záležet na prohlížeči, jak je robustní. Teoreticky by mělo být možné se u každého streamu znovu zasynchronizovat, ale praktické zkušenosti jsou takové, že to nebude vždy fungovat...

[pavlix]

Měl jsi potřebu napsat pár nepodložených žvástů nebo o tom opravdu něco víš?

[Petr Tomášek]

Vím, že mi občas chcípne mplayer, když se mu rozsype stream.

A vím, že např. Ogg jakožto kontainerový formát má vždy na začátku každého bloku synchronizační 4 bajty. Předpokládám, že ostatní kontainery to budou mít taky tak, takže předpokládám, že je to tak navržené, aby se přehrávač při chybě ve streamu měl šanci znovu "chytit".

No a video kodeky jsou dělány tak, že čas občas mají klíčové framy (třeba u MPEG-2 jsou to I-frames), které zase umožňují "začít od začátku" např. ve chvíli kdy se rozsype obraz. Ostatní kodeky to mají podobně.

Takže z toho vyplývá, že kontainery a kodeky jsou dělány tak, aby se dokázaly z chyb v bitstreamu vzpamatovat (s VBR versus CBR to moc nemá co do činění).

Ale v praxi to nemusí nutně fungovat (alespoň z mé zkušenosti).

[pavlix]

Takže celkem víš, to je fajn, synchronizační bajty, to je asi sekvence, která se běžně nepotká z hlediska pravděpodobnosti, že.

[Josef Kufner]

Ano

A vlastně je i celkem jedno, jestli se vyskytuje i jinde. Když data za značkou nebudou dávat smysl, začne se hledat další značka.

[Heron]

Ale jestli může někdo potvrdit, že v takovém případě to řadič nebo SW raid v Linuxu překousne a přijdeš jen o ten soubor

Takto to nefunguje. HW řadič ani MD neví o souborech vůbec nic. V případě chyby čtení při opravě degradovaného pole je jednoduše konec.

Na to jsou dobré souborové systémy typu BTRFS nebo ZFS, které ví kde co mají za data a v nejhorším případě opravdu přijdete o jednotlivé soubory (jejiž jména se dočtete v logu). (Ale R5 na BTRFS zatím není úplné OK.)

[Jendа]

Takto to nefunguje. HW řadič ani MD neví o souborech vůbec nic. V případě chyby čtení při opravě degradovaného pole je jednoduše konec.

To ho fakt neumí přeskočit (a třeba vyplnit nulama)?

[Sten]

Ta chyba čtení způsobí, že se přečte něco jiného (jeden bit bude jinak), ne že čtení selže.

[Jendа]

V tom případě neplatí je jednoduše konec, ale prostě budeš mít jeden bit blbě.

Mimochodem mám už skoro rok ve správě ZFS pole z 12 1.5TB a 2TB disků (Seagate, mix různých modelů a sérií), které se čte každý týden, a ještě jsem takovou chybu neviděl.

[Sten]

To také záleží na tom, jak moc to pole máte plné a jaké modely to jsou (možná mají 10^-14 nebo menší chybovost)

[Jendа]

Je tam asi 8 TB dat a jsou to

ST31500341AS
ST31500341AS
ST2000DM001-
ST31500341AS
ST1500DM003-
ST31500341AS
ST31500341AS
ST31500341AS
ST1500DM003-
ST31500341AS
ST1500DM003-
ST1500DM003-

Pak mám ještě několik MD polí, kde se přiznám, že to nesleduju (vyhodí to disk když v RAID1/5/6 dojde k takovéto chybě?). Asi začnu.

[Jendа]

Tak jsem na testovacím poli přehodil pár bitů, obsah se poškodil, ale data-check vůbec nic nenapsal. WTF?

[1265016.733130] md: md0 stopped.
[1265016.733773] md: bind<loop2>
[1265016.733888] md: bind<loop3>
[1265016.734011] md: bind<loop1>
[1265016.738171] md/raid:md0: device loop1 operational as raid disk 0
[1265016.738178] md/raid:md0: device loop3 operational as raid disk 2
[1265016.738182] md/raid:md0: device loop2 operational as raid disk 1
[1265016.739111] md/raid:md0: allocated 0kB
[1265016.740135] md/raid:md0: raid level 5 active with 3 out of 3 devices, algorithm 2
[1265016.740143] RAID conf printout:
[1265016.740147]  --- level:5 rd:3 wd:3
[1265016.740152]  disk 0, o:1, dev:loop1
[1265016.740157]  disk 1, o:1, dev:loop2
[1265016.740163]  disk 2, o:1, dev:loop3
[1265016.740196] md/raid456: discard support disabled due to uncertainty.
[1265016.740200] Set raid456.devices_handle_discard_safely=Y to override.
[1265016.740279] md0: detected capacity change from 0 to 57671680
[1265016.741451]  md0: unknown partition table
[1265025.994964] md: data-check of RAID array md0
[1265025.994979] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
[1265025.994985] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
[1265025.994997] md: using 128k window, over a total of 28160k.
[1265027.026126] md: md0: data-check done.

[Lyco]

RAID (každý s výjimkou RAID 6) spoléhá na detekci chyb na řadiči nebo v disku, a neumí rozeznat poškozená data. Je to zdokumentované asi tak všude (manuál) a nelze s tím nic dělat, protože prostě není možné rozeznat, který ze dvou daných různých bitů (= disků) je správný. Takhle se chová úplně každý RAID, je jedno jestli softwarový nebo hardwarový.

RAID 6 je výjimka, protože jsou k dispozici 2 paritní bity. Za předpokladu že došlo k chybě v jednom bitu se dá určit který je chybný a data opravit. Pokud je chyba ve víc než jednom bitu, pak RAID6 poškodí další data.

RAIDZ a podobné (to co používá ZFS, BTRFS a spol) mají k dispozici další informace, které jim umožňují rozhodnout která data jsou správná. V podstatě dělají to samé co disky s jejich interními kontrolními součty, jenom víc.

[Mrkva]

Je to zdokumentované asi tak všude (manuál) a nelze s tím nic dělat, protože prostě není možné rozeznat, který ze dvou daných různých bitů (= disků) je správný

Co takhle vyhodit chybu ze data nesouhlasi?

[Pepa]

Chybu to nehodí, ale za to se zvedne mismatch_cnt podle počtu poškozených bloků. Ale které bloky to jsou a kde to si nechá pro sebe.

[Sten]

Bloky to zahlásí do dmesg

[Jendа]

Mně to nic nezahlásilo.

[Jendа]

a neumí rozeznat poškozená data

Umí, v případě mirroru snad vidí, že se ty dvě kopie neshodují, a v případě RAID5, že 1 XOR 2 \= 3.

a nelze s tím nic dělat, protože prostě není možné rozeznat, který ze dvou daných různých bitů (= disků) je správný

Když mi to řekne, mohu obnovit ten soubor ze zálohy.

[trubicoid]

jendo, dej po dobehnutym check (jak uz tu radili)

cat /sys/block/md*/md/mismatch_cnt

jinak je mozny, ze si pretocil bit ne v souborum, ale nahodou ve volnym miste nebo hur v metedatech fs

by me zajimalo, kdyz bys pretocil bit v souboru, tak jestli jeho cteni hodi chybu, ale myslim, ze RAID1 cte kvuli rychlosti bloky na stridacku, ale ne dvakrat, takze jednou dostanes preklopeny a jednou nepreklopeny. s RAID5 to asi bude stejny, bude cist 2 ze tri

jinak k puvodnimu tematu: mel jsem RAID5 s xfs, ted mam zfs raidz1 a btrfs raid5, to bych asi doporucil, kontrolu raidu nebo scrub delam z cronu jednou za tyden, dlouhy smart test jednou za mesic

[Jendа]

jendo, dej po dobehnutym check (jak uz tu radili)

cat /sys/block/md*/md/mismatch_cnt

Ha, super, dám ten soubor na serverech monitorovat.

jinak je mozny, ze si pretocil bit ne v souborum, ale nahodou ve volnym miste nebo hur v metedatech fs

Ne, koukal jsem přímo na blokové zařízení bez FS.

by me zajimalo, kdyz bys pretocil bit v souboru, tak jestli jeho cteni hodi chybu

Nehodilo.

btrfs raid5

Ještě nedávno to neumělo rebuild po výpadku disku, teprve ve 3.19 je experimentální podpora. Ale přemýšlím, že to asi zkusím nasadit.

[Heron]

Když mi to řekne, mohu obnovit ten soubor ze zálohy.

To by ti ten MD musel vrátit číslo sektoru, potom pokud je nad tím md nějaký LVM nebo něco bys musel najít v jakém oddílu a offsetu se to vyskytuje a potom přes debugovací fce FS najít jaký soubor tam má data.

Jako, šlo by to, ale to už je mnohem jednodušší nasadit BTRFS, kterej ti to vykecá přímo do logu.

[chsajarsa]

Zalezi na disku. Nektere disky maji sektor velky 520b s tim, ze 8b je tam pro kontrolni soucet. Takovy disk na vadny sektor prijde sam a ohlasi ho firmware toho disku.

[Jendа]

Všechny disky mají spoustu samoopravných kódů.

[Heron]

Tak možná na nějaké hodně lowlevel úrovni možná jo a pořád je to OSS, takže si to tam můžeš dopsat, ale v základním režimu to opravdu chybu čtení při recovery nepřežije.

[lertimir]

Proto je vhodné provádět pravidelné kontroly pole, kdy se skutečně všechna data přečtou, a ne je číst až tehdy, když je jeden disk v pytli. Pak se dá zachytit začátek pádu prvního disku a bez problému ho nahradit. Mě se celé pole čte jednou týdně. na 4TB discích to čtení bude tak den takže bych to četl tak jednou za 2-3 týdny.

[Jendа]

1 bit ku 10^12 až 10^15, což odpovídá zhruba 1 bitu na jednotky až desítky TB

Distribuce co jsem potkal (Debian, CentOS) pole pravidelně (cron.monthly) celé přečtou, takže se na chyby většinou přijde dřív než když pak jeden disk opravdu chybí.

A pokud to má na filmy, tak tam by jeden vadný sektor uprostřed nemusel tak moc vadit, dekodér pravděpodobně nakreslí do pár framů barevný čtvereček.

[Sten]

Ten problém je trochu jiný. Ten disk to pořád přečte, ale přečte něco jiného, než by měl, takže pro řadič to vypadá, že jsou data v pořádku, a protože nemá žádnou další paritu, která by mu řekla, že je potřeba to ještě jednou přečíst, tak je použije pro rekonstrukci pole. (Ve skutečnosti současné pevné disky kvůli fyzikálním vlastnostem tak hustého zápisu čtou každou chvíli něco trochu jiného, ale samoopravné kódy a CRC to odchytí. S pravděpodobností 10^-12 až 10^-15 ale dojde k chybě, kterou neopraví/opraví špatně.)

[lertimir]

Pokud si přečteš něco o samoopravných kódech, tak ti to řekne, že disk by špatná data "něco jiného" dát neměl. Samoopravné kódy v podstatě umožní, že když je to malá chyba, tak jsou to "provozní chyby" a opraví se bez další reakce, když je to větší chyba je to "relokační chyba" a software na řadiči by po dosažení jisté hranice chybovosti měl sektor přealokovat, a když je velká chyba, tak je to chybný sektor a řadič disku by měl vrátit chybu čtení. Protože ví, že je to chyba čtení a že nemůže dodat správná data, že je těch chyb tolik, že správná data neumí zrekonstruovat.

[Pepa]

Jenže takhle to nefunguje. Samoopravné kódy používané u disků jsou kolizní, proto si disk myslí, že vše je v pořádku, ale ve skutečnosti (dnes) průměrně jednou za 10^(14-15) není.

[Sten]

Žádná opravná data (ať již paritní nebo kontrolní) nedokáží se 100% jistotou určit chybu. Úložiště těch dat totiž trpí stejnými chybami jako úložiště dat, která opravují, jelikož oboje je uloženo na tom samém disku. Takže se klidně může stát, že poškozená budou jak původní data, tak opravná data, a to takovým způsobem, že buďto to disk vůbec nepozná nebo (pravděpodobněji) se data pokusí opravit, ale kvůli poškození vyjde něco jiného, než by mělo.

[pavlix]

Osobně jsem obětoval kapacitu a nasadil RAID6 na čtyřech discích i při menším objemu. Záleží, jaké máš požadavky.

[Petr Tomášek]

Hm a má na 4 discík RAID6 nějakou výhodu oproti RAID1+0?

[Jendа]

Mohou „bezpečně“ chcípnout libovolné dva disky, ne jen disky z různých mirrorů.

[lertimir]

Na druhou stranu je to významně pomalejší na malé soubory. Pro malý soubor (zápis), který nepokryje jeden track na dvou discích se musí nejdříve přečíst příslušná data, která se počítají do parit a pak všechno zapsat. Naproti tomu v RAID10 se jen data zapíší synchronně na dvě disky.

[pavlix]

Otázka zněla, zda má výhodu, nikoli zda je za všech okolností lepší volbou.

[pavlix]

To se ptáš vážně? RAID6 se používá kvůli jedné jediné konkrétní vlastnosti (přežití výpadku dvou libovolných disků), kterou RAID1 nemá.

[pavlix]

Přesněji řečeno kterou RAID1 nad dvěma blokovými zařízeními nemá.

[Max]

Přesně tak, a proto jsem nasadil na jednom větším poli RAD60 a né RAID50.
Zdar Max

[Petr Tomášek]

Hm, no, ale to znamená, že když v jedné půli RAID0 odejde víc než 2 disky, tak máš po ptákách. Počítal sis pravděpodobnost, oč je to bezpečnější než samotný RAID6?

[chsajarsa]

Pokud se nebavime o DDP, coz na linuxu neni, tak rozdil je v tom za jak dlouho se dana diskova skupina prepocita na spare disk. Pokud by jsi udelal diskovou skupinu treba z 50x8TB disku, tak by sis docela pockal. Uz ted neni problem cekat na dopocitani disku treba tyden.

[pavel]

Pro domaci pouziti bych nasadil RAID 1 ze dvou disku, treti disk bych pridal do pole jako hot-spare a na ctvrty bych zalohoval.

[pavel]

Nevyhoda je, ze ze 4 disku realne vyzijes jeden, ale holt za jistou miru bezpeci se priplaci...

[pavlix]

Nevím, jestli bych namísto hot-spare nepřidal ten disk jako živý, ať aspoň člověk ví, jestli je ještě ok.

[chsajarsa]

Presne tak. To je pomerne casty problem, hlavne pokud clovek ten spare-disk nenecha se tocit jako ostatni disky a ma potrebu setrit energii jeho uspavanim.

[chsajarsa]

Mozna bych radeji ten treti disk pridal do raid1 k tem ostatnim zarizenim.

[pavel]

Dotaz pro ty, co radi jednou za cas precist cele pole. Jak byste to delali?

dd if=/dev/mdX of=/dev/zero

nebo kazdy disk postupne? sda, sdb, ... dd nebo cat nebo neco jineho?

[Pepa]

echo check > /sys/block/mdX/md/sync_action

[Heron]

Nedělal bych to. Každý disk se umí postarat sám o sebe, takže pravidelně spouštět smart long test (lze to automatizovat i přes službu smartd). Já každý den pouštím short testy, jedou týdne long testy. Stačí to. Smartd potom posílá emaily, když se mu něco nelíbí, test se nedokončí apod.

Potom ještě jednou týdně běží script na kontrolu pole (automaticky v distribuci jako součást instalace mdadm). Takže minimálně jednou týdně se 2x přečtou všechny disky (jednou jako interní věc smartu, podruhé přes mdadm). Taky posílá email v případě, že mismatch_cnt není nula.

Dělat ještě třetí testy už je asi nadbytečné.

[pavel]

mel jsem na mysli /dev/null samozrejme.

[Josef Kufner]

Diskové pole pro domácí server řeším už mnoho let a k uspokojivému výsledku jsem se ještě nedostal. Buď to vyjde moc draho, nebo to neposkytne dostatečnou spolehlivost. Takže zatím jsem dospěl k tomuto:

Pro domácí server si je důležité uvědomit základní požadavky:

1. Dlouhý, ale částečný výpadek nevadí. Úplný ano, pokud se server stará o poštu a podobné kritické věci. Výpadek v rozsahu pár hodin nevadí ani úplný.
2. Objemná data nejsou časově kritická, je to málo navštěvovaný archiv, který může být chvilku nedostupný.
3. Časově kritická data jsou malá, max. desítky GB. To lze udržet spolehlivé celkem snadno.
4. Uživatelů je málo, server se většinu času fláká.
5. Disky neodcházejí zas tak často. Střední životnost je cca tři roky, ale ve stabilním prostředí při nízké zátěži i mnohem déle.
6. A to nejdůležitější: Zálohování! a dlouhodobá archivace!

Po zvážení situace jsem to tedy vyřešil takto:

• Vyřešil jsem v první řadě zálohování. Musí být automatické a inkrementální. Používám rsnapshot, každou noc se odzálohuje to důležité na vyčleněný disk. A po síti se odzálohují i notebooky a další stroje, pokud jsou zrovna online.
• Protože mám funkční zálohování, vykašlal jsem se na online redundanci. Tedy žádný RAID. Data jsem rozdělil mezi disky podle jejich logického členění (/home, zálohy, fotky, filmy, hudba) a s příchodem celkem relativně levných 4TB disků má každý mountpoint celkem přijatelnou rezervu. A také vím, co na kterém disku je.
• Pokud disk selže, znamená to pár hodin výpadek, než se data obnoví z umírajícího disku nebo zálohy. Protože jsou však data členěna do logických celků, výpadek se týká jen dané skupiny služeb poskytovaných domácím serverem. Prakticky ověřeno.
• Čas odčasu, typicky když je mi nějaký disk už moc malý, ho nahradím novým. Starý disk pak uložím jako archivní zálohu. Chtělo by to ještě offline zálohovací disk, aby toto probíhalo o něco častěji.

Je důležité mít na paměti, že se jedná o domácí prostředí a to má svá specifika. Pro velký server poskytující služby stovkám uživatelů by toto byl zcela nevhodný přístup. Pro malý server v malé firmě by to chtělo mít mnohem lépe řešené různé scénáře a volit opatření úměrně škodě, kterou by výpadek způsobil. V domácích podmínkách však stačí udržet naživu komunikaci (e-mail, Jabber) a přistup k Internetu, ten zbytek stačí být schopen obnovit druhý den.

[Pepa]

Dospěl jsem doma ke stejnému řešení, akorát důležitá data zálohuju jak na další disk tak i ven do internetu. Nevýhoda je nesdílení volného prostoru mezi mountpointy (řešení s 4TB disky (zatím) nepoužívám ).

[Heron]

To jsem zkoušel taky, ale potom jsem zjistil, že vytahování zálohy je pro mě otravné, takže jsem přešel na režim všechno na md. Mám jedno velké md raid5 (8TB), kde jen vyměním disk při selhání (teď jsem si pořídil sata backplane rámečky a nechápu, jak jsem bez toho mohl žít), což je na pár minut.

Vedle toho mám 5TB BTRFS multidevice raid 1, na které to postupně přesouvám. Cíl je zbavit se md, které má své neduhy (nepozná vadný soubor, pokaždé synchronizuje všechno, neumí se pořádně zkontrolovat) a přejít komplet na BTRFS R1. Ano, BTRFS má také svá negativa, ale v mém prostředí pozitiva značně převažují. Na tom BTRFS R1 mám různé disky tak jak mi zbyly na poličce - další výhoda, netřeba sudý počet stejně velkých disků, mám tam mix velikostí a aktuálně dokonce lichý počet.

[Pepa]

Nad konsolidací disků pomocí BTRFS taky uvažuju. Nechtěl jsem mdraid, protože nemám doma terabajty dat, které by stály okamžitě za nový disk, když by jeden selhal, přesně jak píše Josef. Jaká jsou negativa toho BTRFS při tomto způsobu použití?

[Heron]

Jaká jsou negativa toho BTRFS při tomto způsobu použití?

"Neštastné" chování při selhání disku. Zatímco v normálním stavu si můžete disky přidávat a ubírat jak chcete (samozřejmě s ohledem na volné místo a počet disků toho kterého typu raidu), tak pokud jeden disk selže, tak ten FS musíte odpojit, připojit jako degraded, udělat btrfs device delete missing, odpojit, připojit normálně. (Možná to jde udělat jako mount -o remount, to jsem nezkoušel).

Takže je tam poněkud nelogicky výpadek, což je škoda. Přitom ten btrfs i v normálním stavu ví, že nějaké device už tam není (je to vidět ve výpisu btrfs fi show). Jen ho neodstraní, to až v degraded módu.

[Pepa]

Díky. To je opravdu nešťastné. Na řešení popsaném Josefem právě oceňuju, že když přijdu o disk, ztratím na nějakou dobu přístup právě k jedné skupině dat a neovlivní to ostatní skupiny. A podle toho jak je ta zasažená skupina důležitá tak si já sám můžu určit dobu nedostupnosti. Jak se chová BTRFS při chybě čtení? Přepne FS do read-only? Líbilo by se mi kdyby šel udělat rebalance (vykopírovat z vadného disku co jde), vyhodit disk, přidat nový a obnovit zálohu a vše online (žel tohle tedy nejde).

[Heron]

Jak se chová BTRFS při chybě čtení? Přepne FS do read-only?

Přečte data z jiného disku. Jako za normálních okolností pokud jeden disk vypadne, tak nepoznáte, že nějaký disk vypadl. FS je normálně dostupný. Poznáte to jen ve brtfs fi show nebo btrfs device stats, kde jsou právě počty chyb čtení. A on ten výpadek v případě toho umount mount degraded umount mount je jen pár minut. Ano, "vypadne" celý fs, ale ta data jsou i v tom degraded režimu normálně dostupná. Jediná nedostupnost je mezi těmi remounty.

Ale mnoho zkušeností s vadnými disky nemám. Mnohem víc o tom ví místní Aleš Kapica.

[Heron]

jen pár minut

sekund

[Jendа]

A on ten výpadek v případě toho umount mount degraded umount mount je jen pár minut.

No jo, ale taky musíš zabít všechny kdo tam mají něco otevřeno.

[Heron]

Tak jistě. No ono všude je něco. ZFS je vyspělejší, otestovanější atd. ale zase nelze přidávat a odebírat disky do raidové skupiny (virtual device), jen celé skupiny. Což asi nedělá problém u bedny, která má prostor pro 40+ disků (prostě se tam budou přidávat do raidz po 6), ale u domácího case, do kterého se tak tak vleze 10 disků už je to skupinování poněkud těžko realizovatelné. Toto byl pro mě asi ten nejpodstatnější důvod, proč jsem před lety nešel do FreeBSD + ZFS.

[Pepa]

Ah, zapoměl jsem zmínit, že uvažuji jen o RAID0. Takže nebude odkud číst, tedy dokud BTRFS neimplementuje "Object-level mirroring and striping", pak bych si ty "důležitější" data pojistil. Proto by mě teď zajímalo jak se rebalance bude chovat nad RAID0 kde bude jeden disk poškozen. Cílem je abych nemusel obnovovat ze zálohy vše a přitom se nemusel starat o kopírování nepoškozených souborů mezi disky jako v případě samostatných mountpointů.

[kapo]

Už jsem to jednou řešil.

Ještě bych chtěl poznamenat, že disky se někdy chovají trochu jinak, než by člověk čekal. Stalo se mi, že jeden 3TB disk Seagate začal házet chyby a ve SMART logu se ukázalo cca 16 sektorů pod položkou Current_pending_sector. Tohle čtením nevyřešíte. Musel jsem disk vyhodit z BTRFS, pak jej celej přepsat, aby došlo k zápisu i do těch chybujících sektorů. Tím se to nějak spravilo a zas jej používám. Je to risk, ale asi nějaké slabší místo, které se zápisem oživilo.

Nevíte někdo o nějakém testu, který by provedl zápisový check disku beze ztráty dat?

[Václav Vanc]

Disk má pár(set) rezervních sektorů, které normálně nepoužívá. Když je nějaký sektor nečitelný, objeví se v "Current Pending Sector". Jakmile se do něj ale zapíše, tak se blok přemapuje do rezervní oblasti a původní sektor se přestane používat. Také zmizí "Current Pending Sector" a objeví se v "Reallocated Sector Count".

[pavlix]

Je tedy nějaký důvod ho úmyslně přepisovat?

[Pepa]

Ano jedině přepis vynutí realokaci.

[pavlix]

Obávám se, že jsem se ptal na něco jiného.

[Pepa]

Obávám se, že v kontextu celého vlákna je jasné, že jde o nečitelné sektory patřící existujícím souborům. Takže, ano je důvod proč je přepisovat.

[pavlix]

Neptal jsem se, zda je důvod je přepisovat, ale zda je důvod je přepisovat úmyslně, tedy explicitně ze strany administrátora. Jestli k tomu je nějaký důvod, tak v diskuzi zatím nepadl.

[Pepa]

Realokace se nemusí podařit, proto je lepší to dělat mimo normální použití.

[pavlix]

To zní rozumně.

[Pepa]

Ten disk (a systém) se totiž může chovat divně, když ho pořádně neotestujete a hned ho začnete používat. Minimálně dojde k zvětšení přístupové doby.

[Václav Vanc]

Jo, přístupová doba se zvedne, jak se disk ten sektor snaží několikrát přečíst než vyhodí chybu. Pak to taky plní logy. :D Jinak vadný sektory považuju za takovou předzvěst že disk brzo odejde a už na něj neukládám nic důležitýho... :)

[Pepa]

Měl jsem na mysli dobu zápisu. U čtení je to jasné. Viděl jsem i disk, který dokázal resetovat při zápisu nebo čtení vadného sektoru celý sata řadič nejen jeho port. Prostě není dobré spolíhat, že se sektory přealokují tak jak se na disk bude zapisovat při běžné práci.

Jinak disky s přealokovanými sektory pak můžou žít spousty let. Stejně už od testu ve výrobě jich má běžný disk přealokováno několik tisíc.

[Heron]

Já teda disk, který má nenulové hodnotu některých atributů dávám rovnou na reklamaci. Rozhodně bych nedoporučoval takový disk dále používat.

Offline_Uncorrectable
Current_Pending_Sector
Reallocated_Sector_Ct
Reallocated_Event_Count

Také zmizí "Current Pending Sector" a objeví se v "Reallocated Sector Count".

No, tak by to mělo fungovat, leč výrobci disků si vykládají smart atributy po svém a to ještě u každé řady jinak. Takže například dokážou zázrakem realokovat sektor a přitom nevyvolat event apod. No, je to spíš smutné. Aby toho nebylo málo, tak soft od WD pro widle dokonce vymaže tabulku hodnot, takže ten disk (který je normálně na reklamaci) se pro prozkoumání nástrojem od WD tváří ve smartu jako nový.

[kapo]

Tak u mě tohle byl právě ten případ, že po přepsání celého disku zmizely sektory z Current_Pending_Sector, ale v Reallocated_* se nic neobjevilo. Takže taky asi prasárna. Pro info se jedná o tento disk.

Model Family:     Seagate Barracuda 7200.14 (AF)
Device Model:     ST3000DM001-1CH166
Firmware Version: CC27

[Jendа]

To mi nějaký notebookový 250GB Seagate z 2010 (nechce se mi ten notebook vybalovat a bootovat) udělal taky.

[paul2no]

Mně se už někdy dávno u disku (Hitachi) v notebooku objevilo Reallocated_Event_Count = 2, ale žádný sektor realokován nebyl (ani není žádný podezřelý), ale to číslo se už minimálně dva roky nezvyšuje, tak to neřeším.

Docela by mě zajímalo, co to způsobilo.

[kapo]

Myslím si, že je. Pokud se zápisem sektor "oživil" a ne potichu realokoval, tak by tímto způsobem docházelo k refreshi, stejně jako v DRAM čipech :).

[pavlix]

Považoval jsme v kontextu diskuze za předpoklad, že se neoživil, ale relokoval.

[Pepa]

Ano to je teorie a většina disků se tak chová. Ale mám i několik disků, které mají "Current Pending Sector" ve stovkách a byly 100x přepsány rw badblockem a jsou bez chyby. Dalším zmizí "Current Pending Sector" a neobjeví se v "Reallocated Sector Count". Je to různé podle výrobce a/nebo firmware.

[Pepa]

badblock má nedestruktivní rw test.

[trubicoid]

tojo, ale ten se neda pouzit, prvne totiz cte a kdyz data neprecte, tak ani potom nezapise

ten nedestruktivni test delal mhdd, nekolikrat jsem ho pouzil, kdyz blok nemuze nekolikrat precist, tak ho zapise

mhdd je/byvalo na systemrescuecd, ale chtelo prepnout v biosu ahci na ide

jeste existuje whdd, to jsem ale jeste s prepisovanim nezkousel

spis se mi zda lepsi proste celej disk prejet badblock -w

[Josef Kufner]

Jak často ti disky odcházejí?

[Heron]

Dost často na to, aby mě to štvalo. Reálně nevím. Jeden dva do roka.

[Josef Kufner]

Aha, tak to jo. Já to mám tak jeden za dva roky.

[Pepa]

Tak to já zatím jen přidával a malé odebíral

[Josef Kufner]

Neboj, ono to přijde. Ten poslední, co mi odešel, sloužil sedm let. Pokud máš sedm disků s takovou životností, je to každý rok jeden.

[Pepa]

Tak v práci kde jich mám 500+ to znám, ale doma jich mám 4 v serveru 24x7 a 4 ve stanicích a zatím dobrý. Holt šťastná ruka

[pavel]

Domaci server jsem vyresil jinak. Predne - celkove nemam tolik dat, abych potreboval nekolikaterove disky. Vsechna ma data maji radove stovky GB, pricemz opravdu dulezitych dat je jen par desitek GB (fotky, dokumenty, zdrojove kody k soukromym projektum apod.).

Takze mam v serveru 2x1TB disk v Raid-1 (Westerd Digital Red). Je to systemovy disk a zaroven datovy disk. Na zalohy mam externi disk 1 TB WD Red.

Zalohovani obstarava Bacula, 1x tydne full (par desitek GB), 1x denne differential. Zpetne drzim 4 fully.

Zvlast se zalohuje moje Git repository - 1x denne full (jednotky GB).

Zaloha multimedii (hudba, filmy) neni scheduled, tu spoustim z bacula-console rucne, kdyz se mi zachce.

Jeste jsem nemusel resit disaster recovery, ale jiz jsem zalohy potreboval, kdyz jsem si neco omylem smazal. Prilezitostne zalohy rozbalim, abych otestoval jejich funkcnost.

[lertimir]

No moje řešení je následujicí. Zdroje dat jsou:

1. standardní systémová a uživatelská data. Systémové a /home adresáře na 3 desktopech a 4 noteboocich v rodině
2. Velkoobjemová data vysoké důležitosti. V podstatě archiv fotek nyní cca 600GB
3. Velkoobjemová data nižší důležitosti. důležitá multimédia
4. Postradatelná data, multimedia zbytek

bod 1. Zálohovací systém BackupPC jedoucí na domácím serveru. data skladována na 500GB oddílu s RAID 10. BackupPC má tu výhodu, že skladuje data pod hash hodnotami tady v záloze je soubor jednou i když je fakticky na několika počítačích, což je výhoda, když mám stejný systém a kopie uživatelských účtů mezi systémy. fakticky se provádí rsyncem. Automaticky se dělá každé dva dny s tím že se provádí fullbackup a následně inkrementální backupy urovně 1,2,3,4 postupně 3 krát za sebou a pak zase fullbackup. s tím, že jsou drženy 2 full backupy a inkrementální backupy za posledních 60 dní. (pokud někdo se potřebuje vrátit v čase). Pro restauraci dat je system transparentní. Webové rozhraní, kterým si vyberu jakou zálohu chci restaurovat a jaký soubor/adresář/strom a kam. Každá záloha mi zobrazí vše. Zálohuje se root a /home, bez video souborů. Současně zabírají data cca 280GB

bod 2. stále držená synchronní kopie na dvou interních discích stanice, RAID 5 poli serveru a méně často synchronizovaná kopie na externím systému mimo byt.

Bod 3. Data držená na raid 5 poli serveru.

Bod 4. Data v jedné kopii na některém interním disku stanice.

[dustin]

A když se dá ten backuppc na degradovaný raid1, stačí připojit externí disk přes esata kolébku a se zapnutou write-intent bitmapou je offline kopie hotová za chvíli.

[lertimir]

No asi bych nikdy neriskl mít důležitý backup jen na jednom disku. Pokud bych tuhle externí zálohu potřeboval, tak pustím dd na backuppc oddíl v časovem intervalu, kdy se na něj nepíše a připojím do esata dokiny disk. Ještě bych doplnil týdně jede kontrola Raidového pole. týdně jednou short testy a měsičně jedou long testy na všech discích.

[dustin]

Ve skutečnosti máme dvě sady těch offline kopií (je to několik disků v raid0) a střídají se po týdnu. Aby mohly využít write-intent bitmapu (která zásadním způsobem zkracuje synchronizaci), jsou tam ty degradované mirrory dva, spojené do hlavního mirroru, na kterém je teprve filesystém. Běží nám to takto ve firmě už řadu let, několikrát byl ze záloh hlavní backup server obnoven (většinou při resizu na větší).

Backuppc nám něco zálohuje neustále, je nereálné jej shazovat kvůli dd přes několik velkých disků.

Samozřejmě ten backup server jede také na polích s redundancí (raid1+0), disky odcházejí a obnova z offline kopie je přeci jen podstatně pracnější než jen vyměnit disk a zasynchronizovat.

[pavel]

Mluvis jeste o "home" reseni?

[dustin]

Pravda, home už tohle není. Ale raid1 na offline disky (ideálně 2 + missing) je i pro home jednoduché řešení.

[Pepa]

Ale na některá data zbytečně drahé.

[dustin]

To asi jen na data, která nechci mít v offline kopii vůbec. V čem je to jinak dražší než kopírování? Na obojí je potřeba další disk, který neběží permanentně v kompu.

Reagoval jsem na příspěvek o backuppc. To ve svém poolu všude využívá hardlinky a bez raidu se špatně zálohuje. Samozřejmě lze použít rsync -H, ale ten je při velkém počtu souborů, jež se v backuppc při každodenních zálohách nastřádají, dost náročný na paměť.

[Pepa]

Nejsme ve sporu, já zas reagoval na domácí zálohování, kde pro některá data je ten disk zbytečně drahý.

[dustin]

Tak záloha, která není mimo komp, moc zálohou není. A na to je prostě nějaký další disk potřeba.

[pavel]

Zalohuji po 20m dlouhem USB kabelu, takze zaloha je mimo komp, ale ve stejnem byte. Je to ok?

[Mrkva]

Hint: blesk, povoden, pozar...

[pavel]

Blesku se nebojim, mam UPS integrovanou prepetovou ochranou. Predpokladam, ze nekde vevnitr je to galvanicky oddelene.

V pripade vody nebo ohne me budou vic mrzet fyzicke statky (vybaveni bytu, diplomy, apod.) nez data.

[Jendа]

Predpokladam, ze nekde vevnitr je to galvanicky oddelene.

jj, je tam žárovka a solární panel.

[Mrkva]

Blesku se nebojim, mam UPS integrovanou prepetovou ochranou. Predpokladam, ze nekde vevnitr je to galvanicky oddelene.

Jako vtip dobry, ale jinak totalne mimo.

V pripade primeho zasahu bleskem (pripojeni pres wifi a zasah anteny a podobne). ti s vysokou pravdepodobnosti z te UPSky a PCcka moc nezbyde. V pripade blizkeho uderu blesku (svedeni hromosvodem na dome nebo tak neco) ti ale prepetovka moc nepomuze. Troska matiky:

Maximalni zemni odpor hromosvodu podle platnych norem je 10Ohm. Bleskovy proud muze byt klidne 100kA. To znamena napeti mezi hromosvodem a zemi je s klidem 1MV. A ted si predstav ze budes mit mezi hromosvodem a zemi cestu s odporem radove 1kOhm - coz se klidne muze stat v pripade spojeni anteny na strese s hromosvodem a podobne. Touhle cestou = napriklad po TV koaxu ti potece 1kA. To se sice bude dal v rozvodech rozkladat do dalsich paralelnich vedeni ale stejne to s dost vysokou pravdepodobnosti skonci nutnosti rekonstrukce alespon casti elektroinstalace. Predstava ze prepetovka v nejake UPSce tohle ustoji mi prijde krajne naivni.

Nehlede na to ze prepetovka ti resi napeti ktere se na misto dostava po dratech. Neresi a ani nemuze resit vliv elmag. poli. Tady mas obrazky jak dopadne CRTcko - magneticke pole vyvolane uderem blesku do hromosvodu zmagnetizovalo mrizku natolik ze vznikl takovyhle krasny barevny efekt.

Ale obecne je to i trosku o nahode. Doma jsem si hral s impulznim zdrojem vysokeho napeti (tak do 300kV, vic jak 30cm to nelitalo) a naindukovane pole odsmahlo zdroj k externimu 3.5" disku. V druhem pripade vyboj preskocil pres VN zdroj do napajeciho zdroje kde to na vstupnim filtru speklo fazi a nulu a akorat to vyhodilo pojistky a nic vazneho se nestalo.

Jinak, ad galvanicke oddeleni - ne nutne :)

[Heron]

Predpokladam, ze nekde vevnitr je to galvanicky oddelene.

Jak v které. Některé mají trafo zapojené jako autotransformátor, tím regulují změny napětí v síti tak, aby na výstupu bylo přibližně stejné. Takže oddělení žádné. Některé mají klasické trafo, s izolací pochybnou Integrovaná přepěťová ochrana v UPS je na dvě věci, pokud elektroinstalace v domě neobsahuje další ochranné prvky (ochrana proti přepětí se dělá jako postupná kaskáda, kde každý další prvek sníží velikost vlny na nějakou hodnotu, jestli tohle v elektroinstalaci není, tak ten MOV v UPS nebo ve zdroji nic nezmůže).

[pavlix]

Je to ok?

Jediný, kdo může na tu otázku odpověďět, jsi ty.

[chsajarsa]

Protože mám funkční zálohování, vykašlal jsem se na online redundanci. Tedy žádný RAID. Data jsem rozdělil mezi disky podle jejich logického členění (/home, zálohy, fotky, filmy, hudba) a s příchodem celkem relativně levných 4TB disků má každý mountpoint celkem přijatelnou rezervu. A také vím, co na kterém disku je.

Jeste si dovolim poznamenat, ze zalohy je treba kontrolovat. Pokud nastane silent corruption, tak se ti s prehledem muze stat, ze budes zalohovat/archivovat poskozena data aniz bys to vedel. V momente, kdy ti vyprsi retence te zalohy, tak zjistis, ze spravna data proste nemas. Videl jsem to nekolikrat u zakazniku a vetsinou to vedlo ke ztrate dat.

[Josef Kufner]

A je nějaký snadný způsob, jak se tomu bránit v domácím prostředí?

[Jendа]

Já jsem kritické zálohy protáhl přes par2. Spočítá ti reed-solomon kódy.

[Jendа]

A není to ani tak kvůli silent corruption, kterou jsem ještě neviděl (od včerejška pořádně monitoruju asi 50 TB, tak uvidíme, co se zjistí), ale spíš proto, že z odcházejícího disku nejspíš půjde data přečíst až na pár sektorů.

[chsajarsa]

Já už jí viděl. Sice ne mockrát, ale občas se to objeví. Docela je módní to teď řešit. Hlavně kvůli deduplikaci je to módní téma.

[Jendа]

Super, z kolika disků za jak dlouho?

[Jendа]

(a nebyla to write hole po výpadku proudu?)

[chsajarsa]

Po výpadku proudu určitě ne, ale po výpadku disku v raidu 5. Mám podezření, že tam byla špatně uložená/prectena parita. Protože od toho dne se jen jeden konkrétní virtual mezi asi 20 ve špatném stavu i zálohoval. Jasně může to mít milion dalších příčin a nemusí jít jen o ten disk. Potíž je v tom, že se to dost špatně určuje kdy a proč to vzniklo.

[dustin]

A opravdu to tedy byla silent corruption? Spíš bych si tipoval na klasické neuložení bufferů nebo tak.

[Petr Tomášek]

Hm, škoda, že něco takového není integrováno přímo do RAIDU...

[Pepa]

Dá se použít třeba SnapRAID.

[Josef Kufner]

To vypadá vcelku zajímavě. Díky.

[pavel]

Mam md-raid 1 nad SSD. Bohuzel jsem pri instalaci nenechal volne misto na konci disku. Je to vazny problem? Filesystem (ext4) mountuji s discard.

[trubicoid]

to je na novy tema, ne?

jinak overprovisioning se doporucuje, zmensi si to