Dotaz: Pravidelné snapshoty do provedení zálohy

[Martin]

Zdravím. Na serveru mám LVM a funkční snapshoty, který využívám zatím jen pro následné zálohování. Tzn. udělám snapshot a rcyncem to odvalím do zálohy. Následně snapshot zruším. Chtěl jsem to posunout ale dál a vykrýt místa mezi zálohama. Tzn. pokud si člověk něco smaže, abych mu to byl schopný vytáhnout v menším období, než je interval záloh (1 den). Napadá mě, že bych dělal např. každou hodinu nový snapshot. Vzniklo by mi jich dejme tomu 24, pak by proběhla ta denní záloha (rsync) a všechny snapshoty by se zrušily. No a pak by to začalo zase nanovo. Možnost obnovy historie by se mi tedy snížila na 1h. Je jasný, že pokud někdo něco vytvoří a smaže v rámci té hodiny, má smůlu, ale stav by se rozhodně oproti současnosti mnohonásobně zlepšil. Chtěl jsem se tedy zeptat, jestli na tohle generování a rušení snapshotů v konkrétním intervalu existuje nějaké hotové udělátko? Díky moc.

Odpovědi

[Jesus Jimenez]

Nechapu otazku...

cron?

[Aleš Kapica]

Hotové udělátko neexistuje. Udělat by se to dalo pomocí Btrfs - na LVM snapshoty v tomto zapomeň.

A udělal bych to tak, že bych - dejme tomu - co hodinu dělal snapshot, ten poslední bych rsyncoval pryč a po přenesení rsyncem bych snapshoty starší než 24 hodin rušil. Popř. bych si udělal skript pro rsync-backup, který by z těch snapshotů dělal rozdílové zálohy a rušil by je pak postupně po vytvoření zálohy.

[majales]

Taky bych se bál použít vícenásobné lvm snapshoty. Dost tím trpí I/O. Alespo%n když jsem to naposledy zkoušel.

[Martin]

No a v čem teda tkví potenciál LVM snapshotů? Jen na zálohování rychle měnících se dat (MySQL atd.)? :)

[majales]

Netvrdím, že to někde nějak nefunguje. Jen jsem při pokusech zjistil, že mi to dost omezuje I/O na tom lvm disku. Ale to může být také způsobené konfigurací mého HW. Asi bych hledal inspiraci v něčem takovém jako je https://github.com/mpalmer/lvmsync A nebo prohledej GitHub, určitě tam něco podobného tomu co chceš ty bude.

[Martin]

jj, díky za tip, mrknu na to

[lertimir]

LVM snapshoty jsou zcela rozdílné od btrfs snapshotů. btrfs snapshot funguje v podstatě tak, že bloky na disku jsou při vytvořeném snapshotu ponechány a změny se zapisují do nových bloků. LVM snapshot defakto definuje nový oddíl. Při změně se jednak zapíše nová data do filesystemu standardního oddílu. Ale zároveň se zapíšou rozdílová data (to co bylo změněno) do oddílu, kde sídlí snapshot. Pokud mám 10 snapshotů, tak jakákoliv změna ve FS se musí rozdílově zapsat do všech 10 oddílů snapshotů, a tím pádem se systém v podstatě zastaví.

LVM snapshot je vhodný na okamžitou zálohu dat. Provede se snapshot, okamžitě se zálohuje, a po záloze se snapshot ihned zruší, aby jeho existence systém nezpomalovala.

BTRFS snapshsot výkonnostně skoro nevadí, jen se snižuje množsví volných bloků, které při zápisech má FS k dispozici, ale vzhledem k tomu že je to copy-on-write filesystem tak by na nové místo psal stejně, jen by mohl trochu více optimalizovat zápis.

[Ivan]

Jen poznamka. Snapshot je vlastne inkrementalni diff. Smazat snapshot = aplikovat diff, neni to uplne levna operace. Myslim, ze jedina moznost je vyzkouset to v konkretnim prostredi.

[Aleš Kapica]

Jen poznamka. Snapshot je vlastne inkrementalni diff. Smazat snapshot = aplikovat diff, neni to uplne levna operace. Myslim, ze jedina moznost je vyzkouset to v konkretnim prostredi.

Mohu potvrdit - strávil jsem díky tomu o kompu minulou neděli odpoledne, večer i kus noci se sevřeným zadkem. A to jsem rušil "jenom" Btrfs snapshoty. Bylo jich cca 230 tisíc. Poprvé v životě jsem zažil, že namountování disku může trvat déle než dvě hodiny. A btrfs-cleaner čistil uvolněné místo ještě včera odpoledne.. U LVM si to nedokážu ani představit.

[hydrandt]

Uh, ja si s vmware esxi netroufam jit ani do desitek Nevim ale, zda-li je to implementaci snapshotu ve vmware, nebo pouzitymi raid radici.

[lertimir]

To se na tom disku, ale v podstatě nic nemohlo dít. Moje situace s btrfs snapshoty na root filesystemu u openSUSE asi z minulého roku byla taková že asi při 50 tém snapshotu se FS začal plnit "na doraz" volné byly jen jednotky procent a vůči s reálný potřebný objem byl cca 20-25%.

A o inkrementálním diffu. LVM snapshot v provozu je inkrementální diff. jeho smazání je naopak zrušení diff operace.

Btrfs má zajímavé vlastnosti a co se přesně děje na disku při smazání snapshotu jsem se zatím propátrat nesnažil. Nicméně moje pozorování je, že mazání velkých souborů trvá dlouho. Mám dva velké disky naformátované LUKS/btrfs a pokud přesouvám větši soubor (cca 1G) mezi disky, tak jednak přenos běží pomaleji než bych čekal cca 30-50 MB/s (na ext4 bez šifrování cca 100-140 MB/s) a také na konci přenosu (podle KDE teploměru) trvá ještě několik sekund až desítek, než soubor v podstatě v původním úložišti skončí. A to je mazání jediného souboru.

[Heron]

Tohle u LVM neplatí (neplatilo v 2009, lvm již nepoužívám).

LVM nechá původní svazek tak jak je (normálně připojený, pro zápis, s tím LV se nic neděje), a snapshoty realizuje ukládáním změn.

Pokud dojde místo nebo je snapshot smazán příkazem, tak tato změnová data prostě zahodí a snapshot zmizí. Toto je velmi rychlé, nic se nemerguje.

LVM snapshoty fungují (fungovaly v roce 2009) přesně opačně, než u jiných systémů (obvykle se původní svazek nechá zmražený v čase pořízení snímku a někam se ukládají změnová data od tohoto okamžiku. Tady ne, tady je původní svazek normálně dostupný a zapisuje se na něj, kdežto pro snapshot se ukládají původní data v době pořízení snímku.)

Oba způsoby mají své výhody i nevýhody. LVM snapshoty jsou dobré pro případ pořízení snapu, jeho rychlé zálohy, rychlého smazání. Tohle třeba je problém ve vmware, kde zapracování snapshotu trvá a jakýkoliv provoz toho virtuálního disku ten proces jen zpomaluje.

COW FS tímto netrpí (ani jedním z uvedených problémů), COW stejně dělá kopii bloku při každém zápisu, tam je snapshot velmi levná záležitost, nic se nemerguje. Při odstranění snapshotu se jen značí bloky jako volné (resp. se jim sníží link count), úplně stejně, jako v případě rm.

Pokud má někdo 230 tisíc. snapshotů, tak si hold počká, ale v případě skutečné kopie a skutečného mazání na jiných fs, by si počkal také a mnohem déle.

[Andrej]

LVM a snapshoty je řešení ve stylu vzít si nůžky a zatloukat tím hřebíky. Z LVM snapshotu se nedá korektně zálohovat, protože obsahuje nekonzistentní filesystém, pokud si člověk nemůže dovolit ošklivost typu unmount—snapshot—mount. Na opravdové snapshoty existují hotová udělátka zvaná ZFS a Btrfs. Automatické vytváření snapshotů a „ředění“ starších snapshotů už zajistí nějaký oneliner v cronu. Některé distribuce měly pro takové účely dokonce i GUI nástroj, ale má-li to být automatizované bez podpory ze strany uživatele, cron prostě musí stačit.

[majales]

LVM snapshot je snapshot blokového zařízení, který neví nic o stavu filesystému který na něm běží. Kdežto snapshoty ZFS a BTRFS jsou snapshoty na úrovni filesystému které jsou vždy konzistentní. Je to tak? Kdyžtak mě někdo opravte.

[Josef Kufner]

Ano. A právě proto už z principu nemůže být LVM snapshot pořízený za běhu konzistentní. Pokud však uděláš snapshot v době, kdy je filesystém odpojený, nebo read-only, tak je vše v pořádku.

[lertimir]

Určitě je ZFS a BTRFS snapshot konzistentní? Podle mne snapshot z principu je záznam stavu filesystému v jeden konkrétní okamžik a ten je na otevřeném filesystému nekonzistentní vždy. A jestliže v tomto okamžiku mám otevřené soubory a případně do nich zapisuji, tak bych měl mít na jakémkoliv systému rozlišeno to, co jsem zapsal těsně před snapshotem (bude v snapshotu) a těsně po něm (v snapshotu nebude). Stejně tak v snapshotu by asi mělo být zaznamenáno, co otevřeno v daný okamžik je a co není.

Tím ale neobhajuji LVM snapshot. Ten je pouze zoufalá snaha dostat záznam okamžitého stavu do filesystému, kde něco takového není od začátku. A s mnoha závažnými důsledky pro výkon.

[Heron]

Určitě je ZFS a BTRFS snapshot konzistentní?

Je konzistentní z hlediska fs. To, že se snapshot pořídí někde uprostřed operace nějakého programu fs neřeší, protože o tom programu nic neví.

Lze to ale udělat opačně, tedy stavem toho programu řídit snapshoty.

Vzhledem k tomu, že můžete mít subvolumů kolik chcete, můžete data toho programu umístit na vlastní subvolume a snapshotování si budete řídit s ohledem na ten program. (Programu se pošle příkaz "teď si všechno ulož a nic nedělej" a udělá se snapshot a program se volně nechá pokračovat. -- např. pg_start_backup, snapshot, pg_stop_backup)

Pochopitelně totéž lze udělat i s LVM, ale tam je zase problém s distribucí volného místa (mít stovky LV a na nich nějak velký fs s nějakým volným místem) není tak jednoduché*.

*) Zkoušel někdo LVM a thin provisioning? Potom by ten fs nad tím mohl označovat volné bloky (discard) a do LVM poolu by se vracely bloky. Tím by šlo redistribuovat volné místo i na LVM.

[lertimir]

Pochopitelně totéž lze udělat i s LVM, ale tam je zase problém s distribucí volného místa (mít stovky LV a na nich nějak velký fs s nějakým volným místem) není tak jednoduché*.

No právě. Myslím, že z hlediska konzistence není mezi přístupem LVM a BTRFS/ZFS principielně rozdíl. Nebo podobně silná konzistence lze dosáhnout i na LVM i když pracněji. To co dělá diametrální rozdíl je samozřejmě, to jak se snapshot vytváří. V ZFS a BTRFS se jenom bloky ve snapshotu neuvolní, v LVM se pořád zapisují rozdíly. A tam se použití přiblížit nedá.

[Josef Kufner]

V principu rozdíl sice není, prakticky však máš nad LVM dvě nekonzistentní vrstvy – filesystém a aplikace, kdežto u BTRFS jen jednu – aplikace. Pokud LVM a filesystém spolupracují, jak píše Heron níže, pak to už vyjde nastejno.

Způsob implementace snapshotu už je věc druhá.

[Heron]

Není to tak úplně přesné. FS mají prostředky (xfs na to má i program xfs_freeze*) pro pozastavení činnosti a uvedení fs do konzistentního stavu. LVM se před pořízením snapshotu snaží fs informovat a tento fs, pokud tuto funkci podporuje, se uvede do stavu vhodného pro pořízení snapshotu. Pokud to fs nepodporuje, tak se prostě udělá snapshot mezi dvěma fsync nebo flush.

*) xfs_freeze halts new access to the filesystem and creates a stable image on disk. xfs_freeze is intended to be used with volume managers and hardware RAID devices that support the creation of snapshots.

[majales]

Nevíte někdo zda a jak funguje fsfreeze pro kvm? Měla by existovat volání guest-file-flush a guest-fsfreeze-freeze pro zmražení filesystému guesta, které se zavolá přes QEMU guest agenta. Něco jsem našel tady, ale nejsem z toho moc moudrý.