Domaci NAS v2 -> v3

23.1.2018 12:13 | Přečteno: 1820× | nas | poslední úprava: 23.1.2018 16:11

Je tomu par rokov, co som tu riesil stavbu domaceho NAS-u.

Nakoniec som skoncil s 2x4TB diskami v nasledovnom rozlozeni:

• md0 /boot mdraid1 + ext3
• md1 / mdraid1 + btrf
• sda4+sdb4 /data btrfs_raid1

Dlho to fungovalo OK, asi najma z dovodu, ze sa ten NAS pouzival vyhradne ako NAS a skoro sa na neho nesahalo. Inu casy sa menia a ja som potreboval na tom stroji rozbehnut par veci v docker-i a celkovo som ho teraz zacal viac pouzivat ako server. Plus par nekorektnych shutdown-ov, no, skoncilo to nasledovne:

[ 2765.719548] BTRFS critical (device sda4): corrupt leaf, slot offset bad: block=3997250650112, root=1, slot=48

[ 2765.731772] BTRFS error (device sda4): failed to read block groups: -5

[ 2765.781993] BTRFS error (device sda4): open_ctree failed

Super. Skusil som to mountnut na 1000 sposobov, ro, degraded, recovery, nic. Skusil som oba disky zvlast a vyzera to tak, ze chyba sa spolahlivo zreplikovala na oba. Na btrfs mailingliste odozva pomala, tudiz som kupil dalsi 4TB disk a zapocal btrfs restore. Zatial to vyzera dobre a mal by som minimalne tie najdolezitejsie veci obnovit bez strat.

Otazka teraz znie, co dalej. Uz sa asi nechcem uberat cestou RAID1+zaloha v trezore, ale radsej jeden disk pracovny, jeden ako (denna) zalohoa v nas-e a jeden ako (mesacna-polrocna) zaloha v trezore. Schema teda A->B----->C

Dalsia otazka je, aky filesystem zvolit na jednotlive disky.

U pracovneho disku (A) potrebujem relativnu volnost, deduplikaciu a asi radsej aj snapshoty. Tam si asi moc vyskakovat nemozem a asi zase pouzijem btrfs, teraz uz len ako single disk (a pouzijem najnovsi kernel).

U (online) zalohovacieho disku B je to zlozitejsie. Btrfs tam na 100% po tejto skusenosti nechcem. Ext4/xfs su stare overene filesystemy, z ktorych tie data v pripade pruseru pojde snad nejak vydolovat, blbo su na tom s checksumami a nie su nijak odolne voci bitflipu. Zvazujem teda skusit ZFS. Zalohovat budem asi pomocou bup, takze deduplikaciu mam vyriesenu na urovni zalohovacieho nastroja a nepotrebujem ju od filesystemu. Takisto nepotrebujem taku volnost s multidevice ako na pracovnom disku.

Disk do trezoru C je takisto nevyriesena tema s identickymi otazkami ako u disku B.

Pouziva niekto podobnu schemu/kombinaciu filesystemov a podeli sa o skusenosti? Nejake ine napady a doporucenia?

Diky        

Komentáře

[Aleš Kapica]

Nic proti, ale jsi blázen. Už ta tvá první konstelace byla na palici. Opravdu si myslíš, že z hovna upleteš bič se kterým budeš práskat až budou uši zaléhat? Tak mi to totiž připadá.

Použít dva pomalé fyzické rotační disk, zpomalit je rozsekáním na menší diskové oddíly, zreplikované různou technologií. Nad nimi souborový systém který se pro daný účel vůbec nehodí a ještě nad tím nasadit docker… No potěš koště. Víš o zfs vůbec něco, krom toho že ho tady někteří vychvalují do nebes?

[msk]

Viem o nom akurat to, ze by to mal byt relativne bezpecny cow fs so snapshotmi a vacsou odolnostou proti chybam vratane bitflip-u a pre mna nepouzitelnou deduplikaciou (nas ma len 8g ram). Osobna skusenost okrem par malinkych pokusov veskera zadna. Rad si necham poradit.

Inak nechapem co bolo na prvej konstalacii na palici. Ako sa disk spomali rozsekanim na particie? Dve rozne technologie mirroringu bol pokus, 4 roky nebol problem, potom chcipol ten fs co si robil raid1 sam. Onehda davno tu (alebo na roote) blogoval Heron, ktory mal v NAS-e len btrfs a nemal s nim absolutne ziaden problem, tak som to proste skusil a spalil sa.

[Aleš Kapica]

No jo. Jenomže ono to taky vyžaduje solidní HW, poměrně dost paměti a taky víc než dva disky.

Co bylo na palici?

No tak především ses měl rozhodnou jestli nasadit md raid 1, NEBO btrfs raid 1. Ve tvém případě bych zvolil asi md raid 1. Nasadit obojí znamená, že se ti budou mezi sebou prát IO přístupy. Trochu představivosti prosím. 4TB disk je určitě rotační a pochybuji že by měl alespoň 7200 otáček. Hlavičky kmitají. Když máš jeden diskový oddíl a nad ním raid, zapíše systém data z fronty na blokové zařízení a jádro už se postará, aby se pak sapsaly nejprve na jeden a potom na druhý disk. Pokud máš ale nad stejnými disky souborový systém co rovněž dělá raid, tak do toho vstupují další operace, které by byly jinak úplně zbytečné. Počítají se kontrolní součty, provádí se komprese. Žongluje se s extenty. A to na discích, kam se paralelně snaží zapisovat ten md raid. Kdyby to byly SSD disky, tak by to takový problém nebyl, protože by to proběhlo mnohem rychleji, jenže ty rotační disky tak rychlé nejsou. Takže máš furt někde něco v keši co není zapsané. No a když do toho přidáš nekorektní vypnutí. Tak dříve či později skončíš na tom, že se nestihne něco důležitého zapsat. A jsi právě v tom loji, jaký jsi popsal v blogpostu.

Ano Heron "mal v NAS-e len btrfs a nemal s nim absolutne ziaden problem". Už to dochází kde byl ve tvém případě problém? Já používám taky jen Btrfs a nemám s ním žádný problém.

[msk]

Teoriu s paralelnym zatazovanim disku neberiem, na / sa prakticky okrem logov bezne nic nezapisuje a vytazuje sa len ten datovy btrfs-raid1. To by si mal potom problem aj s obycajnym swap-om. Ze je v cache nieco, co sa este nestihlo zapisat nastane vzdy, od toho je ten filesystem inteligentny, aby to pri vypadku napajania prezil (zurnal, bariery, ...). Je otazka ci ten disk nekecal (ale su to WD RED, tie by tento omrd nemali mat). Takisto je otazka, ci pred sebou netlacil nejaky problem z davnejsej doby, neviem kedy som posledne pustal scrub.

[Aleš Kapica]

Neber. V takovém případě ale hledej pomoc na lampárně a ne tady.

[msk]

Dobre, popis teda spravne rozdelenie disku, aby k problemom nedoslo. Precital som si 4x Tvoj predosly text a nie som v stave z toho pochopit, ci preferujes mdraid1+btrfs alebo btrfs-raid1.

[Kate]

Tipla bych (a za mě určitě) btrfs vůbec nad mdraidem nepoužívat, takže pokud btrfs, tak variantu 2. Btrfs se nejvíc líbí přímo na blokovém zařízení.

[msk]

Coz je ale presne pripad toho crashnuteho filesystemu mimochodom ...

[Adolf Kernel]

Za cenu cca 6000 CZ si mohol mat HP Microserver Gen 10 s ECC 8GB RAM a nizkou spotrebou a super spracovanim.

[msk]

Pred 4 rokmi? No, nevedel som, skladal som si to sam, rozmery podobne, bohuzial bez ecc a na soho zakladnej doske (tusim asrock). Kazdopadne je to uplne mimo temu, hardware teraz neriesim.

[SAM:]

Když už máš ty disky, tak bych koupil čtyřdiskové Synology - uvnitř je btrfs a máš to hotové. ZFS i btrfs jsou filesystémy zajímavých vlastností, ale nesprávné použití a nedodržení návrhových pravidel je cestou ke ztrátě dat nebo mizernému výkonu. ZFS i btrfs potřebuje pracovat přímo s disky bez jakýchkoliv HW/SW mezivrstev. Pokusy vložit něco mezi to většinou dopadnou špatně. Pokud to máš na hraní, experimentování a učení se, tak OK. Ale nedávej si na to ostrá data. Já i moje okolí má bohaté zkušenosti se ztrátou dat na btrfs při "pokusech".

[msk]

Rozosral sa ten filesystem, co lezal priamo na diskoch (pokial teda nepovazujes particiu za hw/sw medzivrstvu).

[Aleš Kapica]

NO! Sám víš, že jediná data co u nás skončila nenávratně v džá nebyla na Btrfs ale na Ext4. A skončila by tam tak jako tak, protože ten FS byl nad md raid 6 polem do kterého byl omylem zapojený jiný disk propagovaný přes NBD.

To ovšem nic nemění na faktu, že Btrfs není určeno pro virtuální disky (což se ukázalo právě u zmíněných pokusů). Tam to chce buď zcela tupý FS jakým je ext3, ideálně nad md raid 1, nebo raději rovnou logický LV disk. Hovoříme pochopitelně stále o dvou fyzických discích.

[msk]

Ono sa v mojom pripade zda, ze tie data obnovim, resp. uz som z toho root subvolume vydoloval komplet cele (doma este skontrolujem), ale stalo ma to 2 dni prace a este ma 2 dni cakaju.

[Bivoj]

Jak se podaří přidat do mdraidu cizí disk tak, aby to ten mdraid rozbilo?

[Aleš Kapica]

Velice snadno. Stačí použít libovolné zařízení vyexportované přes iscsi, nebo nbd.

Ale abyste si nemysleli, podobně lze nabourat i distribuované blokové zařízení - stačí ho použít souběžně u dvou virtuálů.

[Bivoj]

Takže i ve vašem případě šlo o souběžné použití jednoho blokového zařízení? Jak se v tomto případě chová BTRFS RAID1? Píše jen do logu chyby o nesouhlasícím checksumu, vyhodí disk nebo se na něm pokouší o opravu?

[Aleš Kapica]

Tady je to pospaáno dostatečně podrobně viz havárie 21. července 2012. Výsledkem bylo totální přepracování konceptu na diskless. Od té doby se nic podobného nestalo.

[Cabrón]

pouzijem najnovsi kernel

Na jaké verzi bylo tohle?

[msk]

4.9.x

[snajpa]

Kdybys chtel nasadit ZFS, vyrazne nedoporucuju nijako ty disky delit, dej je cely ZFS rovnou. Co se deduplikace tyce, je to s ni trochu osemetne - IMHO ma cenu ji zkouset jenom v pripade, ze znas zatez na to pole predem a vis, ze se tam nebude dit nic jineho. Protoze je to in-line dedup (tj. jak se data ukladaji, tak se rovnou deduplikuji), musi se drzet dedup tabulky v RAM a jakmile se ti tam nevejdou, jde veskery vykon deduplikovanych datasetu do haje.

[snajpa]

Pravda teda je, kdyz prijde tvrdy na tvrdy, s temi celymi disky ro ZFS je to vlastne jenom o tom, ze ma ZFS volny prostor k planovani IO operaci nad temi disky. Ono totiz nepocita s tim, ze by se co se tyce IOPS melo o disky s necim dalsim delit (v navrhu ZFS to nedava smysl, kdyz miri spis na petabajty, urcite ne smer embedded). Ale taky pravda, ze to vubec ma smysl resit tam, kde se neco deje. Kdyz ma to pole v podstate jednoho uzivatele, tak neni moc co resit (protoze neni moc paralelismu ze strany uzivatele k planovani). Mit ale treba blockchain nad ext* na tech samych discich a pak chtit od ZFS nejaky rozumny vykon, tam uz to muze znamenat nejakou tu sub-optimalnost (obzvlast pri vice VDEVech a obzvlast, pokud maji ruzne zatizene leaf devices, tj. koncove disky).

[msk]

Ako hovorim, ja som prakticky ochotny znovu risknut "pracovny" disk ako btrfs, koniec koncov ono moc inych moznosti ani nemam, pokial chcem mat featury na ktore som zvyknuty.

Co ma zaujima teraz trosku viac je ten druhy disk, na ktory budem odlievat zalohy denne a ten treti usb3 disk, ktory obcas vytiahnem z trezoru a pripojim k nas-u. Tam snapshoty nie su podmienkou (ale hodia sa) a zalohovat budem nejakym zalohovacim nastrojom (zatial preskumavam ten bup, ktory si tu deduplikaciu poriesi sam). Od tohoto filesystemu ocakavam spolahlivost a stabilitu a preto skumam ci mi zfs ma co ponuknut, alebo zostanem na ext4/xfs. Bohuzial sa cela diskusia zatial ubera uplne inym smerom a radu tohoto typu som zatial nedostal.

[snajpa]

No... ale spolehlivost a stabilitu nezajistis jednim diskem. Navic, kdyz si sjednotis storage pod jednim systemem, ktery umi inkrementalni send/receive (BTRFS by to melo umet taky AFAIK), tak si brutalne usnadnis cele zalohovani (a usetris hromadu IOPS a casu).

[msk]

Vsak mam tie disky 3, takze mozem mat pracovny bud single, alebo ako raid1, k tomu hot zalohu priamo v nas-e (ako dalsi filesystem, nie mirror) a dalsiu zalohu v trezore.

Lenze to tym padom obmedzuje filesystem na ZFS, kedze nechcem btrfs na disku co mam v trezore, vzhladom na to, ze mu uz neverim.

[msk]

Este dodam, ze v pripade ze by to nebol zfs som zmiereny s tym, ze budem prehadzovat hromadu dat lopatou zo strany na stranu (pri pouziti nejakeho "standardnejsieho" zalohovacieho nastroja ...

[snajpa]

Dalsi vec je, ze v ZFSonLinux pristala podpora nativniho sifrovani (mel jsem ho na notebooku, ktery mi pred par dny ukradli...). Akorat teda zatim nevyslo stabilni vydani, ktere by to v sobe uz melo (ale ja stabilni vydani v podstate ignoruju a stejne si nad master branchi valim svuj vyber work-in-progress patchu od komunity). Aktualni head masteru na Githubu je pouzitelny a nezere data, kdybys to chtel testnout.

[msk]

Este ma napadla ta deduplikacia. Tu bohuzial potrebujem a na online nemam dost pamate. Nad btrfs som riesil zcasu nacas offline bedup-om. :(

[cezz]

Preco vlastne potrebujes deduplikaciu?

[msk]

Jednoduchy argument - zena a "triedenie" fotiek (stylom F5). Skusim to cez vikend kvantifikovat, mozno to nebude stat za rec a budu to len jednotky GB, teraz som ale rad, ze mam tie data z toho sfailovaneho btrfs niekam vobec odliate bokom a nemusim si lamat hlavu ako velmi mam neaktualny backup v trezore :D

[cezz]

Tak ak mas 4TB disky, dost pochybujem, ze budu fotky nejaky zasadny problem co sa tyka kapacity.

A keby aj, takych dedup nastrojov co ti narobia hardlinky na rovnake subory je niekolko. Ziaden som nepouzil, pretoze mi uspora na urovni max par GB ani nestoji za namahu, ale riesenie bude na akomkolvek FS.

[msk]

U hardlinkov je drobne riziko, ze pokial s tou fotkou niekto nieco bude robit, nenavratne rozbije vsetky jej "kopie". Tu ma proste deduplikacia na urovni filesystemu nespornu vyhodu. Ale je mozne, ze by som s tym dokazal zit.

[Josef Kufner]

Ono se to nezdá, ale fotky umí hodně rychle naskákat do stovek GB. Trocha přejmenovávání a volné místo je pryč.

[Migi]

Už ti to tu naznačili nejednou ostatní, ale trochu i přijde, že jsi ten typ člověka co chce spolehlivé zrcadlení, a ze staré školy to pro tebe automaticky znamená md raid.

Potom si uvědomíš že chceš být i cool a in a protože jsi o tom četl v nějaké zprávičce, nesmyslně, bez rozmyslu a navzdory základním poučkám nad to nasadíš i btrfs.

Ten docker to už je jen taková třešnička na dortu, opět zřejmě proto, že je to ted v kurzu.

[msk]

Rozmyslam ci som ten blog napisal nejak nezrozumitelne, alebo v com by mohol byt problem, ale kedze sa to neustale dookola v tejto diskusii objavuje, tak to napisem este raz a zvyraznim podstatne informacie:

Rozpadol sa BTRFS-RAID1 nad dvomi fyzickymi diskami (sda4/sdb4) bez akejkolvek medzivrstvy. Presne ten, ktory mi tu vsetci vratane Teba doporucuju ako jedine spravne riesenie. Nebol pod nim ziaden mdraid a btrfs sahalo priamo fyzicky na blockdevice (partition).

Upresnim, ze sa na oboch diskoch nachadzal este [mdraid+ext3 /boot] a ten diskutovany [mdraid+btrfs_single /], ktoremu absolutne nic nieje.

Jedina teoria o ktorej sa tu viedla diskusia (a ktora mi pride krajne podozriva *1) je, ze na tie fyzicke disky (ale do inych blockdevice/partition) sahal este mdraid, nad ktorym boli dalsie filesystemy, ktorych paralelny zapis spolu s vypadkom napajania mohli poskodit ten btrfs mimo mdraid. Tento argument mi ale pride podozrivy, pretoze v 99% beznych nasadeni sa vedla btrfs particie nachadza vzdy minimalne jedna dalsia (swap), takze ten fyzicky disk prakticky je vyuzivany paralelne minimalne dvomi filesystemami skoro vzdy.

[Aleš Kapica]

Bože. To je obraz bídy a zoufalství. Víš ty jak funguje a k čemu je swap? Máš vůbec představu co se děje když OS pracuje s blokovým zařízením? Víš jaký je rozdíl mezi fyzickým zařízením a VFS? Přečetl sis vůbec tady na tomhle webu něco o Btrfs v raid 1, jak funguje, jaké má úskalí a jaký má smysl?

Mám pocit, že ne.

[msk]

Seriem na to, nema to zmysel.

[Migi]

Já nic nedoporučoval. Když už, tak ZFS a systém od tvůrců originálního FreeNASu. Dnes Nas4Free.

Rozpadol sa BTRFS-RAID1 nad dvomi fyzickymi diskami (sda4/sdb4) bez akejkolvek medzivrstvy. ... Upresnim, ze sa na oboch diskoch nachadzal este [mdraid+ext3 /boot]

Wait, what? Takže byl mdraid nad btrfs raidem? A jeste k tomu se z toho datoveho uloziste bootovalo?

[msk]

Nie. Na tych 2 fyzickych diskoch to vyzeralo takto:

• sda1 + sdb1 = md_raid1 -> ext3 -> /boot
• sda2 + sdb2 = md_raid1 -> btrfs(single) -> /
• sda3 + sdb3 = md_raid1->swap -> /
• sda4 + sdb4 = btrfs(-mraid1 -draid1) -> /array

Po vypadku uz ten stroj skoncil v initrd s tym, ze nedokaze pripojit /array, cize ten jediny "cisty" btrfs bez akychkolvek vrstiev pod skolaboval. Pokial za "datove uloziste" povazujes fyzicke disky v NAS-e, tak ano - bootovalo sa z nich.

[cezz]

Ja osobne by som dal dva disky ZFS a urobil z nich mirror. Pravidelnymi snapshotmi ziskas zalohu dat v roznom case a je to prakticky okamzite a zadarmo. Naviac vies tu granularitu robit sposobom kedy budes mat par hodinovych zaloh, potom par posledych dni, tyzdnov, mesiacov,.. Viz napriklad zfs auto snapshot.

Samozrejme ak sa to ZFS zosype, tak mas po zalohe, ale pred rm -rf ta to ochrani. Aby si mal ozajstnu zalohu, mozes cez zfs send posielat data na ten treti disk raz za cas. Bude to zrejme o cosi rychlejsie ako BUP, lebo hoci ten robi deduplikaciu, tak aj tak musi nezmenene data prejst zatial co zfs proste posle zmeny od posledneho snapshotu.

(predpokladam ze vsetky disky maju rovnaku kapacitu?)

V zasade to je podobne tomu tvojmu A-->B------>C rieseniu, len tie A-B sa nereplikuju hodinovo, ale okamzite a rollback o hodinu/den/tyzden spat ti poskytne snapshot. Plus je to omnoho jednoduchsi setup a s Ubuntu 16.04 a vyssim mas podporu ZFS priamo v distribucii.

Ja osobne mam v podobnej konfiguracii NAS uz roky a to som medzitym postupne menil disky z 500GB na 1TB a 4TB a zakazdym prebehol resilvering v pohode. Tiez mam zfs send konfiguraciu a plus off site zalohu do cloudu.

Ozaj a Docker nad ZFS funguje v pohode.

[Bedňa]

Na čo kurwa RAID, RAID nieje žiadna záloha a zachráni len online operácie. Takže keď mám v prdeli dnešné dáta, tak zálohuj a na RAID sa vykašli.

[msk]

Ano, moje myslienky sa uberaju aj tymto smerom, pretoze po nocnom badani som si overil, ze to btrfs je spolahlivo rozkopnute na oboch diskoch rovnako, spravilo si to zjavne samo (pretoze si mirroruje vo vlastnej rezii, nikto to za neho nemirroruje) a cim dalej tym viac si skor myslim, ze je to dosledok bugu nez nejakeho vypadku napajania. To by musela byt extra sila aby sa oba disky syncli identicky blbo pri prave jednom vypadku.

Takze mozno namiesto raidu primarneho disku pojdem fakt cestou castejsieho snapshotovania a prenasat snapshoty na druhy disk v kratsich intervaloch. A do trezoru vlastne tiez. A vyrazne viac scrubovat, ci uz tam dam znovu btrfs s novsim kernelom, alebo zfs.

[Bedňa]

Je zbytočné zabíjať disk online zápisom na dva krát ak to nepotrebuješ (RAID). Tak prooste disk zhebne a mám nočnú zálohu a čo som robil dnes je v prdeli. Ak som si toho vedomí a stráty sú bezpredmetné, tak to neriešim.

Život je otázka priorít a tie si musíš určiť ty.

[snajpa]

No vidis, pro tebe zbytecne - a ja treba nedavam *nikdy* samotny jeden rotacni disk do neceho zapnuteho tak porad, jak muj desktop. Vzdycky aspon mirror, mam rad svoje nervy a ztrata dne prace - pokud jsem za ten den rozbastlil nekolik zajimavych veci, ale nic do commitovatelne podoby - je pro mne neprijatelna. K tomu snapshoty tak casto, jak potrebuju (aktualne nemam zfs-auto-snapshot, protoze jsem si to rozbil pri hrani a jeste neopravil) a send/recv na zalohovaci pole. Je pravda, ze kdyby byl kriticky bug ve vsech verzich ZFS, co mam nasazene, tak mam po datech - ale tak s tim tak trochu pocitam a zalohovaci pole jede vzdycky nejvic overenou verzi ZFS bez experimentalnich patchu. Obzvlast, kdyz jsou ty rotacni disky WD RED, nebo podobny levny j*bky, mit je v mirroru se sakra vyplati...

[Aleš Kapica]

To nemá smysl. Je to jak volební diskuze. Někdo zkrátka neumí myslet dopředu a poučit se z cizích chyb a jiný jo.

Proto jsem svou snahu pomoci ukončil ihned poté co autor blogpostu oznámil, že nebere můj názor na příčinu problému a místo toho jako mezek furt dokola hledá zázračné řešení do budoucna, místo aby se pokusil pochopit příčiny, proč se jeho problém vůbec objevil.

[msk]

Autor blogpostu cez vikend odhalil vadny so-dimm modul, takze Tvoj nazor na pricinu problemu bola uplna blbost, ako som si od zaciatku aj myslel. Teraz uz dava dokonca aj zmysel, preco boli oba disky poskodene uplne identicky - k poskodeniu doslo este v pamati a btrfs to len zapisal do raidu, ako sa po nom chcelo. Tym, ze som nescruboval (moja neodpustitelna chyba), prisiel som na to az v momente, ked som ten stroj musel otocit a on pri nejakych checkoch pri mounte na ten problem prisiel a poslal ma do prdele.

Blbe je, ze som robil btrfs restore na tej vadnej ramke, takze ju vymenim a dam si to kolecko preventivne znova.

[Aleš Kapica]

Vadná paměťový modul. To se může stát. A čím víc je, tím hůř se takový problém odhaluje. Také jsem měl podobný problém, občas mi to shodilo některý z virtuálů ale souborový systém mi to nerozbilo nikdy. Asi jsem měl štěstí.

[Bedňa]

Keď mám dva disk a budem sa rozhodovať čo s nimi, tak jeden online a druhý bude spať. Keď pôjdem na kávu, tak stlačím klávesovú skratku a dáta sa zálohujú. Alebo si to dám každú hodinu na automatiku. Stále to bude spoľahlivejšie ako keď havaruje zrcadlo. Teda s podmienkov, že ten druhý disk má extra napájanie, čo pri zrkadlení nebýva zvykom. Videl skapať zrkadlo na zdroji a nebolo to nič príjemné, pretože si mysleli, že zrcadlo je záloha.

[snajpa]

Co furt nevyresi situaci, ze prijdu o par hodin prace Jinak, nerekl jsem, ze zrcadlo je zaloha. Ale ze samotny rotacni disk bez zrcadla si proste do PC nedavam (kvalitni SSD jo, s tim zas takovy problem nemam, ale mechanicka nachylnost rotacnich je pro mne problem, kteremu se vzdycky snazim predejit, kdyz se da - od urcite doby...).

[Josef Kufner]

Zrovna s SSD bych měl větší problém než s rotačním. Rotační disk, když začne zlobit, tak většinou ještě jdou vykopírovat data. A při interaktivní práci si toho člověk všimne včas. SSD prostě chcípne a hotovo. Pro mne to je však bezpředmětné, neboť do notebooku se mi dva disky nevejdou.

Pár hodin práce obvykle řeším pushnutím commitů do repozitáře na síti (do vlastní větve, abych to ostatním nerozbil, pokud to je relevantní). Pokud bych nepoužíval k práci Git a o data se tak moc bál, řešil bych to posíláním snapshotů každou hodinu na NAS.

[msk]

Tak ono snapshoty ide posielat kludne co 5 minut, to uz je myslim dostatocne maly timebox proti akejkolvek citelnej strate...

[Vantomas]

Na jakém distru a verzi jádra to btrfs běželo?

[msk]

Nemam to teraz nabootovane, takze negarantujem na 100%, ale debian jessie a 4.9.x