Fórumok
Sziasztok!
A Google nem igazán segített, de hátha tudtok ti okosságot. dd-vel készített és gzip-pel tömörített lemezképet szeretnék csak olvasható módban loopback eszközként használni. Egyrészt mountolni szeretném a tartalma miatt, másrészt pedig nekiereszteném a photorec-et a törölt fájlokért. Viszont helyszűkében vagyok, az előre kitömörítés nem járható.
Van ötletetek?
Hozzászólások
A gzip önmagában nem igazán lesz jó erre, mert az stream alapú tömörítő. Ez azt jelenti, hogy végigmegy egy stream-en és az egészet tömörítve adja vissza a végén. Kitömörítéskor meg szintén végigmegy az egészen, és eredetiben adja vissza stream-elve. Viszont olyan művelet nem értelmezett rajta, hogy add vissza kitömörítve csak az 1234. diszk blokkot. És ugye a filerendszer ami benne van, az pont ilyen műveleteket akarna. Ezért nem működik nyilván, mivel nem lehetséges bármely blokk lekérése esetén az egészet az elejétől kezdve kitömöríteni minden egyes alkalommal.
Más jellegű megoldás kell neked erre a célra, pl. squashfs. Itt van egy leírás róla, hogyan lehet úgy trükközni, hogy készítesz egy nem tömörített lemezképet, azt berakod egy squashfs-be, és aztán a mountolt squashfs-ből mount-olod az eredeti lemezképedet.
https://unix.stackexchange.com/questions/31669/is-it-possible-to-mount-…
ez jo otlet, lneygeben tomoritett disk?
Ez így nem egészen igaz, mert a zlib tartalmaz ilyen wrapper függvényeket (gzopen / gzclose / gzread stb. tud seekelni is). Viszont nem túl hatékony, úgyhogy szerintem is a squashfs (vagy cramfs, dwarfs vagy hasonló) a legjobb megoldás erre.
Én egyébként az ilyesmit nem szoktam felcsatolni, hanem simán egy archive fájlban tárolom és a Midnight Commander-rel használom. Az úgy csinál, mintha egy sima könyvtár lenne, bele lehet lépni, keresni lehet, ki lehet másolni belőle.
Ha a felcsatolásra is mindenképp igény van, akkor az archivemount-ot szoktam használni (illetve van még a google-ös fuse-archive is, de azt még nem használtam élesben). Ez utóbbi kettő megeszi a gzip-elt lemezképet, de csak akkor, ha az iso9660 formátumú.
Ez tömörített lemezképen egész biztos nem fog menni. Tömörítés helyett próbáld meg inkább a lemezképet sparse fájllá alakítani (úgy a lemezképben jellemzően megtalálható nagy üres területek nem foglalnak tényleges tárhelyet).
Na de tudtommal belépéskor ez is kicsomagolja valahova, jellemzően a /tmp-be. Ha nincs annyi szabad hely, akkor ez ugrott is.
Viszont így fog találni bármi törölt adatot a photorec?
Persze, a sparse file csak annyit tesz, hogy a csupa nulla blokkokat nem tárolja ténylegesen a lemezen. Ettől még a fájl tartalma pontosan ugyanaz marad. (Általában az így nyert terület nem jelentős, de egy lemezkép esetében jellemzően nagyon sok az "üres hézag" a fájlban.)
Apró probléma, hogyha valamikor is volt az adott adatblokk írva, akkor az nem nulla, még akkor sem, ha az adott fájl törlésre került, mert a legtöbb Linuxos fájlrendszer a törlés során csak a metaadatokat pucolja ki, illetve az adott fájl adatblokkjait rakja rá a szabad blokkok listájára...
Nem értelek, miért lenne ez probléma? Pont, hogy lehetetlen lenne a törölt fájl visszaállítás ennélkül. Ennek nincs köze a tároláshoz, bitre pontosan ugyanazt olvasod ki egy sima fájlból és egy sparse fájlból is.
ps: a sok nulla jellemzően a lemezfájl végén, a még fel nem használt inodebejegyéseknél az inode tábla végén, a preallokáció miatt minden egyes fájl végénél, a szektorcsoportokat használó fájlrendszerek (pl. ext234) esetén minden csoport végén stb. található. Rengeteg helyen van egy fájlrendszerképben egy valag nulla, még akkor is, ha a törölt fájlok tartalmát effektíve nem nullázza ki.
Csak amíg a sparse "arra épít", hogy sok benne a nulla bájtokból álló terület, egy valós, sokat használt diszken messze nem lesz annyi, mint amennyi a szabad hely. Ahogy írod, gyakorlatban a metaadatokban van explicit kinullázott terület, de az a (jóval) kevesebb - vagyis az n*00 bájtok "tömörítésével" messze nem lehet annyit spórolni, mint mondjuk a /var/log/lastlog esetében .-)
Nyilván, viszont még így is jó sokal spórol, simán el tudom képzelni, hogy ez is elég (tapasztalatom szerint egy sokat használt fájlrendszer esetében is még mindig rengeteg a nullás terület). Persze itt tudni kéne pontosan, mennyi is az annyi, addig csak tippelhetünk, hogy mennyi spórolás elegendő.
Az biztos, hogy így a törölt fájl visszaállítás is egész biztos lehetséges; csak olvasható tömörített lemezkép esetén ez szerintem nemigazán megoldható (bár ezt a photorec programot én még nem használtam, lehet, ez utóbbiban tévedek).
De, sajnos el kell hogy szomorítsalak, mert igaz. A seek az egy emulated művelet, le is van írva a dokumentációjában, hogy "extremly slow". Pont azért, mert NINCS olyan, hogy csak az 1234. blokkot olvassa be. Be kell olvasnia az elejétől az egészet újra.
Én is írtam, hogy nem túl hatékony, na de attól még nagyon is létezik!
Na most akkor vagy lassú, vagy nincs...? A kettő egyszerre nem lehet.
Egyébként a deflate pont egy olyan stream tömörítő, hogy egy pici context elég neki, ami könnyedén indexelhető kicsomagolt pozícióra. Például elég elmenteni minden 1M-es offszethez a contextet, és onnantól nem kell az egész fájlt mindig végignyálazni, hanem elég a legnagyobb 1M-es offszethez tartozó context-et bemásolni egy futó z_stream-be és elég csak onnantól kicsomagolni, hogy egy tetszőleges pozícióhoz eljussunk.
Nincs. Nem tud olyat az implementáció, hogy csak az 1234. blokkot olvassa be. Beolvassa az elejétől, és aztán visszadja csak az 1234. blokkot. Hogy jól értsd mi a különbség, kiemeltem neked a lényeges szavakat.
Persze ha szeretnéd, tőlem nyugodtan becsaphatod magad azzal, hogy lehet seek-elni, és a gzip csak az 1234. blokkot adta vissza neked, mert te ennyit látsz az egészből.
matrioska
szerintem két lépéses:
1. fuse-mount zip adott helyre ( https://github.com/google/fuse-archive )
2. adott hely mountolása a megfelelő paraméterekkel másik helyre (a lemezképnek megfelelően, vagy automatikus felismeréssel)
Ez így nem lehetséges. A legközelebb az áll hozzá, hogy felmásolod kitömörítve egy olyan fájlrendszerre, ami tud transzparens / on the fly / röptömörítést, pl. Btrfs, ZFS, akkor neked meg a programok felé úgy tűnik, hogy tömörítetlen.
Esetleg, ha belefér a RAM-ba, mert van hozzá elég memóriád, akkor oda még kitömörítheted. Bár azt nehezen hiszem, hogy manapság valakinek helyproblémája legyen, mikor már évek óta ilyen olcsóak a háttértárak.
“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)
mountolni nem fogod tudni az 100%, ahogy fentebb mar leirtak, azret mert a gzip nem tud random poziciobol kitomoriteni, csak folyamatosan az elejetol kezdve.
photorec: meg kell nezni, mivel az elvileg linearisan olvassa a "disket", lehet tud stdinrol/pipebol is dolgozni? vagy fel kell darabolni a cuccot, gunzip+dd-vel mindig csak egy par gigas reszt kitomoriteni belole es azokra kulon kulon rakuldeni a photorec-t. erdemes par mega overlapot is hagyni, hogy ha epp a file kozepen sikerult vagni az is meglegyen.
illetve ami meg eszembe jutott: qemunak mintah lenne tomoritett disk img formatuma, abba atkonvertalni, es csinalni egy vm-et aminek odaadod azt a tomoritett diskimgt.
de a legjobban akkor jarsz ha szerzel egy eleg nagy hdd-t kolcsonbe, vagy kolcsonkersz, vagy veszel valami webshopbol aztan 15 napon belul visszakuldod... de erre egy hasznalt is megteszi, nem hiszem hogy draga lenne, persze nem tudjuk 1-2TB vagy 100TB az adat.
Igen, végül én sem találtam más megoldást, mint hogy kell még diszk.
>>abba atkonvertalni, es csinalni egy vm-et aminek odaadod azt a tomoritett diskimgt
vagy nem átkonvertálni, hanem a ricpet által is említett matrjoska trükkel egy tömörített qcow2-be rakni a kitömörített eredeti dumpot, és akkor vm sem kell
Szerintem nem erdemes a matrjoska trukkozes, csak bonyolitja az eletet.
(-c compressed, -F output format, a -o compression_type=zstd nem biztos, hogy tamogatott, akkor marad a default zlib)
Utana
Es innentol a /dev/nbd0 alatt ott figyel a teljes image block device-kent. Lehet rajta mindent csinalni, amig a read-only mod megfelel: kpartx -a, mount, photorec...
Régóta vágyok én, az androidok mezonkincsére már!
jogos, thx
(valamiért azt gondoltam, hogy a qemu-img alapból csinál sparsifyt, amit "nem szívesen" engednék egy megmentendő lemezképre)
mondjuk itt meg mindig az a gond hogy neki original.img.gz-je van es nincs helye kibontani...
Ja, hát kérem, az élet nem habostorta. Az adatmentés hely nélkül meg olyan, mint vőlegény nászéjszakán szerszám nélkül. :)
A stratégiát alapvetően az határozza meg, hogy mennyi az annyi.
Mekkora most a gz? Mennyi lenne kitömörítve az image? Kb mennyi terület foglalt benne (beleértve a szemetet is)? Kb mennyi adat ami megmentendő? És ehhez most mennyi hely áll rendelkezésre? Illetve reálisan mennyi helyet tudsz még keríteni?
Illetve: van-e bármi belső struktúra, bontható-e önálló egységekre (pl particionált-e, és mekkorák a particiók), amikkel külön-külön lehet foglalkozni.
Ha ezek ismertek, akkor kb el lehet kezdeni gondolkodni.
Ha a .gz legalább 2x (de reálisan inkább 3x) nem fér el, akkor minden konverzió felejtős, és el kell gondolkodni azon is, hogy a gz-ből kimentett adatokat is valahova tenni kell majd...
Ez esetben maximum azt tudom elképzelni, hogy pl ezzel https://github.com/google/fuse-archive felcsatolod a gz-t (valamelyik feature requestben írják, hogy működik mezitlábas gz-vel is, nemcsak .tar.gz-vel: https://github.com/google/fuse-archive/issues/5)
Ha 1 konverziónak megfelelő hely van (vigyázz, a .gz-nél kisebb blokkmérettel fog dolgozni, rosszabb lesz a tömörítési aránya), akkor fuse-archive mount majd qemu-img convert.
B variációnak az üres helyre egy btrfs-t létrehozni, tömörítést bekapcsolni rajta és oda kitömöríteni a gz-ből az image-et, aztán hagyományos módon losetup-pal loop device-ra felvenni.
Lehet még zcat-tal qemu-img dd subcommandba pipe-olva átfejteni (sose csináltam) illetve stdin-ről qemu-nbd-be pipeolással ugyanez: https://unix.stackexchange.com/questions/536404/qemu-img-compress-image-from-stdin-gunzip de így tippre azt mondanám, hogy ezekben az esetekben a végeredmény nem lesz tömörített.
Régóta vágyok én, az androidok mezonkincsére már!
A lemezkép tömörítetlenül kb. 1 TB. És még hely kell a photorec által visszaállított állományoknak is, mert az nem tud szelektíven dolgozni: visszahoz mindent, amit talál. És lemezképből kettő van, jó lenne, ha a másodikra átváltáskor nem kellene letörölni az első kicsomagolt lemezképet és a visszaállításából származó eredményt.
Biztos olcsó a háttértér, de csak ezért egyelőre nem vennék ~5-10TB-os háttértárat, amire utána nincs szükségem. Elvileg sikerül kölcsönkérnem egyet.
Ja ok, így azért más a helyzet, eredetileg úgy hangzott (vagy Arpi értelmezte úgy?), mintha in-place kellene megoldani az eredeti gz-vel, mert annyira nincs hely. Ugyan írtam arra is ötletet (fuse-archive), de fogalmam sincs mennyire működne a gyakorlatban ekkora file-on.
Ha egy teljes kitömörítésre van lehetőséged, akkor a qemu-img convert-es megoldás járható lehet. Ez stabilan működő megoldás, 5-6 éve Openstackkel rendszeresen használtuk.
A btrfs-t igazán jó szívvel nem tudom ajánlani. Mondjuk rég próbáltam és biztos javult a stabilitása azóta, de akkor (bekapcsolt tömörítésnél) képes volt saját magától is szétesni. Ehhez foghatót még reiser4 és hasonló bétás filerendszerekkel sem tapasztaltam.
Régóta vágyok én, az androidok mezonkincsére már!
Igen, az lett volna az eredeti cél, hogy a tömörített lemezképet ne kelljen kibontani, mert akkor biztosan lett volna annyi szabad hely, hogy elfért volna mindkét visszaállítás eredménye. De már látom, hogy ez nem járható út. Viszont nagyon érdekes, tanulságos dogokat írtatok válasznak.
Egy 3TiB diszk kb. 30-35E Ft, egy külső ház olyan 6-8E Ft. és ez nem "kidobott pénz", mert a "műtét" után ide lehet majd pakolni a mentéseket/archivált adatokat - aztán később ebből tovább lépni valami raid-et tudó megoldásra archiválási célra.
https://en.wikipedia.org/wiki/SquashFS
Oké, de ennek (meg más javasolt megoldásoknak is) az a hátránya, hogy nálam már csak a tömörített lemezkép van.
Hozz létre egy squashfs-t, és tömörítsd ki oda. És akkor ott lesz a squashfs-en a tömörítetlen lemezkép, amit majd tudsz mount-olni. És ha szerencséd van, akkor nem foglal sokkal többet végső soron tényleges diszk helyből, mint a gzip-es, tehát kis szerencsével akár még meg is tudod oldani kevés hellyel.
mikor utoljara foglalkoztam squasffs-el akkor letrehozni ugy lehetett hogy megadtad a konyvtarat aminek a tartalmabol letrejott, es amugy is readonly. nem hiszem hogy van mkfs.squash vagy ilyesmi ami egy mountolhato irhato valamit hoz letre...
Valóban nem pontos a fogalmazás, nem az elkészült squashfs-be kell beleírni, hanem már úgy kell létrehozni.
Amit feljebb linkeltem https://unix.stackexchange.com/a/75590 ott pont ilyesmiről írnak: Streaming Compression To avoid making a separate temporary file the full size of the disk, you can stream into a squashfs image.
Azért meg kell nézni, hogy ez applikálható-e jelen gzip-es esetre, mert kicsit más a kiindulási állapot.
Hát pedig majdnem, merthogy van az mksquashfs és az mountolható valamit hoz létre.
Persze read-only. Kivéve ha rádobsz egy overlay-t, de az már másik téma.
Ez oké, de ez csak a létező állományokat emeli át tömörített, read-only formátumban a squasfs image-be. De ha photorec-kel akarunk vadászni törölt image-ket, akkor az nem fog bekerülni a squasfs-es cuccba. Tehát báriféle fs konverzió ezt a célt élből hiúsítja.
https://libguestfs.org/nbdkit-xz-filter.1.html
https://manpages.debian.org/testing/nbd-client/nbd-client.8.en.html
Szerk.: a gzip-pel már tömörített image file-t tömörítsd át:
nem tudom mi a pontos use case ezesetben, de kedvencem amikor a 'mentsük meg az adatokat' felkéréssel jönnek olyanok, akik még a szükséges adathordozó árát sem hajlandóak a szaraik 'visszaállítása' érdekében kifizetni.... na azok meg is érdemlik. De azok is akik 'occón' akarnak rajtuk segíteni, még ha a jó szándék is vezérli őket.
mindeközben érdekel, hátha valaki tud varázsolni :D
Én azzal szoktam kezdeni, hogy kell egy legalább 2x akkora diszk, mint a 'megmentendő'.
Ha már itt 'pénzügyi' akadálok vannak, akkor ilyenbe nem érdemes munkaidőt sem fektetni - szerintem.
van is erre gyakorlati példám, haverom erre aszongya:
zrubi.hu
> Én azzal szoktam kezdeni, hogy kell egy legalább 2x akkora diszk, mint a 'megmentendő'.
igen, de volt mar olyan kb 10 eve, hogy hoztak egy 12 diskbol allo 30TB-os raid5 tombot amit a storage egyszer csak nem latott tobbe. kerdes volt, hogy egyaltalan mentheto-e? egy kerdes megvalaszolasahoz nem vesz az ember hirtelen 60TB-nyi disket, foleg akkor amikor ezek meg aranyarban voltak, es nem is volt trivialis egy gepbe egyszerre ennyit bekotni...
en akkor ugy oldottam meg, hogy fogtam egy 3tb-os disket es mind a 12 forras disk elso 128 GB-jat ramasoltam, azzal kezdtem el dolgozni. ha "kicsiben" mukodik (osszerakhato a tomb annyira hogy latszodjanak az adatok) akkor menni fog nagyban is...