Záchrana Btrfs volume poškozeného při btrfs check

Záchrana Btrfs volume poškozeného při btrfs check
« kdy: 12. 05. 2022, 01:12:35 »
Zdravím,

prosím o záchranu reputace Btrfs a jako vedlejší efekt i 5,28 TiB mých záloh. Volume vykazoval problémy a po spuštění a pádu btrfs check už nejde ani připojit. Popíši to celé chronologicky níže.

Popis

Měl jsem Linux openSUSE Leap 15.3 s jen oficiálními repozitáři. Byl ve VPS na QNAP NAS.

Do něj jsem měl z toho NASu přes ISCSI připojený 5,28 TiB volume obsahující zálohy všech mých serverů na šifrovaném Btrfs. Říkejme mu třeba blokové zařízení /dev/star1/backups:

Kód: [Vybrat]
localhost:~ # blockdev --getsize64 /dev/star1/backups
5798201655296

localhost:~ # blkid /dev/star1/backups
/dev/star1/backups: LABEL="space-backups" UUID="18d0fd43-c0ac-42f6-a480-fb4f02932b00" UUID_SUB="f91d3e0c-46a6-4ab4-b492-1ed211a1d030" BLOCK_SIZE="4096" TYPE="btrfs"

Protože se mi tento Btrfs volume začal přepínat vždy chvíli po bootu do read-only kvůli nějakému problému, spustil jsem na něm btrfs check, ten ale spadl:

Kód: [Vybrat]
krato-nas01-vps-backups:/home/krato # date ; time btrfs check --repair --clear-space-cache v1 --progress --check-data-csum /dev/star1/backups ; date
Mon May  9 17:03:49 CEST 2022
enabling repair mode
Opening filesystem to check...
Checking filesystem on /dev/star1/backups
UUID: 18d0fd43-c0ac-42f6-a480-fb4f02932b00
Failed to find [6147432235008, 168, 16384]
btrfs unable to find ref byte nr 6147432251392 parent 0 root 2  owner 0 offset 0
transaction.c:195: btrfs_commit_transaction: BUG_ON `ret` triggered, value -5
btrfs(+0x51f99)[0x55a7695aef99]
btrfs(btrfs_commit_transaction+0x1ae)[0x55a7695af58e]
btrfs(btrfs_clear_free_space_cache+0xdc)[0x55a7695a20bc]
btrfs(+0x157fa)[0x55a7695727fa]
btrfs(cmd_check+0x103a)[0x55a7695c4cca]
btrfs(main+0x8e)[0x55a76957c08e]
/lib64/libc.so.6(__libc_start_main+0xed)[0x7febe47e034d]
btrfs(_start+0x2a)[0x55a76957c28a]
Aborted (core dumped)

Po jeho pádu oddíl najednou už ani nešel připojit:

Kód: [Vybrat]
localhost:~ # mount /dev/star1/backups /mnt
mount: /mnt: wrong fs type, bad option, bad superblock on /dev/mapper/star1-backups, missing codepage or helper program, or other error.

localhost:~ # dmesg -T | tail
[Wed May 11 20:32:53 2022] BTRFS error (device dm-1): open_ctree failed
[Wed May 11 21:25:42 2022] hrtimer: interrupt took 18596350 ns
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): flagging fs with big metadata feature
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): disk space caching is enabled
[Thu May 12 00:17:04 2022] BTRFS info (device dm-1): has skinny extents
[Thu May 12 00:17:06 2022] BTRFS info (device dm-1): bdev /dev/mapper/star1-backups errs: wr 1, rd 0, flush 0, corrupt 408, gen 0
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): parent transid verify failed on 6086151716864 wanted 487495 found 487500
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): failed to read block groups: -5
[Thu May 12 00:17:14 2022] BTRFS error (device dm-1): open_ctree failed

Protože btrfs check při dalších pokusech opět vždy spadl, nainstaloval jsem novou VPS s openSUSE Tumbleweed, kernel upgradoval na 5.18-rc6 a blokové ISCSI zařízení připojil jen do této VPS:

Kód: [Vybrat]
localhost:~ # head -n 2 /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20220507"

localhost:~ # uname -a
Linux localhost.localdomain 5.18.0-rc6-1.ged50f8f-default #1 SMP PREEMPT_DYNAMIC Sun May 8 21:14:22 UTC 2022 (ed50f8f) x86_64 x86_64 x86_64 GNU/Linux

localhost:~ # btrfs --version
btrfs-progs v5.17

Na něm btrfs check napíše nějaké chyby a pak to vzdá:

Kód: [Vybrat]
localhost:~ # btrfs check /dev/star1/backups
Opening filesystem to check...
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
parent transid verify failed on 6086151716864 wanted 487495 found 487500
Ignoring transid failure
ERROR: child eb corrupted: parent bytenr=6086151536640 item=223 parent level=1 child bytenr=6086151716864 child level=1
ERROR: failed to read block groups: Input/output error
ERROR: cannot open file system

Zkusil jsem btrfs rescue zero-log a btrfs rescue clear-uuid-tree, ale nepomohlo to.

Zkusil jsem na konec ještě btrfs rescue chunk-recover, ale to se vždy po pár hodiných přeruší s chybovou hláškou:

Kód: [Vybrat]
localhost:~ # date ; time btrfs rescue chunk-recover /dev/star1/backups ; date
Wed May 11 20:35:04 CEST 2022
Scanning: 272670670848 in dev0scan chunk headers error
Chunk tree recovery aborted

real    140m45.289s
user    4m31.873s
sys     25m25.405s
Wed May 11 22:55:49 CEST 2022

Připadá mi, že se to neustále točí dokola jen kolem následující chybové hlášky. Možná je tam jen jeden zádrhel, se kterým si neumí poradit mount a ani check. Tato chyba myslím byla také v dmesg úplně na začátku kdy ještě šel ten oddíl přimountovat a přepnul se po chvíli do read-only:

Kód: [Vybrat]
parent transid verify failed on 6086151716864 wanted 487495 found 487500

Dotaz

Máte někdo prosím nějaký nápad jak to opravit aby to šlo opět přimountovat a číst data?

Jedná se v mém případě "jen" o tisíce záloh různých strojů. Cítím to hlavně jako velkou zkoušku vyspělosti Btrfs. Protože jestli "načatý" Btrfs dokáže "btrfs check" dorozbít, že to už nic neopraví a to na stable Linuxu a kernelu, tak se začnu bát můj velmi oblíbený Btrfs používat kdekoliv.

Mohu vyzkoušet jakoukoliv Vaši radu, ten oddíl jsem právě teď snapshotnul. Bohužel naivně ne už před btrfs check. Teď mi stejně jde hlavně o to, zda se lze na Btrfs spolehnout.
« Poslední změna: 12. 05. 2022, 01:14:08 od Petr Kratochvíl »


RDa

  • *****
  • 1 772
    • Zobrazit profil
    • E-mail
Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #1 kdy: 12. 05. 2022, 02:16:27 »
A proto jsem v tomto ultra-konzervativec, co radeji EXT4, ktere si muze precist dekoderem v PHP :)

Pokud si na to troufate - implementujte RO userspace driver (tool) pro prochazeni filesystemem (resp. dump adresarove-souborove struktury) - dokumentace datovych struktur snad nekde musi existovat, ne?

Behem takoveho dumpu pak zjistite, kde se to rozbilo (zacnou vyskakovat reference na sektory za koncem partition a podobne), takze to musite pak napravit, aby jste se ke svym datum dostal.

Ano, bude to vyzadovat nejakou praci a studium, ale jsou to vase data. Za to, to bude vzdy stat.

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #2 kdy: 12. 05. 2022, 10:38:15 »
A proto jsem v tomto ultra-konzervativec, co radeji EXT4, ktere si muze precist dekoderem v PHP :)

Neměl jsem do teď problém s používáním Btrfs, ale jen pod podmínkou, že žádná cenná data nemám jen na jednom místě, což bych stejně dodržoval tak jako tak a pod podmínkou, že čas od času provedu check dat alespoň přes btrfs scrub.

Pokud si na to troufate - implementujte RO userspace driver (tool) pro prochazeni filesystemem (resp. dump adresarove-souborove struktury) - dokumentace datovych struktur snad nekde musi existovat, ne?

Behem takoveho dumpu pak zjistite, kde se to rozbilo (zacnou vyskakovat reference na sektory za koncem partition a podobne), takze to musite pak napravit, aby jste se ke svym datum dostal.

Málo co by mě bavilo víc, ale bohužel už jsem fulltime pracující a tohle mi navíc ani nikdo nezaplatí :-(

Ano, bude to vyzadovat nejakou praci a studium, ale jsou to vase data. Za to, to bude vzdy stat.

Čistě z pohledu uživatele mě ani tak nezajímá jak to opravit, ale zajímá mě, zda se lze vyhnout tomu, aby btrfs check domrvil volume tak, že už z něj vůbec nic nedostanu bez total low-level hackingu.

Tj. zda může být při správných verzích kernelu apod. bezpečné spoléhat se na Btrfs stejně jako na ext4 a nebo dokonce i více (už jednou jsem relativně včas detekoval jeden low-level problém díky Btrfs checksumům dat, což ext4 nenabízí).

_Jenda

  • *****
  • 1 095
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #3 kdy: 12. 05. 2022, 10:52:09 »
A proto jsem v tomto ultra-konzervativec, co radeji EXT4, ktere si muze precist dekoderem v PHP :)
Tam je blbý že zrovna na zálohy se zatraceně hodí snapshoty, které „staré“ filesystémy nemají. Samozřejmě můžeš používat nějaké snaphotové řešení na úrovni souborů (rdiff-backup) ale s tím jsou zase jiné problémy (mně se třeba stalo, že rdiff-backup ukládal všechny snapshoty + metadata + poznámku o tom že byl soubor smazán do stejného adresáře jako ten soubor, takže když máš v adresáři pár tisíc souborů (PHP session dir; ano, měl jsem ho excludnout), tak za chvíli máš v cílovém adresáři milion a narazíš na limit počtu souborů v adresáři ext4).

OP: Gratuluju, mně btrfs check v roce 2015 začal rekurzivně mazat /, od té doby se ho bojím spouštět. Což je blbý, protože se mi btrfs taky občas rozbije, a nenašel jsem jiný způsob než vytvořit nový a zkopírovat data. Lidi se nechali ukecat „má to scrub tak se nemůže nic stát“ a nepochopili, že scrub nechrání před většinou SW bugů a nechrání před HW chybou typu bitflip RAM vzniklou před spočítáním checksumu.

Čistě z pohledu uživatele mě ani tak nezajímá jak to opravit, ale zajímá mě, zda se lze vyhnout tomu, aby btrfs check domrvil volume tak, že už z něj vůbec nic nedostanu bez total low-level hackingu.
Nemůžeš, tohle může udělat každý fsck, protože při porušení invariant FS ti nezbývá než heuristicky odhadnout „jak to asi bylo správně“ a výsledkem snadno může být ztráta dat (samozřejmě coredumpnout se při tom je ostuda). btrfs check má navíc zhoršenou pozici v tom, že 1) ten FS je složitější, 2) není otestovaný protože ho nikdo nepoužívá. I v dokumentaci je hned nahoře tučné varování že ho nemáš používat.

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #4 kdy: 12. 05. 2022, 11:23:47 »
A proto jsem v tomto ultra-konzervativec, co radeji EXT4, ktere si muze precist dekoderem v PHP :)
Tam je blbý že zrovna na zálohy se zatraceně hodí snapshoty, které „staré“ filesystémy nemají.
Tam by se daly, asi s určitým omezetím oproti BTRFS, použít LVM snapshoty.

Vůbec mi přijde z technického hlediska jako svým způsobem hloupost v rámci souborového systému řešit záležitosti jako třeba snapshoty nebo RAID. Jednak kvůli náchylnosti na chyby - FS sice umí pomalu i uvařit kafe, ale z hlediska spolehlivosti BTRFS kdovíjakou reputaci nemá, a proto třeba pro mě je rovnou nezajímavý. A jednak proto, že modulární přístup mi přijde lepší - každý modul/vrstva řeší svou funkcionalitu, není třeba to samé či víceméně samé implementovat na dvacet různých způsobů. To by zase mělo přispět ke spolehlivosti, snadnějšímu testování, atd.


_Jenda

  • *****
  • 1 095
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #5 kdy: 12. 05. 2022, 11:43:18 »
A proto jsem v tomto ultra-konzervativec, co radeji EXT4, ktere si muze precist dekoderem v PHP :)
Tam je blbý že zrovna na zálohy se zatraceně hodí snapshoty, které „staré“ filesystémy nemají.
Tam by se daly, asi s určitým omezetím oproti BTRFS, použít LVM snapshoty.
To asi bude zoufale pomalé (bavíme se o stovce snapshotů - denní zálohy s několikaměsíční historií) a neefektivní (snapshotujeme třeba i žurnál).

RAID na úrovni block device má zase problém v tom, že je dost pain ho provozovat s různě velkými disky a přidávat disky za běhu (reshape).

RDa

  • *****
  • 1 772
    • Zobrazit profil
    • E-mail
Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #6 kdy: 12. 05. 2022, 11:59:29 »
Čistě z pohledu uživatele mě ani tak nezajímá jak to opravit, ale zajímá mě, zda se lze vyhnout tomu, aby btrfs check domrvil volume tak, že už z něj vůbec nic nedostanu bez total low-level hackingu.
Nemůžeš, tohle může udělat každý fsck, protože při porušení invariant FS ti nezbývá než heuristicky odhadnout „jak to asi bylo správně“ a výsledkem snadno může být ztráta dat (samozřejmě coredumpnout se při tom je ostuda).

Tady souhlasím, ono to moje ruční dobrodužství s EXT4 nastalo v době, kdy jsem zvětšil volume nad 16TiB, ale provozoval to na 32bit systému, kde je tohle maximální velikost (původně šlo o ext3 fs upgradnutý na ext4). Není tam (nebo tenkrát nebyla) žádná explicitní ochrana/kontrola na kompatibilitu cpuarch vs velikosti volume, takže se to rozbilo prvním namountováním.

A fsck.ext4 to následně domrvilo tak, že nezbylo nic jiného, než si to fakt zparsovat sám - pak jsem objevil jak se na pár místech kvůli tomu 32bit wraparound přepsali špatné clustery (kvůli těm průsřelům jsem měl poškozeno nakonec pár souborů), ale šlo to dát dokupy inplace, bez nutnosti dělání kopie.

Pak jsem pole přesunul do jiného kompu, už s 64-bit OS.

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #7 kdy: 13. 05. 2022, 01:21:54 »
Toto FUNGUJE pro mount:

Kód: [Vybrat]
localhost:~ # mount -o ro,rescue=nologreplay,rescue=ignorebadroots /dev/star1/backups /mnt

Do teď mě to nenapadlo zkusit, protože jsem myslel, že log už smazal btrfs rescue zero-log a použít backup root jsem také hned zkusil. Ale zafungoval až mount výše.

Co dál: Vytvořím nový Btrfs volume, přes btrfs send/receive přenesu několik vhodně zvolených snapshotů a začnu používat nový volume místo toho poškozeného. Budu u nového držet min. 1 LVM snapshot za cenu horšího výkonu (dle QNAP NAS warningu horšího o 5 až 30%, ale však to jsou jen zálohy).

Mezi tím jsem navíc zprovoznil nezávislé zálohování přes Kopia+rclone na box.com , kde si už pár let platím neomezené úložiště.

Děkuji velmi všem za cenné zkušenosti a rady.

PS: Kdyby někoho ještě napadlo něco k tomuto tématu, tak sem samozřejmě dál pište.

Podařil se zatím jen zázrakem ten read-only mount, což jest nic moc, ale třeba toto vlákno někdy někomu zachrání data.
« Poslední změna: 13. 05. 2022, 01:28:35 od Petr Kratochvíl »

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #8 kdy: 13. 05. 2022, 08:40:52 »
Co dál: Vytvořím nový Btrfs volume, přes btrfs send/receive přenesu několik vhodně zvolených snapshotů
No já bych raději přenášel pouze soubory např. rsyncem, bál bych se, aby mi tam btrfs send/receive nepřenesl nejakou chybičku (jistota je kulomet ;-))

bmn

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #9 kdy: 13. 05. 2022, 09:10:41 »
btrfs check --repair sa nemá používať. Celý btrfs check je deprectated.
Prepnutie sa do read only módu je vlastnosť btrfs kedy sa tým zabraňuje ďalšiemu poškodeniu/strate dát. Čo je podľa mňa čiastočne aj za tou zlou reputáciou. Kým btrfs sa pri chybe zamkne tak ext4 si ide nerušene ďalej. Taktiež btrfs je náročnejší na korektnosť správania sa disku.

send/receive je samozrejme tiež chránené crc32 checksum takže tam by k chybe prísť nemalo.

RDa

  • *****
  • 1 772
    • Zobrazit profil
    • E-mail
Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #10 kdy: 13. 05. 2022, 10:39:12 »
send/receive je samozrejme tiež chránené crc32 checksum takže tam by k chybe prísť nemalo.

Ochrana transportu vam nepomuze, kdyz je vada v payloadu. A to myslel ten pisatel, ze bude lepsi prenaset soubory -  z uzivatelsky pristupneho koncoveho API, nez nechat btrfs prenest interni strukturu s potencialnim neporadkem.

_Jenda

  • *****
  • 1 095
    • Zobrazit profil
    • https://jenda.hrach.eu/
    • E-mail
Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #11 kdy: 13. 05. 2022, 11:24:42 »
btrfs check --repair sa nemá používať. Celý btrfs check je deprectated.
Tak to je super, a náhrada není, takže pak nebude fsck vůbec?

Taktiež btrfs je náročnejší na korektnosť správania sa disku.
Jeden z hlavních selling pointů btrfs je, že autoři tvrdí, že disky se chovají nekorektně (např. tiše vrací špatná data) a oni to vyřešili.

rmrf

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #12 kdy: 13. 05. 2022, 14:02:53 »
btrfs check --repair sa nemá používať. Celý btrfs check je deprectated.

deprectated je příkaz btrfsck.

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #13 kdy: 13. 05. 2022, 17:17:58 »
A jak je na tom v Linuxu ZFS? V zásadě akorát vím, že na Sunech to funguje dlouho a dobře a že dřív byly nějaké licenční problémy, ale jaký je aktuální stav vůbec netuším.

Re:Záchrana Btrfs volume poškozeného při btrfs check
« Odpověď #14 kdy: 13. 05. 2022, 18:19:59 »
ZFS nemá fsck, používá se jen scrub