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.
pv /dev/nvme0n1 | pzstd -o mujdisk.bin.zstMoje 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:
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í:
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é.
19 Odpovědí
8356 Zhlédnutí