Page 1 of 1

Záchrana vecí ze .sparsebundle zálohy

Posted: Thu Aug 22, 2024 11:59 pm
by Morc
aneb jak (ne)posrať ale ve výsledku bolestivo zachrániť hodnotné súbory.

Najprv trochu príbehovo. V roku 2020, určitý čas pred prechodom z Cloveru na OpenCore a z macOS 10.14 na macOS 10.16b1 som si robeu zálohu 10.14kovej inštalácie. Zakál som si šecky zálohy pred touto a šecky zálohy po tejto robeu jak readonly komprimuvané .dmgčka tak toť táto bola volákou záhadnou a bližší neobjasnenou výnimkou pri kerej som spraveu .sparsebundle. Spraviť zálohu v inom formáte neni zrovna hneď takto voláka problematická vec, ten filesystem je. Veci sa majú totižto tak, za celé roky odkedy som na jablčnej systémovej platforme, som prežeu aj HFS+ celkom dlho a aj zažeu príchod a kompletný prechod na APFS. APFS je filesystem dobrý, nehovorím že ne. Podporuje CoW, vnútorné kontajnery a podobné sprostosti, fakt to pekne vymysleli a ešte lepší premigruvali to, čo na HFSku bolo vrátane i<Zariadení> a existujúcich macOS inštalácií. Ale nemóžem si odpustiť za tí roky povedať na APFS aj volačo zlé, s týmto filesystemom som mal ja osobne asi najvác incidentov pri porovnaní se šeckými ostatnými. Jeden incident s týmto filesystemom som mal v júni 2018 krátko po príchode macOS Mojave, jeden ve februári 2022 a potom posledný dva dni pred príchodom mójho aktuálneho MacBooku presne 16.3.2022. Teda, ten posledný bol posledným dotedy, dokedy ho nenahradeu ten z čerajšku (21.8.2024).

Le incident z čerajšku (21.8.2024)
Momentálne robím doma veliké upratuvaní na diskoch, robím porádky a stem si potenciálne vzácne veci z tých záloh dať na jednu kopu aby som vóbec o tom vedel že to existuje. Pri tejto príležitosti som zálohový disk mal vybratý, kopíruval som súbory odťál hentam a tam. Jedna z posledných velikých záloh bola zrovna táto .sparsebundle macOS záloha o kerej som dlho vedel že trvá strašne dlho kým sa vóbec namountuje. Nevedel som dóvod, neríšeu som to ale robeu som čo bolo treba, vyťahuval veci. Volačo som vyťáhol a potom som potrebuval spraviť reštart a disk prehodiť inde. A tu sa dostávame k jednému problému o kerom som v tom čase reštartu ešte nevedel.

Pojme rovno k veci, tá .sparsebundle záloha bola totižto voláky záhadný read/write výmysel pri kerom som to vtedy nedomysleu aj keď som za to moc nemohol a nemal som jak vedeť. V zálohe bolo teda APFSko keré, jak som už naznačeu, schytalo incident a posralo sa. Posralo sa z dóvodu "doví", na výpadky a disky vyzíra byť filesystem fakt náchylnejší jak na SSDčku. Vtedy sa naskytla bežná otázka "Šak vezni voláky recovery program a prežeň to s ním, šak to bude jednoduché, ne?", lenže jeden by si pomyslev... Keďže tá záloha bola úplne kaput tak nešla namountuvať. (v tomto prípade keby nešla namountovať tak by som ju pridal do recovery programu jak súbor, lenže .sparsebundle záloha je zložka s kvantiliónom malých súborov kerým rozumí jedine zálohový formát a nie ja) V tomto prípade sa zaťál nedal použiť recovery program jakéhokoľvek typu, a tým bol v mojom prípade čil Disk Drill. Ale vereu som že existuje voláky spósob.

A čil reálny spósob:
To s tým "záloha bola úplne kaput tak nešla namountuvať" bola hovadina. Ona namountuvať v podstate išla. S velikou podmínkou. Nemohol sa použiť klasický macOSový dvojklik, disk utilita a ani nič podobné. V termináli dokonca klasický "hdiutil attach" ťéž nešóv.

Na aspoň čiastočné namountuvaní bolo treba

Code: Select all

hdiutil attach -verbose -nomount -noverify -noautofsck <cesta k sparsebundlu>
a po minimálne trištvrtehodinovej čakačke a kukaní sa na, o moc vác náladu nezlepšujúce, chyby jako napríklad:

Code: Select all

obj_checksum_verify:6644: s1 failed: cksum 0x0000000000000000, oid 0x0, o_xid 0x0, o_type 0x0, o_subtype 0x0, size 4096
nx_corruption_detected_int:60:  Container corruption detected by obj_checksum_verify:6652!
obj_read:6230: s1 oid 0x497fb7 flags 0x10040000003 0x0 type 0x40000003/0xb paddr 0x497fb7 error verifying checksum
btree_check_recent_sanity:798: s1 node 0x137e34 (level 1): error getting index 127 child: 92
nx_check_recent_sanity:1256: s1 omap check failed for omap 909411: 92
nx_checkpoint_find_valid_checkpoint:630:  xid 437 sanity check of recently-changed structures failed: 92
alebo

Code: Select all

obj_init:3207:  wrong object at 0x490068 - wanted oid 0x490068 type 0x4000000b:0x0 xid 0 - got oid 0x2d19 type 0x3:0xe xid 402
nx_corruption_detected_int:60:  Container corruption detected by obj_init:3208!
nx_checkpoint_traverse:855:  failed to get omap for checkpoint FIXUP traverse: 92
nx_checkpoint_find_valid_checkpoint:603:  xid 304 failed to fix up checkpoint data: 92
alebo

Code: Select all

nx_checkpoint_find_valid_checkpoint:603:  xid 395 failed to fix up checkpoint data: 92
2024-08-22 17:17:47.703 hdiutil[64298:12176400] -[DIHelperProxy(Thread) waitForHelperDone] timed out waiting for helper registration
2024-08-22 17:17:47.703 hdiutil[64298:12176400] helper did not register
obj_checksum_verify:6644: s1 failed: cksum 0x0000000000000000, oid 0x0, o_xid 0x0, o_type 0x0, o_subtype 0x0, size 4096
keré sa opakuvali som dospel nakonec k

Code: Select all

nx_mount:1636:  failed to find valid checkpoint: 2
DIDiskImageInstantiatorProbe: interface  3, score        0, CRawDiskImage
DIDiskImageInstantiatorProbe: interface  5, score     -100, CShadowedDiskImage
DIDiskImageInstantiatorProbe: interface  6, score     -100, CWrappedDiskImage
DIDiskImageNewWithBackingStore: CSparseBundleDiskImage
DIDiskImageNewWithBackingStore: instantiator returned 0
Attaching…
DI_kextWaitQuiet: about to call IOServiceWaitQuiet...
DI_kextWaitQuiet: IOServiceWaitQuiet took 0.000002 seconds
2024-08-22 17:34:27.709 diskimages-helper[64301:12214962] DIHelperHDID serveImage: attaching drive
{
    "auto-fsck" = 0;
    autodiskmount = 0;
    "hdiagent-drive-identifier" = "0CD77208-F07E-48B2-9F1B-D2CA1BF90069";
    "unmount-timeout" = 0;
}
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: connecting to myDrive 0x460B
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: register _readBuffer 0x120008000
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: activating drive port 17419
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: set cache enabled=TRUE returned FAILURE.
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] DIHelperHDID serveImage: set on IO thread=TRUE returned SUCCESS.
2024-08-22 17:34:27.712 diskimages-helper[64301:12214962] -processKernelRequest: will sleep received
Finishing…
Finishing…
/dev/disk5          	GUID_partition_scheme          	
/dev/disk5s1        	EFI                            	
/dev/disk5s2        	Apple_APFS                     	
/dev/disk9          	EF57347C-0000-11AA-AA11-0030654	
/dev/disk9s1        	41504653-0000-11AA-AA11-0030654	
/dev/disk9s2        	41504653-0000-11AA-AA11-0030654	
/dev/disk9s3        	41504653-0000-11AA-AA11-0030654	
Toť táto posledná časť ťéž zrovna moc nevypovedá o dobrých vecách, ale vypovedá minimálne o jednej. Záloha sa jako taká aspoň čiastočne namountuvala. Namountuvalo z toho to, čo išlo a ostatné to nehalo tak, síce nenamountované ale stále potenciálne prístupné volačomu, čo by rozumelo vác. V tomto bode som už probuval First Aid z diskovej utility kerý nekončeu nijak ináč, jak len tak, že nič nenašóv, nič neví a nič s tým teda nespraví. Ale narozdíl od diskovej utility mám aj vyšší spomínaný recovery program Disk Drill, ten som teda ešte raz otvoreu a s malou dušičkou som dúfal že keď on tú zálohu nedovolí namountuvať, tak ju aspoň uvidí v tomto polorozbitom stave. A čo čert nesteu, resp. čil asi steu, ukazuvalo sa to tam. Narozdíl od diskutilu kerý na tom APFS kontajneri ukázal velikú chybu a mýtické označení chyby s číslom -64620 som teda povolau Disk Drill na robotu a nehal som ho rozmýšlať. Prešlo 5%, 10%, 20%, 35%, 55% a furt nič. Furt ništ nevideu, nenašóv. Žádny súbor, žádne ništ, ani bodka ani bajt. Strácav som tak náladu a chuť, raz darmo hádam aj nie keď to trvalo pri tých 55% už minimálne dve hodiny plus to ešte nerátam to čo to mountuvaní s hdiutilom trvalo. Ale nehal som ho tak, že hádam volačo nájde.

Našóv. Našóv file table, našóv súbory, našóv obsah, póvodné APFSko vyskladal tak, jak si ho pamatám naposledy. Obsahy som si kukal tedy v Disk Drille a nič nevyzíralo zle. Nastav ale ďalší zádrhel, volákym externým faktorom som bov nútený ten disk se zálohou vypať a ríšiť inšo, takže som ten session nehal uložiť a disk se zálohou som odpojeu. Potom keď som sa k zálohe vráteu som dav načítať session a vyťahuvať súbory. Na disk nasypalo gigabajty relevantných súborov. Priznám sa že som si spätne z tej zálohy potom už nič neprekontroluvával, takže som to potom zebral a dal na místo určeňá.

Tu samozrejme reálny spósob končí, ve vačšine prípadov je záloha zachránená, šetci sú radi a hotovo, tu vlákno bežne končí.

Akurát že v mojom prípade trt. To jak som ja ten disk odpojeu a pripojeu, to jak som načítal ten session, som toto šecko nespraveu úplne dobre. Ja som si totižto tedy nešimóv malé varuvaní v Disk Drille o tom, že to tú zálohu nájsť neví. On ju v zozname ukazuval, on ukazuval póvodne místo zálohy, ale nemal ju namountuvanú tým póvodným spósobom, takže ju nevidel a on na disk nasypal gigabajty prázdnych súborov. Je pravda že ma mohol vác upozorniť alebo potenciálne poslať kadeľahší s tým že to nemám ani robiť keď to nič reálne nevyťáhne, ale to je už jedno. Ve výsledku som na koreň problému aj tak ja došóv. V tomto prípade som ja mosel celé mountuvaní zopakuvať ešte raz, dať to prehľadať celé odzačátku ešte raz lebo ten session furt nevidel tú zálohu namountuvanú a dať to vykopíruvať. Týmto som zabeu ďalších 5 hodín len čakaním na to, aby som vóbec videl voláky obsah zálohy.

Ve výsledku som pochybeu aj ja. Raz darmo, nido neni svatý, ani software, ani človek a ve výsledku samozrejme ani ten hardware.
Čil momentálne ešte čakám kým sa veci vykopírujú, priznám sa že mi dojde že to čil aj kopíruje pomalší jak tedy prvý raz. A samozrejme uvidíme čo z toho bude, lebo z toho čo som zbežne kukol tak súbory majú náhľady, majú obsah, takže to je fakt na lepšej ceste jak to bolo dočilku.

Re: Záchrana vecí ze .sparsebundle zálohy

Posted: Fri Aug 23, 2024 9:40 am
by Morc
Aktualizácia situácie: pozitívna
Situácia aktualizácie: kompletná
Stav funkčnosti: funkčný
Funkčnosť stavu: ťéž funkčná
Já: spokojný

Zadarilo sa, síce som moseu ten účet dohodiť manuálne lebo sa v tej Disk Drillom vyťahuvanej zálohe rozbili symlinky, ale to je minimálny problém.

Idem pokukať čo tam také zaujímavé ešte je, budem v tom moseť spraviť kúštek porádky, ale móžem povedať že móžem byť rád že som rád a že to nedopallo horší jak to už celé bolo.

Ponaučení na záver: odporúčam obejsť sparsebundle zálohu a odporúčam ostať na readonly .dmgčkach