Inkrementální zálohování pomocí btrfs snapshotů

Dlouho jsem na zálohování dat program rsnapshot. Který pomocí rsync a hardlinků udržoval několik inkrementálních záloh. Po vyzkoušení nového systémů souborů BTRFS jsem též změnil způsob zálohování.

RSnapshot

Program rsnapshot je funkční a léty prověřený. Funguje jednoduše tak, že se pomocí rsync kopírují data do záložního adresáře a takto odzálohované soubory se potom pomocí hardlinků deduplikují, což je značná úspora místa na disku.

Rsync je velmi úsporný, co se týče spotřeby prostředků a po síti přenáší pouze změněná data, nikoliv celý změněný soubor. Toto zálohování je tak velmi rychlé a lze jej provádět často.

Je tak k disposici libovolné množství záloh, nezměněné soubory ukazují na totéž místo na disku, místo tak zabírají pouze celé soubory, které se změnily. Tolik ve stručnosti, více o algoritmu lze nalézt na webu rsnapshotu.

Každý změněný soubor je ovšem na disku uložen znovu celý, i když se v něm od minulé zálohy změnilo pouze několik bajtů.  Další nevýhodou rsnapshotu je veliké množství souborů na systému souborů a také to, že většina souborů jsou pouze hardlinky. Systém souborů tak nemůže příliš optimalizovat uložení souborů na disku. Což je do značné míry teoretická záležitost a nemá vliv na funkčnost a bezpečnost uložených dat. Pouze na rychlost.

BTRFS

Moderní souborové systémy, jako například ZFS fimy Sun (dnes již Oracle), nebo (též Oraclem) vyvíjený BTRFS nabízejí nové možnosti práce se souborovým systémem. Mimo jiné též možnost pořizovat snímky systému souborů. Snímek (snapshot) je „otisk“ systému souborů v daném okamžiku, se všemi soubory a jejich daty. Snímků je možno vytvářet téměř neomezené množství.

Důležité také je, že snímky zabírají pouze minimum místa na systému souborů. Pokud si osnímkujeme soubor a poté na něm uděláme nějaké úpravy, BTRFS zaznamenává pouze tyto upravy.  Soubor sice vidíme dvakrát, jednou starý, podruhé nový a změněný, ale reálně na disku zabírá pouze jednu velikost + velikost změn. BTRFS také podporuje automatickou transparentní kompresi, a tedy soubory na disku reálně zabírají ještě méně.

BTRFS používá koncept copy-on-write, kdy se pro každý měněný blok souboru alokuje blok nový, který se zapíše na disk a až nakonec se přesměrují ukazatele na tento blok. Což je vysoce bezpečné — pokud nedojde (například z důvodu výpadku napájení)  ke konečnému přesměrování ukazatelů na nový blok, soubor obsahuje konzistentní data tak jak vypadala před zahájením zápisu.

Tento koncept (copy on write) se používá i pro snapshoty.  V určitém snapshotu má soubor přidělené určité bloky a tyto bloky se nikdy nemění právě z toho důvodu, ze jakýkoliv zápis do tohoto souboru v jiném snapshotu (ano, btrfs má všechny snapshoty zapisovatelné, v jeho konceptu ani o snapshoty, tak jak je známe z ostatních systémů, nejde), vytvoří nový blok. Snapshoty jsou tak velmi úsporné, místo navíc je nutné alokovat pouze pro změněné bloky.

Což je další výhoda oproti systému rsnapshot ten hardlinkoval celé soubory, sebemenší změna (byť i pouze jediného 4kB bloku)  znamenala nutnost uložit celý soubor znovu.

Ingredience máme

Vše nutné pro inkrementální zálohování tedy máme. Umíme kopírovat data úsporným způsobem pomocí rsync a to i ze síťových strojů. A umíme jednoduše vytvářet snímky souborového systému, které jsou velmi úsporné, co se týče diskové kapacity. Kombinací obou přístupů lze vytvořit systém inkrementálních záloh.

Algoritmus je tedy jasný:

  1. Udělat zálohu do adresáře pomocí rsync.
  2. Vytvořit snímek tohoto adresáře pomocí btrfs.

V praxi:

# odzálohuje /home do adresáře /backup
/rsync -a --delete /home /backup/

# vytvoří snapshot adresáře /backup do /.snapshost/backup_$(date +%Y%m%d-%H%M)
btrfs subvolume snapshot /backup /.snapshots/backup_$(date +%Y%m%d-%H%M)

Každé spuštění tohoto skriptu vytvoří novou zálohu adresáře /home do adresáře /backup a udělá snímek adresáře backup pojmenovaný aktuální časovou značkou.

Místo na disku

Změny souborů a nové soubory místo na disku samozřejmně ukusují. Snímky je tedy potřeba mazat. Tady se projeví další dobrá vlasnost BTRFS. Snímky (na rozdíl třeba od ZFS) jsou zapisovatelné. Jestli je to pro zálohu dobré nebo ne, nechám na laskavém posouzení čtenáři. Důsledkem toho je, že můžeme ze snímků libovolně mazat a tím uvolnit nějaké místo na disku.

Záloha má být samozřejmně konzistentní, mazání ze snímků není to pravé ořechové. Je tedy potřeba mazat jednotlivé snímky.

Opět jednoduchý příklad:

btrfs subvolume delete /.snapshots/backup_"nejake datum"

Smaže konkrétní snímek a uvolní místo, které zabírají data tohoto snímku. Možná vás překvapí rychlost s jakou BTRFS maže libovolně velký snímek. Je to mnohonásobně rychlejší, než mazat hardlinkované snímky z rsnapshotu.

Závěr

Tento systém používám již několik měsíců a zálohuji několik cílů každý den (dříve každou hodinu – opravdu to jde, je to velmi rychlé). Celkově mám na disku přes 5tisíc snímků. Mohu vytáhnout libovolný soubor z libovolného data.

BTRFS je velmi mladý systém souborů, který je ve vývoji. Proto doporučuji opatrnost a data mít na více místech (což platí obecně).

Musím říct, že snapshoty jsou ona pověstná killer featura, díky které jsem BTRFS začal, ač s jistou nedůvěrou, používat. Lze je používat i na normální práci. Systém správy verzí sice nenahradí (je to něco jiného), na druhou stranu málokterý systém správy verzí umožňuje pracovat se stovkami gigabajtů dat touto rychlostí.

 

Příspěvek byl publikován v rubrice BTRFS, Linux, Systémy souborů. Můžete si uložit jeho odkaz mezi své oblíbené záložky.

4 komentáře: Inkrementální zálohování pomocí btrfs snapshotů

  1. lzap napsal:

    Pěkné. Taky se už těším. Ale já si raději počkám. Nedávno se to odsunulo do Fedora 17 kvůli nehotovým nástrojům pro opravu FS.

    • Heron napsal:

      Mě spíše děsí jiná věc. BTRFS má ještě mnoho featur k implementaci. Což si může vyžádat změnu diskového formátu. Pokud bude hodně nasazení, tak se obávám, že vývojáři ustoupí změně formátu a prostě to nabastlí na stávající.

      Ale jinak je to fajn FS. Ještě by se mi líbila automatická deduplikace a také implementace raid5.

  2. Pingback: Dva způsoby zálohování snapshotů btrfs | Heronovo

  3. Pingback: BTRFS v praxi po 5 letech | Heronovo

Komentáře nejsou povoleny.