Dotaz: Rozdílová záloha blokového zařízení

[vboh]

Ahoj. Chtěl bych provádět rozdílové zálohy blokového zařízení. Jenže to běžné nástroje neumí. Takže mě napadlo udělat něco ve stylu "dd if=/dev/mapper/data-system bs=1M | split -b 1M -d -a 8 - data-system.img.part" a poté na tom provádět rozdílovou zálohu. Jenže to má jednu obrovskou nevýhodu: musím mít nějaké úložiště (nejlépe lokální), na které by se to provedlo a až poté by se prováděla rozdílová záloha oproti těm vytvořeným souborům. Napadlo mě, jestli neexistuje nějaký speciální souborový systém, který by zobrazoval soubory, které by odpovídaly blokům blokového zařízení (např. soubor blok55 by odpovídal nějaké části blokového zařízení). Oproti tomu už by totiž šla přímo dělat rozdílová záloha. Existuje nějaké takové řešení nebo si musím něco napsat sám (třeba přes FUSE)?

Odpovědi

[NN]

Jen se ze zvedavosti zeptam o co se vlastne jedna ? Co je to za blokove zarizeni ? Nema souborouvy system ?

[vboh]

V podstatě se mi konkrétně jedná o LVM oddíly či jejich snapshoty. Ale to je víceméně jedno. Důležité je, že to chci dělat na úrovni toho zařízení, ne na úrovni souborového systému.

[JanM]

Jenom chcete nebo je za tím nějaký praktický důvod?

Co třeba ZFS jako volume manager? (Tedy vytvořit kontejner zvol a ten použít s LVM.)

Snapshoty lze dělat v ZFS a rozdílově zálohovat zvol (budete mít tedy zálohované blokové zařízení).

[l4m4]

Na rozdílovou zálohu potřebuješ jednak nový stav a jednak starý stav. Kde máš starý stav?

Uchovávat rozdíly mezi nestrukturovanými binárními daty lze pomocí rsync --write-batch.

Ale celé je to podezřelé. Zálohovat živý fs bez spolupráce s tím fs stěží povede ke konzistatnímu snapshotu. A ve spolupráci s fs to dělat nechceš.

[vboh]

Na serveru provozuji KVM virtualizaci. Potřebuju zazálohovat větší množství strojů a nevadí mi chvilková nedostost virt. strojů. Všechny disky KVM strojů jsou LVM volumy hostitelského stroje. Můj plán je před zálohou zastavit virt. stroj, uložit jeho stav na disk, udělat LVM snapshot a obnovit virt. stroj. V té chvíli mám plně konzistentní stav soub. systému (i bez jeho spolupráce) vč. obsahu paměti stroje. Takový LVM snapshot bych chtěl rozdílově zálohovat. Co se týče těch stavů, tak starý stav je zálohované blokové zařízení a nový stav je aktuální stav toho zařízení (zde lvm snapshotu). To nestačí?

[Aleš Kapica]

8-D Zapomeň na to.. Cokoliv na úrovni blokových zařízení ti bude trvat nechutně dlouho a obnova bude s výsledkem nejistým.

Záleží pochopitelně co to je za virtuály a do jaké míry je můžeš udělat podle sebe. Mám jedno řešení, které je velice efektivní - využívá NBD, bohužel ale není dostatečně blbuvzdorné. Je však ideální pro provozování strojů u kterých nemůžeš vrtat dovnitř.

Já provozuji v KVM linuxové virtuály. Mám je všechny jako diskless nad NFS. Je nutno říct, že jde o nejodolnější kombinaci. A věř, že vím o čem mluvím. Stroje jsou umístěny nad DRBD, takže v případě totálního kolapsu stroje se přehodí NFS server na stroj záložní a na virtuálech to nepoznáš, protože ty sevirtualizují jinde.

Kromě toho se komplet vše zálohuje přes rsync za běhu na diskové pole s btrfs. To pro případ, že se nějak podrbe instalace - revert takového stroje je pouze otázkou nabootování ze záložního adresáře. Kromě toho se po každém synchronizovaném virtuálu udělá jeho snapshot na úrovni souborového systému. Je to výrazně rychlejší - záloha deseti strojů, které celkem zabírají cca 320GB trvá zhruba necelou hodinu. Obnova stroje je záležitost na minutu. Stačí vypublikovat přes NFS adresář ze zálohy. Za běhu se pak rsyncem naplácne zpět aby se mohl zase přehodit tak, aby běžel z původního umístění.

[vboh]

Já potřebuju týdenní zálohy těch strojů s tím, aby se uchovalo posledních N týdnů. Plné zálohy (používám teď) zabírají ohromné množství na diskovém poli backup serveru => nemohu si jich dovolit uchovávat tolik. Jedná se mi čistě o zálohy, HA s DRBD řeší úplně něco jiného. Co se týče souborových systémů, tak mám zatím všude ext4, příp. ext3. Btrfs se celkem děsím, vzhledem k tomu, že je to ve vývoji. Výborné by bylo, kdyby to umělo deduplikaci. Pak bych nemusel vůbec řešit rozdílovou zálohu. Jen bych to tam nasypal celé a ono by si to nějak "samo" poradilo. Nicméně btrfs zatím deduplikaci neumí ne?

[vboh]

Narazil jsem na lessfs, který umí deduplikaci na úrovni bloků. Což by mi úplně vyřešilo celý problém s rozdílovým zálohováním (nevadí mi tahat po síti pokaždé velké množství dat, problém je jen s uložením). Nemáte s tímto fs někdo nějaké zkušenosti?

[Aleš Kapica]

Velké množství dat => velké množství času potřebného jak k vytvoření zálohy, tak k její obnově.

Udržovat zálohy souborů, které mají více než 5GB je neskutečný opruz.

S lessfs ovšem zkušenosti nemám. Volím raději spolehlivější řešení, postavené na relativně odzkoušených technologiích. Btrfs používám už nějaký čas a přijde mi spolehlivější než ext4, ovšem každý FS má svoje. Takže nad DRBD polem je právě ext4.

[Aleš Kapica]

Deduplikace má podle mě smysl pouze tam, kde používáš virtuály, které mají hodně shodných datových bloků - typicky widle, které si sebou tahají až 15GB balastu. Jenže to není náš případ. Stroje jsou různé a jen uživatelské adresáře (které se rovněž zálohují tímto způsobem) mají přes 60GB.

[Aleš Kapica]

Já dělám zálohy denní. S tím, že se dělají na úrovni souborového systému. Tzn, že jde defakto o rozdílové zálohy. Více se dozvíš u Herona.

DRBD nemá se zálohami nic společného. To že může posloužit jako záloha v případě výpadku, je jen třešnička na dortu. Primárně ho využívám při aktualizaci hostitelských strojů.

Ad ta deduplikace. Když uděláš rsyncem zálohu do subvolume, a pak uděláš pro to subvolume snapshot, tak btrfs do něj uloží pouze inkrementální rozdíly. Nicméně tobě se to jeví jako by ten snapshot byl normální adresář. O spolehlivost blokového zařízení pod Btrfs se mi stará SW RAID 6 pole složené ze čtyř 2TB disků.

[vboh]

Co se úspory dat, tak je to prakticky asi totožné s lvm snapshoty, ne? Tzn. každý snapshot nese rozdíl dat oproti originálu, tj. když budu mít 10 snímků a změním něco v originálu, tak se to promítne 10x do každého snapshotu (tzn. 10x tolik dat se využije k zápisu). Není to teda taková hrůza jako plné zálohy, ale ve výsledku je plná bloková deduplikace mnohem lepší než tohle.

[Aleš Kapica]

To tedy vůbec ne. LVM snapshoty se dělají na nižší úrovni, což znamená, že kromě čistých dat je v každém extentu i hromada nepodstatné "špíny", protože LVM nemá páru co to je za data.

Snapshotování u LVM není určeno přímo k zálohování. Předpokládá se, že se vytvořený snapshot namountuje, odzálohuje a zruší. Což znamená, že se do něj zapíší rozdíly, které se zatím zapisovaly do dočasného LV oddílu.

U Btrfs je to jinak. Všechno je objekt, a ty rozdíly se dělají vůči těmto objektům. Pokud se tedy objekty vůči snapshotu nezmění, tak se pro ně ani nedělají rozdílové soubory. A jelikož se vše odehrává na úrovni souborového systému, který ví které objekty se měnily a které ne, je celá operace mnohem rychlejší a efektivnější.

Ale já vás přesvědčovat nebudu. Prostě si to všechno vyzkoušejte.

[vboh]

Prošel jsem si https://btrfs.wiki.kernel.org vč. stránky o designu btrfs, ale nedozvěděl jsem se, jak je to se zabraným místem po snapshotu a změně originálů. Vím z toho jen to, že snapshoty jsou prý hodně efektivní a jsou prakticky totéž, co subvolumy (s tím, že subvolume má jen referenci na snapshot). Nicméně, jak moc efektivní ve skutečnosti jsou? Pokud mám nějaký subvolume a udělám 10 snapshotů. V originálním subvolume změním v jednom souboru blok dat o velikosti 1 MiB. Otázka je: když 10 snapshotů referencuje jeden zdroj, zabere se navíc 10x 1 MiB nebo jen 1?

[Aleš Kapica]

Tak na to ti neodpovím. Ale třeba si uděláš obrázek na základě konkrétních dat.

server (DATASERVER) :~# df -h
Souborový systém        Velikost Užito Volno Uži% Připojeno do
...
/dev/mapper/data-nfs        2,0T  821G  1,1T  44% /srv/backups
/dev/drbd1                  387G  282G   86G  77% /srv/virtualy
server (DATASERVER) :~# btrfs fi df /srv/backups/
Data: total=995.01GB, used=795.38GB
System, DUP: total=8.00MB, used=132.00KB
System: total=4.00MB, used=0.00
Metadata, DUP: total=39.50GB, used=12.68GB
Metadata: total=8.00MB, used=0.00
server (DATASERVER) :~# btrfs subvolume list /srv/backups | wc
    525    3675   32812

Zálohuje se od 30. srpna. Stroje, resp. adresáře, které jsou snapshotovány jako subvolume přibývaly postupně.

[Aleš Kapica]

Kromě toho je v rámci toho Btrfs uloženo ještě 300GB starých rozdílových záloh studentských účtů cca za 2 roky.

[vboh]

Díky. Také jsem to zkoušel na virtuálním stroji v debianu 7. Na subvolume jsem přes dd nahrál 2GB urandom dat, poté provedl 4x snapshot, data ze subvolume vymazal a poté nahrál na subvolume dalších 2GB náhodných dat. Poté jsem provedl na těchto datech 4x snapshot a data vymazal. Výsledkem bylo, že se zabralo jen 4GB dat, tj. snapshoty musí o sobě nějak vědět a není to tak, že by každý sám o sobě reflektoval změny originálu (takže to mají implementované vážně dobře, jinak by se zabralo 8x 2GB dat). Zkoušel jsem to na malém oddíle, abych si ověřil skutečnou velikost zabraných dat. Tady to vypadalo, že df udávalo skutečnou hodnotu. Nakolik se dá ale df u btrfs věřit (pokud nepoužívám btrfs raid)? Ještě to budu chvíli zkoušel a pak asi provedu konverzi ext4 na btrfs (přeci jenom btrfs mám v jádře a utility v balíkách debianu standardně, narozdíl od lessfs). Jak moc dobře tahle konverze na již tak experimentálním btrfs funguje?

[Aleš Kapica]

Příkaz df u btrfs vrací skutečně obsazený prostor. To co udává normální df není moc relevantní. U malého oddílu se to neprojeví až tak výrazně, jako u těch velkých - je to dáno tím, že velikost metadat se pro velký diskový prostor nijak dramaticky nezvětšuje.

Jestli mohu poradit, tak bych ext4, pro disk ze kterého virtuály jedou, ponechal, a raději to udělal tak jak to mám já - btrfs na oddíle pro zálohy. A nejlépe na nezávislém diskovém poli.

[Ivan]

Hmm a proc nepouzijes prikazy dump/restore? Inkrementalni binarni zalohy jsou normalni vec.