Názory k článku Souborový systém Btrfs: práce se snapshoty
-
Zaujimalo by ma to ako je to s rychlostou btrfs, ci je to citelne pomalsie ako napr ext4 pri desktope.
V tomto teste vyzera BTRFS dost pomale :(
https://www.phoronix.com/scan.php?page=article&item=linux55-ssd-raid&num=1 -
Michal SmržStříbrný podporovatelTak, vždy může být rychleji, o tom žádná. Ale BTRFS nakonec čék používá z jiných důvodů než rychlost.
-
Filesystem by si mal vyberat podla vhodnosti nasadenia - pokial ocakavas vysoky IO load, zrejme by si mal zvolit FS, ktory je na to usposobeny. Btrfs pouzivam na ako root filesystem na pomerne obstaroznom notebooku (i5 Sandy Bridge) - pri rotacnom disku som si nevsimol, ze by migraciou z ext4 na btrfs nejako vyrazne spomalil. Po vymene za ssd som uz porovnavanie nerobil - nebol dovod.
Inymi slovami, pokial nemas nejake specialne poziadavky, problemov s vykonom by som sa nejako velmi neobaval. -
Na desktopu (laptopu) nepoznám subjektivně rozdíl mezi ext4 (typicky čistá instalace nového stroje) a btrfs. Je to průřez celým spektrem od velmi výkonných (threadripper s NVMe SSD a obscénním množstvím RAM) po velmi úsporné (ARM laptop s 4GB RAM a malým eMMC). Nečetl jsem, jakou metodologii použil Michael v tom benchmarku, že mu xterm startoval 34 sekund na EPYCu, ale takovou dobu xterm nestartuje ani na PineBooku, za tu to dvakrát nabootuje :-)
Mám obvykle nějaké IO na pozadí (automatický snapshot co pár minut s off-site přenosem přes Syncthing), a přesto na nic nečekám.
-
Funguje to tak. Takhle dělám systémy i já - jeden oddíl na disku (btrfs umí i bez partitions přímo na disk, ale zatím to tak používám jen na emmc), v něm je adresář /subvol a v něm jednotlivé subvolumes. Ty potom připojím:
# /etc/fstab
(...)
/dev/mapper/pool / btrfs ...,compress=zstd,subvol=/subvol/rootfs
/dev/mapper/pool /var btrfs ...,compress=zstd,subvol=/subvol/var
/dev/mapper/pool /home btrfs ...,compress=zstd,subvol=/subvol/home
a dál se to chová jako tradiční instalace s tím rozdílem, že se sdílí volné místo, takže se už nestávají maléry kdy mi např. padne kompilace LibreOffice, protože došlo 20 GB v rootu nebo dojde místo v /home, přestože na rootu jsou desítky GB volna.Když chci změnit systém a zachovat home, je několik způsobů, jak toho docílit. Můžu zálohovat konkrétní subvolume (příkazem btrfs send), ale elegantnější je jednoduše vytvořit další /subvol/rootfs-blabla a na ten se pak odkazovat v /etc/fstab a /proc/cmdline :-) dokonce jde mít konfiguraci statickou a subvolume zvolit symlinkem.
Vedle /subvol mám ještě adresář /snapshots, do kterého se dělají automaticky snapshoty popisované v článku, a automaticky jsou pomocí btrfs send streamovány do NASu.
28. 1. 2020, 13:36 editováno autorem komentáře
-
Peter FodrekZlatý podporovatel
tie 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.
-
Predne, diky za clanek a cely serial. Je to prinosne a dobre cteni. Okolo btrfs je hodne zastaralych informaci, tak jsem rad, ze to nekdo shrne k aktualnimu stavu.
Je to nekolik mesicu, co jsem zacal zalohovat pomoci rsnapshot+btrfs subvolume.
Kdo zna rsnapshot, tak jde o to, ze misto vychoziho vytvareni hardlinku – jako r-snapshotu – se vytvori btrfs snapshot a misto mazani adresare se maze cely btrfs snapshot. Zjednodusene jde o tento princip- Vytvor novy btrfs snapshot
rsync-em nahraj novou verzi zalohy- Smaz nejstarsi snapshot
Jsem pozitivne prekvapeny vykonem. Zalohy probihaji velmi rychle a tez se hodne setri misto.
Co se tyce problemu s btrfs, tak jedine, na co jsem narazil bylo pri zapnutych quotach na kernelu 4.19 (cas od casu to pri prejmenovani snapshotu zamrzlo). Bez kvot zadny problem a nyni na kernelu 5.4 to slape v pohode i s kvotama.
Co bych ted rad vyresil je kopie techto snapshotu na sekundarni uloziste (off-site). Bude v nejakem z nasledujicich dilu probrany
btrfs send/btrfs receive? Je mozne temito prikazy synchronizovat dva btrfs vcetne zachovani snapshotu? Neco ve smyslu posli snapshot 3 subvolume 1 a na druhe strane opet vytvorim snapshot 3 subvolume 1 pouze s rozdily, se zachovanim spolecnych bloku.Jeste jsem to detailne nestudoval, tak by me zajimalo, na co se mam pripravit. Ci jestli se nekdo potykal s necim podobnym. Budu rad i za relevantni linky.
5. 2. 2020, 22:19 editováno autorem komentáře
