Vlákno názorů k článku Souborový systém Btrfs: kontrola dat a pokročilé použití od Swiso - Předně bych chtěl vyjádřit autorovi své díky za...

Předně bych chtěl vyjádřit autorovi své díky za brilantní seriál o Btrfs systému. Jelikož ho začínám čerstvě používat spolu s RAID 1 polem, jsem rád, že se dozvídám mnoho důležitých informací jak z článku, tak i od diskutujících.

Nyní k mému dotazu: I zde v článku je zmíněno zálohování. Musím říct, že tenhle způsob záloh mi nedá spát a stále si nejsem jist, že to, jak to celé funguje, chápu správně. Pro mě osobně je záloha, kterou lze označit za zálohu 1:1 kopie dat. Čím více důležitých dat, tím více kopií na více úložištích a také fyzických místech. Tedy příkladně, pokud mám 2TB důležitých dat, lze jako jediné považovat za zálohu, pokud mám tyto data 1:1 na jiném 2TB disku (3 zálohy = 3x 2TB HDD). Jestli to chápu správně, snapshoty fungují tak, že dělají rozdílové "zálohy", tady musím mít něco jako zdroj a ze zdroje odečítám (zapisuji) k prvnímu snapshotu pouze rozdíl. Následný další rozdíl také, ale jenom s tím rozdílem, že již nějaká data odečítám z prvního snapshotu. Důležité ovšem je to, že musím mít někde ty 2TB dat (zdroj, který je porovnáván). Jestliže se zdroj poškodí, můžu si 10 snapshotů strčit někam. Chápu to správně? Jestliže ano, nejedná se totiž o zálohu a je velmi nesprávné a také zavádějící, to takto označovat. Je to jako tvrdit, že RAID 1 je záloha dat. Ano, data máte na dvou discích, ale bohužel, dojde např. k napadnutí stroje ransomware a data se zašifrují i na disku druhém. => proto se nejedná o zálohu. Píšu to, protože mnoho lidí to, bohužel, nechápe. Je mi jasné, že diskutující zde, ví.

Díky za pochvalu.
Ano je bude stal stejný problem jako pri priruskovych zalohach - pokid stratis full zálohu tak prustky ti jsou k nicemu.

Zaloha to je - mas to kopii od produkcnich dat a i na jinem mediu.

Ne úplně. Pokud provedeš na zálohovacím stroji Btrfs restore, tak tam budeš mít dva snapshoty, oba s full zálohama. Pokud starší snapshot smažeš, tak furt pomocí toho nového snapshotu data obnovíš. V tom je ta "genialita" snapshotů a obrovský rozdíl oproti klasickému přírůstkovému zálohování.

Ano ale samozřejmě taky s dvojnásobným datovým objemem :(
Zatímco snapshoty jsou něco jako git revize, kdy je celý systém v daném bodě dostupný, ale vnitřně to zabírá jen tu inkrementální část. Podobně jako u věcí typu syncthing.

Nikoli: pokud to send-restore uděláš jako inkrementální, tak na cílovém stroji Ti také vzniknou dva snapshoty sdílející data. Btrfs send-restore právě funguje přesně jako git: snapshoty šetří místo jak na místním, tak na "vzdáleném repozitáři".

Předně bych se nedržel premisy, že záloha == 1:1 kopie dat. Pokud tím máte na mysli to, že bude 1:1 bitová kopie, pak to zase s sebou nese riziko vznikající z chyb filesystému a jeho interpretace (v roce 2020 může mít btrfs nějakou chybu, kterou zároveň v této době umí "správně" interpretovat, ale v roce 2025 při připojení zálohy můžete narazit na projev problému). Záloha bitové kopie je jedna ze specifických typů záloh, ale určitě se nedá říct, že je to nejvhodnější vždy a všude (já bych skoro řekl, že se tato výhoda hodí málokdy).

Zálohovací systémy často umějí přírůstky intepretovat do hlavní knihovny záloh takovým způsobem, že po uložení dat už neexistuje závislost na full záloze a na předcházejících přírustcích (ale přesto umí podle katalogu najít stav ke každému inkrementu). To, jestli vím, tak ani zálohy snapshotů btrfs, ani zfs neumí (a třeba pro mě je to velké mínus).

Formou snapshotů je vhodné zálohovat často měnící se data, aby byl zachycen stejný okamžik na celém subvolume. V praxi je asi nejčastější případ formou snapshotů zálohovat (jenom) transakční logy databázových systémů, případně, pokud to situace dovoluje, tak i hlavní databázi.

Překvapilo mě doporučení na vypínání CoW pro databázová úložiště. Zrovna tam je to potřeba - stejně databáze zapisují stránky na konec transakčního logu, takže k častým přepisům dat nedochází. Ve chvíli, kdy dochází k promítnutí změněných stránek do hlavního úložiště, je CoW zapotřebí jako soli. CoW by mělo mít poměrně mrňavou režii (filesystem stejně zapisuje svoje stránky). Doporučil bych spíš vyladit interval zápisu logů do databáze, případně (po pečlivé úvaze) oslabit fsync, než vypínat CoW - to jde zcela proti smyslu architektury!

Ano, máte pravdu, použil jsem nešťastný termín. Měl jsem na mysli 1:1 ve smyslu stejná data na jiném médiu ("prachsprostě" překopírovaná a poté ověřená a zkontrolovaná). Jinak časový snímek dat je parádní věc a i vím, kde bych to používal já, ale nelíbí se mi to označení záloha, protože to mate uživatele a já jim pak dost blbě vysvětluji, že to vlastně záloha ve smyslu záloha, není. Obdoba RAID 1, jak jsem psal. O bitové záloze máte pravdu, kvůli tomu ji také nedoporučuji používat. Na vlastní kůži jsem už poznal její záludnost.

Ve chvíli, kdy dochází k promítnutí změněných stránek do hlavního úložiště, je CoW zapotřebí jako soli.

Záleží na konkrétní db, ale ty postavené na MVCC architektuře si něco jako COW dělají sami. Nikdy se nepřepisuje existující záznam, ale vždy se vytváří nový. Až zpětně jsou označeny volné záznamy nebo celé stránky.

Takže dělat MVCC nad COW znamená ty bloky na disku měnit 2x. DB zapíše změněnou stránku, FS to vidí jako změnu bloku, tak udělá ještě COW toho bloku. Potom nad DB proběhne vacuum, DB označí tu původní stránku jako volnou a FS to opět vidí jako změnu a provede COW.

Nepřináší to žádnou výhodu, takto postavená DB se sama vyrovná s výpadkem napájení apod. Živé stránky se nikdy nepřepisují a ty mrtvé jsou označeny za volné až někdy zpětně (ano, samozřejmě, existují optimalizace jako hot update apod, ale to není teď potřeba komplikovat). Tj datové soubory jsou vždy v pořádku a snadno rekonstruovatelné pomocí logů. Dělat nad tímto ještě další COW nic nepřinese a sníží výkon zápisu efektivně na polovinu (v praxi ještě více).

Ja by som teda najprv urobil poriadok v pojmoch. Zaloha nie je archiv a archiv nie je zaloha. Mali by ste mat nejaku policy pre archivaciu udajov. Napriklad jeden archiv pre kazdy rok a za poslednych 6 mesiacov kazdy mesiac a posledne 4 stvrtroky. Vzdy full archiv na 2 roznych lokaciach a 2 technologicky roznych mediach (SSD, tocity disk, cloud, paska, ...).
Zalohy sa potom mozu odrazit z tychto archivov, takze si zalohujete iba rozdiely oproti full archivom.
No a na zaver technicka poznamka, musite vediet co robite. Ked si pod beziacim Oraclom urobite snapshot a zazalohujete neznamena to ze viete neskor obnovit instanciu Oraclu.