Vlákno názorů k článku Souborový systém Btrfs: práce se snapshoty od Peter Fodrek - tie snapshoty mi pripadajú skoro ako repozitár v...
-
Peter FodrekZlatý podporovateltie snapshoty mi pripadajú skoro ako repozitár v subversion. akturát tam vidím pár výhod, že subversion má len jeden subvolume..
-
Snapshoty mají hodně využití, ne jen na zálohu dat - to je dokonce spíš okrajová funkce.
Btrfs může být zajímavé pro databáze, někdy se může hodit mít zapnuté checksumy na filesystému a na databázi je vypnout. Počítány stejně jsou, ale na úrovni FS to přinese pár funkcí navíc.
Snapshoty mohou sloužit např. i na přenesení stejných dat do jiné instance, otestování. Nebo na operace, kde hrozí poškození dat aplikací. Při exportu iSCSI je to dobré na odlití stavu "tady a teď", např. pokud na něm běží VPS. Výhodou tedy je, že vrstva "nad daty" vůbec nemusí vědět o tom, že nějaké snapshoty existují, není potřeba přidávat aplikační logiku atd. atd.
Pro desktop je využití dost diskutabilní. Někdo to rád používá na pokusy, nebo při upgradech OS, aby existovala možnost vrátit se zpět. Osobně mám radši obyčejnou zálohu a načtení ze zálohy, než se crcmat se snapshoty. Z obyčejné zálohy daleko jednodušeji vytáhnu jednotlivý soubor, to je se snapshotem o kousíček složitější.
28. 1. 2020, 13:44 editováno autorem komentáře
-
Má to svoje výhody i nevýhody. Např. nechci mít v žádném okamžiku systémově přístupná data záloh. Když mám přístup do subvolume snapshotu, musím řešit, aby se do něj nedostal jiný proces, aby např. souběžně probíhající záloha (nebo jiný task) nezahrnul i snapshoty atd. To zvyšuje systémovou komplikovanost. Pro mě je čitelnější mít zálohy řešené jinak a vytahovat si z nich - je to možná méně pohodlné na tu samotnou operaci (kterou provádím opravdu zřídka kdy), ale jednodušší na hlídání těch ostatních aspektů.
Asi se shodneme na tom, že snapshoty jsou opravdu šikovná věc, můj pohled se možná jen trochu liší v té univerzálnosti použití.
-
okud zálohujete pomocí btrfs, tak riziko rekurzivní zálohy není (btrfs sub snap nepracuje rekurzivně). Dokonce můžete dělat snapshoty, aniž by byly odkudkoliv pod / dostupné :-)
To ale není doporučovaná praktika. Na zálohování platí zlaté pravidlo 3-2-1: tři typy záloh, dvě média, jedna záloha offline. Takže stejně souběh musíte předpokládat. Stejně jako musíte zabezpečit přístup ke snapshotům, když si je připojíte.
Není to neřešitelné, ale přináší to nové administrativní úkony a je nutné nad nimi přemýšlet, ne jen brát snapshoty jako jediné a univerzální řešení.
Samozřejmě je použitelný postup: udělat snapshot, odlít snapshot jinam, smazat snapshot. Ale to už zase ztrácí tu výhodu okamžitého přístupu k souborům. V tu chvíli už existují pohodlnější řešení.
-
Peter FodrekZlatý podporovatel
>To ale není doporučovaná praktika. Na
>zálohování platí zlaté pravidlo 3-2-1: tři
>typy záloh, dvě média, jedna zálohabez pravidelných backup recovery testov?
-
Asi si nerozumíme. Snapshot není záloha, je to prostředek jejího dosažení.
Podrobněji to popisuji na fóru, ale ve zkratce: co pár minut se udělá btrfs sub snap (tím se chráním před nechtěným smazáním nebo přepisem něčeho, "rollback"), co pár hodin se zstd komprimovaná šifrovaná delta (btrfs send ... | zstd | openssl enc ... > /mnt/storage/syncthing/bulk/...) odlifruje po síti do NASů, lokální snapshoty se promažou (uvolní se místo). Na straně NASu mám možnost příchozí deltu automaticky aplikovat na mirror subvolume a tím mít přístup k jednotlivým souborům (v časové posloupnosti), ale to nedělám - mám radši trustless storage, tj. NAS nemá klíče od šifrovaných blobů, nevidí do nich.
Před pár dny jsem spustil NASku u příbuzných a tak jsem konečně 321 compliant: >=3 kopie na >=2 zařízeních a >=1 kopie je off-site.
Zbývá mi dokončit automatizované testování záloh. Teď to dělám manuálně, jak si vzpomenu. Kříží se to s požadavkem na trustless storage :)
-
To je náhodou zajímavý problém. Jak otestovat integritu šifrované zálohy, aniž by byla data dešifrována...
Jak by to šlo udělat? Třeba šifrovat zvlášť (jiným klíčem) obsah a metadata, a k metadatům připojit hash obsahu? Nebo nějakým certifikátem? Mít současně dvě úrovně šifrování a porovnám jen hash, který si při šifrování spočítám? -
To je právě ten problém :-)
Existují různé kryptografické proof-of-storage systémy, např. co používá Storj, kterými si jedna strana ověří, že ta druhá skutečně drží daná data, aniž by ta druhá strana věděla, co v nich je (nebo mohla jejich vlastnictví předstírat).
Záloha ale není storage. Když testujete zálohu, nezajímá Vás jen že tam máte nějaká data, ale (hlavně) že tu zálohu jde určitým a pokud možno přímočarým způsobem použít, udělat z ní opět živá data. Je to tedy storage plus ty všechny procesy okolo. Podle mě to bez důvěry — tj. dešifrování, aplikací do nějakého VM, a pak funkčního porovnání s referencí či vzpomínkou (v případě selhání hardwaru :) — udělat nejde.
-
Filip JirsákStříbrný podporovatelVýhodou tedy je, že vrstva "nad daty" vůbec nemusí vědět o tom, že nějaké snapshoty existují, není potřeba přidávat aplikační logiku atd. atd.
Nevýhodou ovšem je, že ten snapshot nemusí být konzistentní – tj. když nad ním později tu aplikaci znovu spustíte, budou data rozbitá nebo budou úplně nepoužitelná. Konzistentní snapshot bez toho, aby s tím počítala aplikační logika, neuděláte. Ta aplikační logika klidně může mít velmi jednoduchý předpoklad („aby to přežilo výpadek napájení v libovolném okamžiku“), ale nějak to řešit musí. -
To děláte IMO zbytečně - vytvoření snapshotu je atomická operace (takže z pohledu procesu to vypadá stejně, ať ho zastavíte nebo ne) a jsou okolo ní bariéry, tj. ten sync tam efektivně proběhne taky (nestane se, že by snapshot předběh např. nějaký pending write). Explicitní sigstop by měl smysl leda kdyby se to týkalo více subvolumes naráz, tam potom je zastavení potřeba.
ČLÁNKY DO MAILU