Vlákno názorů k článku
EXT4 dostane podporu bloků větších než stránka paměti od lukastesar - Budoucnost je nyní! Ještě aby podpora pro blocksize...

Ten tooling je specificky pro kazdou zakazku na obnovu dat - a je tam nekolik hodinova adaptace, resp. analyza toho co tomu vlastne je, ta implementace je pak uz primocara. Je treba rozumet problematice a samotnemu problemu co nastal - jakym zpusobem jsou data poskozena. Ma to diry? Ma to prepsane adresare? Dvojmo zformatovane / prolnute filesystemy? A milion dalsich veci, vcetne formatu souboru, kontejneru a kodeku (moje specializace je pro multimedialni formaty). Mnohonasobne skenovani, objevovani specifickeho patternu, atd..

Lidi si predstavuji ze to je jednoducha aplikace co pustis, kliknes a na druhe strane vylezou data - vubec. Casto to pripomina spis EEG a snahu o cteni myslenek - poskladani velice slozite mozaiky - kde znalost rezimu selhani je klicova.

Hotove reseni funguji pouze na neposkozena data.. to by lidi nemuseli prece hledat a potrebovat specializovane sluzby.

Jestli nekdo chce pomoct - tak mu radim jedine - nastudovat si obor, umet programovat, mit schopnost cist dokumentaci, a investovat neomezene sveho casu k vyreseni sveho problemu. Pokud neco z toho nemuze.. je lepsi to sverit tem, co to umi / absolvovali.

Proc implementovat neco co uz existuje - protoze to muzete ridit ve vlastni rezii - a castecna/degra­dovana fukcionalita je vic, nez nejaky error typu - corrupted, unable. Resim veci, kde human-in-the-loop je potrebnej, protoze se to samo sebou nespravi.

Buď děláš produkt a ty funkce bys měl samozřejmě implementovat dopředu nebo děláš službu a ty funkce si nějak implementuješ pokus-omyl jakmile ti příjde taková zakázka. Já se bavil o té druhé variantě, kterou tady RDa popisoval.

Pokud máš na vstupu poškozená data, zdb je dost striktní a velmi rychle ti umí služby ukončit, nepracuje v režimu, že ti stačí získat jen část dat nebo si některé věci pokusit dopočítat. Často ten fs dostaneš ve stavu, kdy ti už zdb hlásí problémy a nechce jít dál.

Jo, za tři dny práce můžeš mít už nějaké výsledky a data. Zase nezapomeň, že neděláš produkt, ale něco, co stačí, když ti bude fungovat na tom, co dostaneš. Iteruješ podle dokumentace, open source zdrojáků a rovnou testuješ na dumpu disku. Předpokládám, že takhle to i RDa dělá. Za ta léta jsem si také prošel různými opravami různě rozbitých fs vč. těch distribuovaných. Jo někdy jsou maličkosti, které tě na týden zabetonují, jindy máš za pár hodin obstojné výsledky, jindy máš tolik dat, že to pak dva týdny běží.

Chtěl jsem jen říct, že zfs prostě na úrovni dat na disku není složité, když ti jde jen o to, vše nějak přečíst.

Ano, delam to tak. Test je vuci aktualnimu dumpu.

ZFS/BTRFS jsem nedelal, z tech mene klasickych FS tam bylo nedavno HFS+. Dokazal jsem v nem opravit dost, aby se to dalo pak pripojit jako disk skrze OSS driver v Linuxu - tj postaci implementovat tolik - aby bylo zrejme co selhalo, v konkretnim pripade - rekonstruovat prepsany zacatek protoze byl disk inicializovan a preformatovan na ExFAT, neco, co pri trose ne-stesti udelaj win bud sami nebo je k tomu treba nevedome ukliknuti v podivne vyzve/hlasce. Plus trocha opruzu s GPT nad hw raidem (byl to mirror), kdy hw raid prezentuje disk zmenseny o sve systemove oblasti.. a GPT implementace v kazdem OS jsou celkove nestastnej z toho, ze backup table je jinde.. v linuxu si clovek poradi skrze losetup nebo device mapper.

MacOS presto nechtel volume primountovat. FSCK na nem pritom nehlasilo zadnou chybu - skvely co? Ale pak v nem sla provest konverze HFS+ na APFS, ktera si dane "chyby" nebo co zpusobovalo nemoznost mountu vubec nevsimla.

Takze ackoliv jsem implementoval cely FS zespoda - abych dostal data a vedel ze ty data tam proste fakt jsou (a uklidnil klienta vzorky), oprava spocivala nakonec ve vygenerovani noveho superbloku a te necekane konverzi v MacOS - pak se z toho data stahli uz klasicky vcetne vsech frikulinskych prav a metadat co MacOS vede. Tak mam holt dalsi tool na dump dat do sbirky.. az bude potreba.

TLDR:
OSS / proprietarni driver / debug dumper = selze na chybejicim superbloku
vycucat novej superblok z prstu nejde, je treba tomu porozumet co clovek dela

A preferoval jsem dostat data z toho po sve ose.. ze to nakonec slo nativne / po konverzi, byla prijemna vyhoda. Ostatne - sroubek stoji halire.. ale opravare platite proto, aby vam rekl kterej je ten problematickej :)

Na zachranu dat z robiteho FS spoustu funcionality toho FS vubec nanic nepotrebujes. Vazne nevim, nac by ti treba bylo implementovat CoW. A takovych funcionalit jsou stovky.

A naopak, chces precist i ta data, o kterych ti FS rekne, ze jsou necitelna, protoze ... treba nesedi hash ... coz je ti tak nejak uplne jedno.

Co se realne pouziva se da zjistit. Ale pripomela mi tahle debata, jak jsem jednou kdysi davno opravoval rozsypane XFS... tri dny to netrvalo, ale prozkoumat co tam jak je a co je spatne jeden krasny vecer zabralo. Ale porad to bylo rychlejsi, nez obnova ze zalohy... a bylo to hodne low-level hrabani se ve strukturach.

Nechci vyloženě rýpat, taky se rád hrabu v datových strukturách, ale co trvá na obnovení zálohy tři dny a ještě je jednodušší se hrabat v rozbitém FS? Už nějakých 20 let ani neřeším nějaké další přepínače u fsck a raději vytáhnu zálohu, je to spolehlivější.

"raději vytáhnu zálohu"

Obnovovani zalohy je to uplne posledni, co chces delat. Z tisicu ruznych duvodu.

Vzdycky pritom dojde ke ztrate dat, mozna libovolne male ale zcela garantovane. Navic obnovovat desitky TB (kdyz v malem) = dost casto dny.

Jako bonus, narazis na spousty mooc krasnych veci ... treba na tema ze ty zcela spravne odzalohovany widle, se ti nepripojej do domeny, protoze mezi zalohou a obnovou doslo na zmenu hesla, a tudiz to co mas v ty zaloze ... uz neplati.

To je datacentrum někde v jeskyni? Na starém 10Gbps ethernetu obnovíš 80TB za den. Naše vmka mají max 1TB (z různých důvodů) a snapshoty se dělají tak často, jak je potřeba (mimo těch pravidelných), takže na záloze je vše, co tam má být. DB servery mají buď replikace nebo zálohování (streaming), takže je tam poslední transakce. Navíc hromada VM je tam v nějaké kopii, takže stačí dotáhnout pouze snapshoty od pořízení klonu. Obnova čehokoliv je v řádu minut a samozřejmě to pravidelně testujeme.

Pokud někdo po změně hesla na provozním serveru neudělá aktuální zálohu, tak je prostě pííííp.

Skutecne velke objemy dat proste dlouho trvaji, limitou muze byt i rychlost zalozniho media (restore z pasky taky trva dyl, zejo). Jasne, pokud si to nekde smudlate s par GB, tak restore z backupu bude asi rychlejsi :-)

Tve mě se fakt líbí ta představa, že všichni mají server na sd kartě v RPi :-D Jinak viz komentář výše. I na 10GbpsE, což je dneska hračka na doma, máš nějakých 80TB za den.

Opravdu bych nechtěl mít server u provozovatele, který se raději tři dny hrabe v nabořeném FS místo toho, aby klikl na tlačítko restore backup. Na restore z pásky trvá nejdéle to, než to robot zasune do mechaniky. Potom už to fičí nějakých 400MB/s.

Thanks, captain obvious. Samozrejme ze neni problem ani stogigova sitovka, to je dnes take spotrebak. A sam jste si i tou paskou nazorne prokazal, ze tou nezvladnete ani naplno vyuzit ten desetigigabit... a podobne uzka hrdla muzou byt proste i jinde.

Mimoto, i to kliknuti na tlacitko muze selhat... historie takovych incidentu pamatuje... vagony :)

No já jsem se jenom ptal, kdy je lepší tři dny obnovovat FS než vytáhnout jednu zálohu, ať už je teda na čemkoliv. Zase tak pomalé ty pásky nejsou, aby to trvalo tři dny.

Zalezi na objemu dat. Vy dle dnesnich moznosti srovnavate jako by treba pred deseti lety byly stejne. Nedejboze pred delsi dobou. Zapatrejte v historii... ;-) Vzdy zalezi na okolnostech a take na casovem zasazeni (o kterem nevite, ale zavery cinite).

Dík, objednám v Alze nějaké levné SSD a pohraju si :). Proti tomu, co jsem tehdy četl je tohle naprosto v pohodě.