Dotaz: BTRFS na domácí NAS

[Fredy72]

Koukal jsem, že u BTRFS byly zavedeny nové raid módy. Už jsem si i ve virtuálu zkusil, že je jde použít nezávisle (mkfs.btrfs -m raid1c4 -d raid6). Uvažuji o novém domácím NASu, tak se chci zeptat znalejších, zda tímto získám nějakou výhodu (pročetl jsem https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg91879.html), když data nechám na raid6, čímž uspořím nějaké místo při třeba 6 discích, těch dat by se možné problémy týkat neměly, a pro metadata a system bych použil raid1c4, čímž si myslím, že bych eliminoval jejich porušení. Je má úvaha správná nebo tím raid1c4 nic nedosáhnu?

Odpovědi

[Andrej]

mkfs.btrfs -m raid1c4 -d raid6

Stačí -m raid1c3 -d raid6.

[Nobody.]

Hohoho. Tomu říkám rady pro robustní systém 21. století! Po tomhle čtení bych se vyhnul RAID modům BTRFS na sto honů. Sparse disky přidávat po failu? WTF?! Takže napsat si vlastní okopávače, abych ráno nečuměl jak puk na rozpadlé pole. Yu made my day, bro!

[Andrej]

Po tomhle čtení bych se vyhnul RAID modům BTRFS na sto honů.

Nějak špatně čteš. Pokud by ses chtěl vyhýbat Btrfs RAIDu na sto honů, musel by ses pak vyhýbat taky všem ostatním (R)AIDům asi tak na tisíc honů (ať už to s honěním souvisí jakkoliv):

"…btrfs raid5 is quantitatively more robust against data corruption than ext4+mdadm (which cannot self-repair corruption at all)…"

Drobné shrnutí faktů:

1. RAID je spolehlivější než jeden disk.
2. Skutečný RAID, například v Btrfs nebo ZFS, je spolehlivější než rádoby-RAID typu mdadm / dmraid.

Otázka je vždy stejná: S čím srovnáváme? Samozřejmě, že Btrfs má nedostatky. Jak závažné? Ve srovnání s čím? Který obdobný software nemá nedostatky?

(Já osobně mám Btrfs s -d raid5 -m raid5 už cca 5 let, disky jsem v tom měnil, žádný problém se nikdy nekonal. Jistě to není dokonalé, ale je to pořád lepší než mdadm / dmraid.)

Takže napsat si vlastní okopávače, abych ráno nečuměl jak puk na rozpadlé pole.

Vypadá to, že máš požadavky mimo realitu, špatnou představu o rizicích a jejich vzájemném porovnání, nebo možná obojí. Čumění na rozpadlé pole čeká s mnohem větší pravděpodobností toho, kdo nepoužije Btrfs.

[jiwopene]

RAIDu v btrfs pořád nějak moc nevěřím, ale je možné, že se zlepšil.

Doporučil bych spíše ZFS, který je btrfs celkem podobný. Z důvodu licence nekompatibiliní s GPL není v Linuxu, musí se doinstalovat zvlášť.

[trekker.dk]

Jeden z vývojářů BTRFS pár měsíců zpátky řekl, že

RAID 5 and 6 have "lots of edge cases", though, and have been famously unreliable.

[Nobody.]

Zatímco my roky bez problémů používame mdraid6 s filesystémem z minulého století, XFS. V současné době 40TB dat, týdně kontrolované AIDE. Jeden týden CRC32, druhý MD5 (teď už by CPU upočítali i lepší hashe). A za těch 15 let ani jedno data corruption, asi zázrak. Obyčejné rychlé SAS disky na HBA LSI.

[bigBRAMBOR]

jenze takovej jsi jeden z milionu, ostatni maji data corruption nekolikrat denne

[Petr Fiedler]

A věříš vůbec na silent data corruption?

[Andrej]

Já například nevěřím na autonehody. Nikdy se mi totiž žádná nestala. Autonehody proto neexistují.

Tohle^^^ zní úplně stejně hloupě jako následující:

A věříš vůbec na silent data corruption?

Nevím, jak předřečník, ale já v silent data corruption rozhodně nevěřím — ani trochu. Věřit se totiž dá jedině v to, co je neověřitelné.

Silent data corruption je ovšem ověřitelný, nesčetněkrát pozorovaný, statistikou "modelovatelný" a fyzikou vysvětlitelný jev. Není to nic, v co by se dalo (ne)věřit.

[Petr Fiedler]

No já si teď brzy budu kupovat novou sestavu a s ohledem na silent data corruption do ní chci pořídit paměti s ECC. A časem chci přejít na Btrfs. Z počátku budu ale muset zůstat na ext4, protože Btrfs asi nestihnu nastudovat a vyzkoušet. Mám teď v plánu dát Mint na volný HDD s Btrfs a hrát si s tím a simulovat různé problémy, abych pochopil co a jak. Až pochopím, tak na Btrfs konečně přejdu. A právě kvůli silent data corruption. Takže pak budu s tebou, Alešem, Heronem a lertimirem tento fs bránit proti zbytku světa.

[Peter Golis]

V tom prípade odporúčam použiť ku tradičnému RAIDu aj dm-verify. Už sa to tu rozoberalo viac krát, v súvislosti s rovnakou diskusiou (BTRFS versus zvyšok sveta). A asi táto diskusia nikdy neskončí.

[Petr Fiedler]

RAID používat nebudu. Alespoň zatím ne, ale možná časem změním názor. Po instalaci OS a jeho nakonfigurování udělám jeho snapshot a pro jistotu jej zazálohuji Clonezillou. Data (datový oddíl) budu denně syncovat a jednou za čas udělám zálohu dat. Časem možná zjistím, že RAID by byl lepší a pak se podle toho zařídím. Zatím s ním ale nemám vůbec žádné zkušenosti a ani plně nedokážu posoudit, jestli jej potřebuji, nebo ne.

[Peter Golis]

Pokiaľ sa ti v priebehu mesiaca pokazia dáta, tak si zlou verziou môžeš zlikvidovať korektné dáta pri ich synchronizovaní. Pozor na to.

Ohľadne syncovania, tak Ubuntu furt nútia užívateľa aby si nastavil nejaký backup cez to ich klikátko (deja-dup a podobne). Len pozor na automatické mazanie ak bude málo miesta, ževraj prebije retenciu.

PS: Zálohovanie a archivácia chránia nielen pred strojovou chybou, ale aj pred používateľovou chybou. Veď kto si ešte nikdy neprepísal potrebné dáta pomocou nejakého balastu, že?

[Petr Fiedler]

Pokiaľ sa ti v priebehu mesiaca pokazia dáta, tak si zlou verziou môžeš zlikvidovať korektné dáta pri ich synchronizovaní. Pozor na to.

Tím myslíš silent data corruption, nebo chybu uživatele?

[Peter Golis]

Obidvoje, ale väčšiu pravdepodobnosť má tá druhá možnosť. Závisí ale aj od použitých parametrov pre rsync, menovite od parametra --ignore-times či jak sa to volalo.

[Petr Fiedler]

Co se týká silent data corruption, tak v budoucnu to budu mít pořešeno díky RAM s ECC a Btrfs.

Co se týká té druhé varianty, tak zatím dobrý. V systému mám nastaveno, aby se při mazání souboru nepoužil koš a nemůžu si vybavit, kdy jsem toho litoval. Kdysi ano, ale už je to spoustu let nazpět. Takže při synchronizaci, nebo zálohováni ani neverzuji, ale zrcadlím a zatím OK.

[Peter Golis]

Zaujímalo by ma, ako RAM s ECC ochráni pred chybou vzniknutou preletom polárnej žiari (aurora borealis je mrak elektrónov letiaci od slnka) cez CPU Cache (už nezvyknú mať ECC paritný bit), alebo pred chybou na disku ktorú firmware nereportuje (aby náhodou neboli reklamácie). Rád sa dozviem niečo nové.

[Petr Fiedler]

Tak nahoře jsi mi napsal:

Pokiaľ sa ti v priebehu mesiaca pokazia dáta, tak si zlou verziou môžeš zlikvidovať korektné dáta pri ich synchronizovaní. Pozor na to.

Takže co můžu dělat pro ochranu svých dat ve vztahu k aurora borealis, nebo chybě na disku, kterou fw nereportuje? Jak můžu tedy dávat "pozor"?

[Peter Golis]

A koľko dát má vôbec cenu vyššiu ako sú náklady na jeden externý disk?

Teda okrem vyladenia OS, to je v tvojom prípade nadštandardne kvalitné. Skôr mám na mysli úrandé dokumenty, fotky z dovolenky kam sa už človek asi nevráti a spomienky na spoločné akcie (dovolenka, výročné stretnutia s blízkymi). Technické poznámky máš minimálne na dvoch miestach, doma a v blogoch (aj rozpísaných).

Sporenie sa dá preinvestovať aj inak, ako na zálohy internetu.

PS: kedysi si ľudia zálohovali dáta aj na pásky pre DV kameru. Ak ju mali, tak to médium bolo lacné. A dosť ľuďom stačilo to 4G alebo 8G čo poskytovala páska.

[Petr Fiedler]

Zatím mi jde pouze o úřední dokumenty.

[Heron]

Zvláštní.

Na jednu stranu úzkostlivě řešíš Silent Data Corruption, což se projevuje tak na úrovni desítek TB dat (ECC paměti na našich serverech hlásí tak 3 chyby ECC do roka, jednotky TB RAM) a na druhé straně vůbec neřešíš chybu lidskou, která se projevuje mnohem častěji.

Zrcadlení snad ani není forma zálohy. Data se ze zálohy vytahují typicky jedině proto, že člověk něco omylem smaže nebo přepíše. Zrcadlení, jak už tu někdo správně upozornil, prakticky znamená, že na nalezení chyby máš maximálně měsíc, potom si data pokazíš i na záloze.

Navíc jen jedna záloha? Tj málo. Pro obyčejné uživatele preferuji model mít dvě zálohovací média (disky) kdy jedno z nich je offline a druhé online. Nemůže se tedy stát, že by přišel o data na originálním úložišti a na obou zálohách současně. Vždy je jeden zálohovací disk odpojen. Uživatel si to střídá třeba po týdnu, nebo jak uzná za vhodné. Zálohy jsou pochopitelně verzované, takže tam má několik týdnů nazpět.

Myslím si, že by to chtělo přehodnotit celý přístup k problému. Nedává smysl řešit ECC, csum a fw disků s tím, že se k datům chováš tak jak popisuješ.

[Petr Fiedler]

Napsal jsem to nepřesně. Mám to teď takto:

V pc mám datový oddíl, který syncuji na NAS (RPi+HDD). Používám k tomu program FreeFileSync. V něm lze nastavit 4 druhy synchronizace:

• Databáze
  

  Rozpoznat a provést změny na obou stranách
  Odstraněné, přesunuté, nebo přejmenované soubory a
  konflikty budou detekovány automaticky pomocí databáze.

• Zrcadlení
  

  Vytvořit zrcadlovou kopii levé složky tak, aby po
  synchronizaci pravá složka přesně odpovídala levé.

• Aktualizace
  

  Kopírovat nové a aktualizované soubory do pravé složky.

• Vlastní
  

  Nastavení vlastních pravidel synchronizace.

Já tedy používám typ "Databáze". Když na datovém oddílu v pc něco přibude, tak ten den večer spustím sync. Když něco smažu/změním, tak se na NASu daný soubor po synchronizaci přemístí do koše. Jednou za čas, když zapnu nb, spustím sync i tam. Pokud na datovém oddílu v nb přibude soubor, nebo pokud něco změním, tak před vypnutím nb provedu sync. Výsledkem tedy je, že mám naprosto stejná data mezi pc, NAS a nb.

Dále mám ext. HDD, který mám rozdělen na 2 oddíly. Na prvním nešifrovaném mám zálohy šifrovaných operačních systémů (pc, nb a flash). Na druhém, šifrovaném oddílu mám zálohu dat, kterou pořizuji tak jednou za 2-3 měsíce. Před tím tu předešlou smažu.

V pc mám ještě další HDD, který je celý šifrován a na něm je vždy aktuální obsah toho externího HDD. Tento HDD zapínám pouze pro zálohování.

Nejsem tedy chráněn např. proti požáru. To ještě budu muset pořešit. Ale proti selhání hw bych řekl, že ano. Takto mi to zatím stačí. Jak jsem psal, už roky jsem nelitoval, že bych něco smazal a pak to potřeboval. Vlastně důležité dokumenty z úřadů vůbec nemažu. Ty jen přibývají, takže tady chybu udělat nejde. Člověk se sice může umáznout, ale pak to není problém okamžitě obnovit. Situace by byla jiná, kdybych např. programoval a pracoval na nějakém projektu. Tam by se hodilo mít každodenní stav toho projektu zazálohován. Člověk něco smaže, po čase zjistí, že to bylo správně a při mém současném způsobu zálohování a syncování by to mohl psát znovu. Ale to zatím není můj případ, takže jsem v klidu. Ten čas ale možná nastane a pak se zařídím úplně jinak.

[Heron]

Časem možná zjistím, že RAID by byl lepší

Lepší vůči čemu? Vůči tomuto?:

Data (datový oddíl) budu denně syncovat a jednou za čas udělám zálohu dat.

To je úplná blbost. RAID a záloha jsou kompletně oddělené věci a jedna nenahrazuje druhou. Tj RAID není ani lepší, ani horší, protože toto nesnese srovnání.

RAID může být používán ke spoustě účelům, někdo preferuje nepřerušený běh služby, někdo jiný rychlost, někdo velikost v případě paritních raidů. Ale zálohy jsou stále nutné, tak jako byly vždy. Největší podíl na vytažení záloh je chyba uživatele. To RAID fakt nezachrání.

Toto ve skutečnosti pomáhají řešit moderní FS jako je BTRFS, lze dělat snapshoty tak často, jak je to potřeba a uživatel si může sám listovat časovými snapshoty a najít si smazaný / přepsaný soubor.

Ale ani toto nijak nenahrazuje řádnou zálohu.

[Petr Fiedler]

Spíše vůči tomuto:

Po instalaci OS a jeho nakonfigurování udělám jeho snapshot a pro jistotu jej zazálohuji Clonezillou.

Já dělám zálohy OS Clonezillou jen po upgradu systému. Takže např. po upgradu z Mint 20 na Mint 20.1. Člověk udělá zálohu a pak toho v OS spoustu změní. Když by těsně před vydáním Mint 20.2 odešel HDD, tak bych sice mohl na nový HDD obnovit tu zálohu, ale musel bych toho spoustu dolaďovat. U RAIDu by to mohlo odpadnout. IMHO. Moc o tom nevím.

Jinak právě jsem si uvědomil, že bude dobré zálohovat OS i těsně před tím upgradem. Až budu používat Btrfs, tak snapshoty budou docela komfort.

[Max]

Mně měsíční scrub občas opraví 1MB dat na cca 90TB poolu. Bavíme se o ZFS. Podrobnější info v blogu: ZFS : Stavba a zkušenosti se ZFS storage
Zdar Max

[Jendа]

Zkoumal jsi, jak ty chyby vypadají? Je to bitflip? Nuly? Když ten stejný blok přečteš stokrát po sobě, dostaneš pokaždé stejný výsledek? Jaktože disk nevrátí CRC error?

[Max]

Vzhledem k tomu, že mi na tom serveru občas v kernel logu přistane, že chyba v konkrétním modulu ramky a samotné disky také občas chybují a vyhazují chyby (podle toho, jak odcházejí), tak jsem to hlouběji nezkoumal. Měl mi už dávno přijít nový storage (zpoždění už pár měsíců) a nyní konečně dojde. Takže až bude nový storage, bude čas si hrát dál se starým.
Zdar Max

[Andrej]

týdně kontrolované AIDE

Iluze jistoty je horší než absence jistoty.

Jak je userspace chráněný před čtením poškozeného souboru, který se poškodí mezi týdenní kontrolou a následným čtením? (No jasně. Nijak.)

Jak je vyřešená ochrana dat po zápisu do souborů, mezi změnou a následným týdenním checksumováním? (Checksum se udělá z toho, co tam za týden je…? Aha. No jo.)

Zkrátka, když podivné, víceméně custom řešení dělá něco, co má správně dělat filesystém v kernelu, je to celkově na houby.

A za těch 15 let ani jedno data corruption, asi zázrak.

Pravděpodobnost a statistika 101: Kdyby se něco významného dělo v něčem tak titěrném jako 40 TB, byl by stav hardwaru nejspíš velmi špatný.

[jiwopene]

Pokud bych řešil nějaké větší úložiště, volím ZFS. Btrfs má pořád co dohánět: nemá šifrované (v terminologii btrfs) subvolumy, subvolume nemůže obsahovat jiný souborový systém než btrfs (ZFS umí subvolume vystavit jako blokové zařízení v /dev, funkčně je to ± totožné s LVM), pohodlné nastavení komprese, spolehlivý RAID (btrfs v jeho RAID1 mě celkem potrápil), spare disky, …

ZFS tedy funguje jako kombinace LVM s dm-crypt a btrfs. Uvnitř je to asi trochu složitější řešení, ale správa je snazší a, podle mých současných zkušeností, se zdá být spolehlivější.

Oproti tomu ZFS má také svoje mouchy – paměť použitá jeho cache se tváří jako použitá, což by na souborovém serveru nemělo vadit. Trochu větší problém je nemožnost zmenšit oddíl se ZFS.

[majales]

Ano, arc cache se tváří jako obsazená paměť a na *BSD systémech nelze uvolnit bez restartu. Vlastní zkušenost s pFsense se zfs a uptime 300 dní+ .Ovšem arc cache se dá limitovat v konfiguraci OS.

[Aleš Kapica]

Můžeš mi vysvětlit, proč si promítáš do Btrfs svoje vlastní představy o hybrydním FS?

[Fredy72]

Tak samo, že ZoL sleduji, dolaďují v2.0, ale přišlo mi dost hlášení v issues.