Výcuc 10TB disku, většinou nuly

Výcuc 10TB disku, většinou nuly
« kdy: 29. 11. 2021, 17:10:28 »
Půjde pro přečtení disku

Kód: [Vybrat]
dd if=sda conv=sync,noerror iflag=direct,fullblock bs=1M | pv  -S -s 12345G | gzip -c image.bin
použít... Odhaduji že z 10TB disku to bude max 2TB. Bude dobře gzip fungovat na mnohagigabitové série nul ?
Ale nevím ,jak to  bude v praxi fungovat, když pak se budu chtít na obraz podívat. Existuje nějaký program, který mountne  velky gzip soubor transparentně? (pro windows Imdisk - umí načíst krásně iso soubor a pracovat s ním jako s novou jednotkou)

Rozhodně nechci procházet disk opakovaně. Nebo poradíte nějaký free tool, který by udělal chytře obraz (nějak komprimovaný) nebo aspoň mapu sektorů které jsou ne/nulové a nebo by udělal obraz jako sérii souborů po gigabajtech do složky (10000 není moc) přičemž by se buď každý file komprimoval samostatně a nebo nulové /prázdné bloky by se logicky nezapisovaly.

Spíš mi jde o nasměrovanání a nějakou generální radu, co je nejlepší přístup, ale rovnou vysypat sem mocný příkaz který přesně něco takového udělá taky ocením...

« Poslední změna: 29. 11. 2021, 17:14:44 od Petr Krčmář »


Re:Výcuc 10TB disku, většinou nuly
« Odpověď #1 kdy: 29. 11. 2021, 17:17:33 »
Existuje nástroj archivemount, který umožňuje připojit komprimovaný archiv a za letu k němu přistupovat jako k dalšímu svazku. Uvnitř může být třeba ISO, které se pak připojí jako běžný další svazek. Mělo by to pak fungovat dle očekávání, bez potřeby dekomprese celého archivu.

Re:Výcuc 10TB disku, většinou nuly
« Odpověď #2 kdy: 29. 11. 2021, 18:45:16 »
image s particiami len tak nemountnes...

inak:
Kód: [Vybrat]
dd if=/dev/sda1 of=/tmp/sda1.img bs=4M
mksquashfs /tmp/sda1.img /tmp/sda1.squash.img
mount /tmp/sda1.squash.img /mnt/squash

k3dAR

  • *****
  • 2 982
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Výcuc 10TB disku, většinou nuly
« Odpověď #3 kdy: 29. 11. 2021, 20:15:49 »
image s particiami len tak nemountnes...

inak:
Kód: [Vybrat]
dd if=/dev/sda1 of=/tmp/sda1.img bs=4M
mksquashfs /tmp/sda1.img /tmp/sda1.squash.img
mount /tmp/sda1.squash.img /mnt/squash
takto by skoncil s adresarem v kterem uvidi sda1.img kterej jeste musi pripojit:
Kód: [Vybrat]
mount /mnt/squash/sda1.img /mnt/oddil1nicmene do squashfs muze zabalit i image celeho disku sda, nemusi jen oddil sda1, pak by pokracoval:
Kód: [Vybrat]
kpartx -a /mnt/squash/sda.img
mount /dev/mapper/loop0p1 /mnt/oddil1
mount /dev/mapper/loop0p2 /mnt/oddil2

Jose D

  • *****
  • 889
    • Zobrazit profil
Re:Výcuc 10TB disku, většinou nuly
« Odpověď #4 kdy: 29. 11. 2021, 22:38:37 »
free tool, který by udělal chytře obraz
jestli máš prázdné sektory vynulované, tak to je ideální usecase na nástroje okolo formátu qcow2.

edit: kompresi to umí taky.
« Poslední změna: 29. 11. 2021, 22:40:37 od Jose D »


Re:Výcuc 10TB disku, většinou nuly
« Odpověď #5 kdy: 30. 11. 2021, 09:56:41 »
image s particiami len tak nemountnes...

mount -o loop,offset=...

Ale souhlas, je to přes koleno. Ten LBA offset se musí ručně zjistit/spočítat.

A stejně by bylo vhodnější, pokud je zájem data zkomprimovat, řešit to na souborové úrovni, spíš než na blokové vrstvě = přesně jak zmínil p.Krčmář. Pokud by se O.P. chtěl hmoždit se zjišťováním, které sektory na blokovém zařízení jsou využité vs. nealokované (přestože historicky třeba obsahují nenulová data), doporučuji klíčová slova jako fiemap (to není překlep) nebo bmap. Pokud zadání zní, sehnat tool, který vyrábí "sparse block images", něco co se tváří jako block device (dá se to mountnout) ale reálně to podle výše navrstveného filesystému ignoruje nealokované sektory, tak takovou věc neznám. Z komerčních softů se tomu snad blíží starý Ghost a jeho doprovodné tooly. Nevím jestli třeba Clonezilla tohle v nějaké formě používá - jako že klon do full-size block-level image, ale nealokované sektory se vyplní nulami (nebo zůstanou jako "díry" ve sparse souboru). Závěrem dotaz do Googlu, který vrátil nějaké zajímavé debaty na toto téma - pokud Vás to ještě zajímá...

k3dAR

  • *****
  • 2 982
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Výcuc 10TB disku, většinou nuly
« Odpověď #6 kdy: 30. 11. 2021, 11:09:49 »
image s particiami len tak nemountnes...

mount -o loop,offset=...

Ale souhlas, je to přes koleno. Ten LBA offset se musí ručně zjistit/spočítat.
netreba, kpartx to spocita za tebe, viz 

edit: jinak samozrejme souhlasim ze obecne je urcite vhodnejsi udelat archiv adresarove/souborove struktury nez image disku/oddilu, zalezi co/proc tazatel tim vlastne chce resit... zda jde o systemovej oddil nebo jen datovej atd...
« Poslední změna: 30. 11. 2021, 11:11:50 od k3dAR »

Re:Výcuc 10TB disku, většinou nuly
« Odpověď #7 kdy: 30. 11. 2021, 11:35:58 »
Použil bych filesystém s transparentní kompresí (třeba btrfs) a vytvořil ten image soubor na něm. Pak ho lze i normálně mountnout, ale přitom je zkomprimovaný a zabírá málo místa. Tam ta komprimace funguje po blocích, aby šlo nějak rozumně seekovat, takže úspora nebude až taková, ale v případě hodně nul to bude naprosto dostatečné. Vlastně by to mělo být i rychlejší, protože dekomprese je typicky rychlejší než čtení z disku.

Jinak bych místo starého gzipu použil zstd – je to lepší ve všech parametrech (rychlosti komprese i dekomprese, kompresní poměr).

Re:Výcuc 10TB disku, většinou nuly
« Odpověď #8 kdy: 30. 11. 2021, 13:22:19 »

netreba, kpartx to spocita za tebe,

Nepisal som ze je to nemozne, ale ze je to zbytocne komplikovane.

luvar

  • ***
  • 238
    • Zobrazit profil
    • E-mail
Re:Výcuc 10TB disku, většinou nuly
« Odpověď #9 kdy: 30. 11. 2021, 14:57:49 »
Ja by som zvazil aj live distribuciu Clonezilla https://clonezilla.org/ Neriesil som mount backupnutych veci, ale zato backup disku robi perfektne po particiach a pozna viacero filesystemov (aj ntfs) a backupuje len "potrebne" veci. Napriklad swap subor vynechava a aj zurnalove veci, ci ine nepotrebne metadata... Teda nielen "nuly na disku".

k3dAR

  • *****
  • 2 982
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Výcuc 10TB disku, většinou nuly
« Odpověď #10 kdy: 30. 11. 2021, 15:07:46 »
Ja by som zvazil aj live distribuciu Clonezilla [...]
Clonezilla je na zalohu disku vynikajici, nicmene jeji image lze pripopojit pouze pokud neni komprimovan

Re:Výcuc 10TB disku, většinou nuly
« Odpověď #11 kdy: 30. 11. 2021, 18:54:04 »
to co popisuješ používám na zálohování již několik let. Funguje to a má to některé velmi dobré vlastnosti. Doporučuji ale udělat několik zlepšení. Doplním i některé kvalitativní odhady o výkonu a efektivitě, které mám za ty roky vypozorované. Používám to na vytváření zálohy a to konrkténě buď zálohy oddílu (40 GiB) na kterém je spousta malých souborů a také na zálohy celých disků, které jsou v mém případě velké 500 GiB a 1000 GiB.

Netuším proč přesně tam máš parametry, které tam máš a zejména jestli jejich použití dává smysl, když zohledníš skutečnost že to posíláš přes pv a pak do gzipu. Já používám následující poměrně jednoduchý příkaz a zatím jsem s ním neměl žádný problém.

Kód: [Vybrat]
pv /dev/nvme0n1 | pzstd -o mujdisk.bin.zst
Moje první doporučení je nahradit gzip. Gzip je poměrně pomalý a bude brutálně spomalovat vytváření zálohy. Je dobré si uvědomit jak rychlý disk zálohuješ a jak rychlé je medium na které zálohuješ. V mém případě dělám zálohu SSD (realistická rychlost čtení cca 1 GBps) na mechanický disk (realistická rychlost zápisu cca 150 MBps). Takže v mém případě (nejlépe) potřebuji kompresní algoritmus, který dokáže generovat výstup rychlostí 150 MBps a takových moc není. Je třeba poznamenat, že ne vždy a ne ve všech fázích komprese rychlost limituje pomalejší disk. Pokud máš na disku 200 GiB nul, tak jejich přečtení bude trvat déle než zápis jejich komprimovaného obrazu. Proto když spouštím ten příkaz pv, tak se progressbar neposouvá lineárně, ale v určitých částech roste hodně rychle a v některých zase hodně pomalu. Postupem času jsem zkoušel pigz, lz4 a nakonec skončil u pzstd (paralel zstd), který má sice taky nějaké rezervy a bottlenect v tom, že všechny I/O operace směruje přes jedno jediné vlákno, ale zatím mi výkonově vychází nejlíp a nic lepšího jsem nenašel.

Velikost zálohy, která ti takto vznikne většinou odpovídá velikosti obsazeného místa na disku, právě proto že neobsazené oblasti se dobře komprimují. Nejsem si zcela jist, jestli tomu nepomáhá i TRIM na SSD. Domnívám se, že při čtení neobsazených oblastí řadič disků vrací nuly, protože z logiky věci řadič stjeně může s buňkami manipulovat aby vyvážil jejich zatížení a zvýšil tím jejich životnost. Nicméně v takovém okamžiku je jejich obsah nevalidní a řadič disku to ví.

Jak jsem zmiňoval, tak je dobré si uvědomit jak rychlý kompresní algoritmus potřebuješ, ale je také dobré si uvědomit jak rychlý dekompresní algoritmus potřebuješ. Za určitých okolností můžeš mít jiné požadavky na dekompresi než na kompresi (jeden příklad zmíním dáleú. Taky kompresní algoritmy mohou mít jiné (zejména výkonové) vlastnosti při kompresi a jiné při dekompresi. Musíš volit kompresní algoritmus, tak aby (nejlépe co nejrychleji) splnil tvoje požadavky ve všech případech, kdy zálohu budeš potřebovat.

V diskuzi padlo několik mýtů. První mýtus:

image s particiami len tak nemountnes...

což další diskutující správně vyvrátil, ale pro jistotu přispěl druhým mýtem:

image s particiami len tak nemountnes...

mount -o loop,offset=...

Ale souhlas, je to přes koleno. Ten LBA offset se musí ručně zjistit/spočítat.

Lze namountovat libovolný oddíl, klidně i všechny a není nutné znát/parsovat z tabulky oddílů/odhadovat/počítat žádné LBA. Linux na to má mechanizmus pro všechny myslitené (a někdy i nemyslitelné) tabulky oddílů, takže s MBR ani GPT není žádný problém. Linux to udělá za tebe. Nekomprimované nebo dekomprimované zálohy tohoto typu mají velkou výhodu že je lze (minimálně v Linuxu) snadno připojit a tím například ověřit integritu zálohy.

Pro připojení této zálohy je nutné ji rozbalit. Neznám žádný zpsůob jak by šel namountovat nerozbalený soubor. Omezení vychází z toho, že do komprimovaného souboru nejde (jednoduše) dělat random access. Jakmile jej ale budeš mít rozbelný, tak si obraz disku (nebo i oddílu) můžeš namapovat na loop zařízení příkazem losetup, a pak si můžeš Y-tou partition připojit z loopXpY zařízení. Příkaz losetup si najde sám volné loop zařízení, ale pro determinističnost doporučuji specifikovat loop zařízení ručně. V takové podobě to můžeš udělat následujícím příkazem:

Kód: [Vybrat]
losetup -Pr /dev/loop123 mujdisk.bin

Soubor mujdisk.bin je dekomprimovaný soubor zálohy mujdisk.bin.zst. Zařízení loop123 je neobsazené loop zařízení. Pokud u tebe loop123 existuje, tak použij jiné libovolné číslo, které zatím neexistuje. Parametr -P znamená partscan. Příkaz tak nechá Linux prosekonvat tabulku oddílů a zaregistruje jednotlivé oddíly. parametr -r zajistí, že loop zařízení bude readonly, ale můžeš ho vynechat a pak do (rozableného) obrazu můžeš klidně zapisovat.

Jakmile budeš mít loop zařízení, tak si můžeš např. čtvrtý oddíl připojit do složky aa jednoduše pomocí:

Kód: [Vybrat]
mount -o ro /dev/loop123p4 aa

Jako velkou výhodu těchto záloh považuji, že zatímco prakticky ve všech krocích pracuješ s jedním vlekým souborem, tak finální obnovu můžeš provést na jiném PC/serveru a přenést zpět pouze soubory, které chceš obnovit. Jako další výhodu považuji, že lze velmi snadno ověřit integritu zálohy. Prostě to skusíš připojit, podívaš se jestli tam jsou soubory jaké chceš, můžeš si ověřit, že jsou nepoškozené, atd. Já osobně své zálohy nahrávám do cloudového uložiště buď AWS S3 nebo Azure Blob Storage. Vždycky po tom co zálohu nahraju do cloudu, tak si tam pronajmu server na kterém si zálohu stáhnu, zkontroluju chcekcsum a zkusím ji připojit abych se ujistil, že záloha je funkční. Pokdu funkční je, tak ji změním access tier na archive, abych za to moc neplatil (v mnohých datacenterech u obou providerů, lze takto mít ulžoené zálohy za cenu 1 USD za 1 TB za měsíc). Tady se dostávám k tomu co jsem lehce naznačil jednom z předchozích odstavců, kdy jsem popisoval důležitost volby kompresního algoritmu. Pro obnovéní souboru ze zálohy nebo ověření integrity ji potřebuješ rozbalit. Server v clodu ale má jiné vlastnosti než disk ze kterého byla prováděná záloha a disk na který byla záloha ukládana. Jakmile máš zálohu uloženou perzistentně na cloudovém uložišti, tak na samotném serveru, kde provádíš obnovu nebo verifikaci integrity, ji již nepotřebuješ perzistentně. Nabízí se tak možnost že se zálohou nebudeš pracovat na pomalém disku serveru v cloudu, ale na potřebnou krátkou dobu si pronajmeš server s velkým množtvím RAM (AWS i Azure mají i servery s 16 TiB RAM, které se pro tyto účely hodí) a se zálohou budeš pracovat v ramdisku, který je exterémně rychlý. Pokud operaci se zálohou uděláš rychle (a pak nezapomenš server zlikvidovat), tak to ani není moc drahé. V cloudu záleží na hodně faktorech, mimo jiné vedle koho běžíš, protože je to sdílená infrastruktura, ale obecně tam ramdisk dosazuje 20 - 80 GBps. Nicméně po počáteční euforii je potřeba se vrátit na začátek: Je použitý komrpesní algorimtus (který při kompresi byl dimenzován na output speed 150 MBps) dostatečně rychlý i pro dekompresi na rychlostech 20 - 80 GBps? Odpověd je u většiny algoritmů bohužel ne. Ani ten pzstd, zejména kvůli zmíněnému botlenecku, neposkytuje kdovíjak dobrý výkon. Práce se zálohou v ramdisku bude rychlá, ale ne tak rychlá jak bych např. já potřeboval. Já jsem se zálohou několikrát v ramdisku zkoušel pracovat a pocitovně mi to přišlo zhruba 4x rychlejší než když zálohu zpracovávám nad instancí s sice malou RAM, ale zase s lokálním NVME SSD (v Azure řada Ls a Lsv2, V AWS řady i3 a i3en) a to mi přijde jako malý speedup, když vezmu v potaz, že porovoz serveru s hodně RAM je mnohem dražší.

Pravděpodobně, ale mžůeš najít spoustu dalších use case pro tyto zálohy a mě se za těch několik let kdy je dělám osvědčily. mají nějaké nevýhody, jako že je nelze dělat za běhu, ale i tak mi připadají jako docela dobré a spolehlivé.

k3dAR

  • *****
  • 2 982
  • porad nemam telo, ale uz mam hlavu... nobody
    • Zobrazit profil
    • E-mail
Re:Výcuc 10TB disku, většinou nuly
« Odpověď #12 kdy: 01. 12. 2021, 00:37:19 »
[...] V diskuzi padlo několik mýtů.
[...] Pro připojení této zálohy je nutné ji rozbalit. Neznám žádný zpsůob jak by šel namountovat nerozbalený soubor.
to je mytus ;-) viz

Re:Výcuc 10TB disku, většinou nuly
« Odpověď #13 kdy: 01. 12. 2021, 07:43:25 »
@janevim12345: děkuji za smeč a pojednání v kostce, přesně kvůli tomuhle sem chodím :-)

@k3dAR: taky nezklamal, díky :-) K tomu squashfs: v práci dělám support jedné značce embedded zařízení, co mají uvnitř Linux... a všiml jsem si onehdá, že jejich balíčky pro update firmwaru se dají otevřít klikacím 7zipem. Moc jsem tomu nevěnoval pozornost, až mě jednou nějak napadlo se podívat, co je to přesně za formát - odhadoval jsem něco na způsob .tar.gz. Chyba lávky: ony jsou to squashfs image. A není to tak, že by ten image byl přímo bootovatelný - on je opravdu použitý spíš jako tarball, při "instalaci" si z něj živý firmware jenom vyzobe hrst obsažených souborů, něco prostě zkopíruje, něco někam rozbalí, něco spustí přímo z toho mountnutého squashfs, následně pár věcí prolinkuje a tak. Je vidět i do instalačního skriptu... zjevně ten "squashfs místo tarballu" používají především proto, že se dá přímo mountnout, něco z toho třeba rovnou spustit, přitom se nemusí nic explicitně dekomprimovat do RAMdisku apod. = asi se s tím prostě líp pracuje...

@Petr Krčmář: archivemount vypadá taky zajímavě.

Tady se člověk dozví věcí :-)
« Poslední změna: 01. 12. 2021, 07:45:59 od František Ryšánek »

Re:Výcuc 10TB disku, většinou nuly
« Odpověď #14 kdy: 01. 12. 2021, 09:34:27 »
[...] V diskuzi padlo několik mýtů.
[...] Pro připojení této zálohy je nutné ji rozbalit. Neznám žádný zpsůob jak by šel namountovat nerozbalený soubor.
to je mytus ;-) viz

Já jsem tam schválně nepsal že neexistuje žádný způsob, ale že ho neznám. Podle mě je ten výrok korektní (byť docela neužitečný).