Vytvoření komprimovaného obrazu disku

Včera jsem psal o rychlosti dostupných komprimátorů a o tom, že komprimátor lzop lze s výhodou použít při přenosu dat přes síť. Dnes se pojďme podívat na použití lzopu při zálohování disku a vytváření jeho (komprimovaného) image.

A to s velkou výhodou v případě, pokud zálohujeme ssd.

Vytvoření image disku je v linuxu triviální záležitost. Vše (skoro) je soubor, zařízení disku je také soubor. Můžeme klidně psát:

cat /dev/disk > /storage/soubor

Zařízení /dev/disk pochopitelně nesmí být připojené pro zápis, jinak dostaneme vadný obraz disku. Zálohu celého disku (například notebooku) obvykle děláme z prostředí live cd (např. System Rescue CD), k našemu dnešnímu úkolu ale hravě postačí jakékoliv Live CD vaší oblíbené distribuce.

Kde /storage/soubor je síťový systém souborů (nfs, samba, sshfs – kde by u starším procesorů mohlo zdržovat šifrování), nebo jiné diskové zařízení v daném počítači (např. i USB disk, nejlépe USB3 – USB2 má totiž max rychlost 30MB/s, což by nás omezovalo.)

Uvedeným postupem získáme obraz disku o stejné velikosti jako zálohovaný disk. Což asi nechceme.

Přidáme tedy proudový komprimátor:

cat /dev/disk | lzop > /storage/soubor

Čímž se data rychle zkomprimují. Rychlost se na obyčejném stroji pohybuje přes 100MB/s, teď jsem to zkusil na 4 roky starém PC, průměrná rychlost na 120GB dat byla 85 MiB/s. Což je slušné, na novějších strojích potom krásně saturujeme gigabitovou síť (max 115 MB/s, za normálních podmínek těch snadno zapamatovalených 100 MB/s).

FS a SSD

V případě, že jsou data na klasickém rotačním disku (nebo obecně disku, který nepodporuje trim), tak nám systém souborů příliš nevychází vstříc.

Klasický souborový systém při mazání souboru si pouze zapíše do metadat „toto místo je volné“ a příště jej může použít, ale samotná data mazaného souboru na disku stále jsou, dokud se nepřepíší novými.

Můžeme také soubor mazat speciálním programem, který data souboru přemaže a až potom jej fs uvolní. V ideálním případě by jej měl přemazat něčím snadno komprimovaným.

V Linuxu máme k disposici program shred, který soubor přemaže i nulami (volba -z), případně na celý oddíl můžeme použít program zerofree, který na volné místo zapíše nuly (podporuje jen extX).

Tím se dostávám k SSD. SSD pro svoji činnost a snížení opotřebení buněk potřebuje vědět, které bloky jsou prázdné (z hlediska FS). FS, pokud to podporuje (funkce TRIM), tak po mazání souboru informuje SSD, že tyto bloky jsou volné. SSD je vymaže a připraví pro další zápis.

Vedou se diskuse o tom, zda zapínat volbu discard ve fstabu (takže fs informuje disk sám, možná po každém mazání souboru), nebo zda je lepší používat občas příkaz fstrim, který danou operaci udělá hromadně.

Záleží to jak na implementaci funkce discard ve fs (jak často a intenzivně disk obtěžuje), tak na implementaci trimu ve firmware ssd (jak často disk skutečně tu operaci nad flash paměťmi provede).

Já používám relativně stará a levná ssd, fstrim volaný z cronu jednou za hodinu se mi zdá rychlejší a provoz disku mimo volání fstrim o něco plynulejší. Ale změřeno to nemám.

Podstatné je to, že pokud čteme trimované bloky, tak ssd vrátí blok plný nul. Samé nuly se velmi dobře komprimují.

Takže již uvedené příkazy:

cat /dev/disk | lzop > /storage/soubor

vlastně komprimují pouze aktuální data souborů a přitom o struktuře daného fs neví vůbec nic.

A skutečně, komprimace 120GB SSD s NTFS (Windows 7), kde je zabráno asi 45 GB, vyplivne soubor o velikosti 30GB a to skoro rychlostí gigasítě. Za 6 minut máme zazálohováno.

75GB prázdných bloků disk maximální rychlosti reportuje jako nuly a lzop si s tím hravě poradí.

Obnova

Obnova obrazu disku je stejně triviální:

cat /storage/soubor | lzop -d > /dev/disk

Přečte se image, dekomprimuje se, zapíše.

Tady by mě zajímalo, zda firmware disku pozná bloky plné nul a přeskočí je („inverzní trim“), nebo zda je skutečně zapisuje (pokud je to vůbec potřeba) na flash čipy. Kdyby někdo věděl, poučte mě prosím.