Odpověď na názor

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 :)