Dotaz: Jak udělat kopii btrfs filesystému

[xxl]

Jak udělat kopii btrfs souborového systému na jiný disk tak, aby byly zachovány všechny subvolumy, snapshoty, atd., atp. ...

Prostě aby vznikla kopie, která se dá například připojit bezproblémově zpátky do původního PC tak, že někde ve fstabu upravím UUID příslušné partišny a všechno ostatní bude fungovat beze změny.

Původní systém třeba tři disky, data, system i metadata raid1, tzn. že na žádném disku nejsou všechna potřebná data. Nový systém jeden disk, data single, system a metadata dup.

btrfs send/receive by patrně fungovalo. Ale je potřeba vědět, jak jde za sebou posloupnost snapshotů, což není tak docela jednoduché a zatím mi zůstává utajeno, jak na to dodatečně přijít.

Nějaký nápad?

---

---

Odpovědi

[Aleš Kapica]

no když se udělá dd, tak tam bude všechno stejné, včetně UUID

jenom je potřeba to asi dělat ne na rw namountovaném btrfs

[xxl]

Sorry jako, to je blbost. btrfs raid1 na třech discích znamená, že na každém disku jsou 2/3 dat.

[Andrej]

Jak se dá udělat dd ze tří disků na jeden?

[Aleš Kapica]

Je to jen o místě. Rozhodně to není vhodný způsob na průběžné zálohy, ale na přesypání Btrfs jak leží a běží. Alespoň tak jsem pochopil ten dotaz.

1. Nejprve bych poslal do cílového místa přes dd obsah všech disků, co do toho FS patří. Ideálně na nějaký jiný diskový prostor, než kde pak bude to Btrfs.
2. Po nakopírování bych navěsil ty images na loop zařízení a ten FS namountoval. Mount by to měl podle mne normálně sežrat, protože se UUID přešoupnutých obrazů disků nezmění.
3. Potom záleží jestli to chce ponechat jako raid, nebo jestli to má být single – v takovém případě je nutné aplikovat btrfs balance.
4. No a pak bych nahradil postupně ty loop zařízení za cílové blokové zařízení. U Btrfs v raid 1 stěhovaném na jedno fyzické blokové zařízení bych nejprve přidal to fyzické zařízení, vybalancoval FS a teprve poté vyřadil loop na kterém by zůstal navěšený zbylý obraz disku.

A nemusí to být nutně soubory. To dd se dá sypat na logické disky vytvořené přes LVM. Důležité je vědět co se má kopírovat.

[xxl]

S dostatkem místa, kam by se daly provést dd kopie všech disků btrfs souborového systému není samozřejmě žádný problém, jak udělat jeho úplnou kopii.

Taky bych mohl do btrfs připojit správně veliký disk, překonfigurovat a rebalancnout to celé tak, aby na přinesený disk přišla všechna data. Pak to podle potřeby celé rozhodit a přinesený disk připojit v degradovaném módu, zase to přenastavit, znovu rebalancnout a je to.

Nicméně dotaz směřoval k tomu, jak relativně jednoduše překopírovat obsah jednoho btrfs souborového systému (s daty) na druhý btrfs souborový systém (čistý), při zachování všech informací o subvolumech a snapshotech.

[Josef Kufner]

Jo, toto bude fungovat, ale bude to trvat hodně dlouho a bude potřeba hodně místa. Pokud je potřeba jen přejít na nový disk, tak ho stačí přidat a staré odstranit. Pokud ale má zůstat na starých discích nepoškozená archivní kopie, tak to moc praktické není.

Řešil jsem přechod na nový zálohovací disk. Starý už dělal trochu blbosti, tak jsem na novém vyrobil nový file systém a ty stovky snapshotů kopíroval jeden po druhém ručně – tedy cyklem, takže to bylo v pohodě, ale stejně to nebylo univerzální řešení.

Musel dávat pozor na správné pořadí vytváření snapshotů, aby mi zbylo na disku nějaké místo, ale jinak by mělo být jedno, v jakém pořadí se snapshoty vytvoří – data tam budou tak jako tak, jen možná bude potřeba deduplikace.

[Want]

Nicméně dotaz směřoval k tomu, jak relativně jednoduše překopírovat obsah jednoho btrfs souborového systému (s daty) na druhý ...

Přečti si ten dotaz ještě jednou. O jednoduchosti tam nic nepsal. To bych mu totiž doporučil úplně jiný postup.

[Petr Tomášek]

!!!!

https://btrfs.wiki.kernel.org/index.php/Gotchas

Do NOT

make a block-level copy of a Btrfs filesystem to another block device... use LVM snapshots, or any other kind of block level snapshots... turn a copy of a filesystem that is stored in a file into a block device with the loopback driver... ... and then try to mount either the original or the snapshot while both are visible to the same kernel.

[Aleš Kapica]

... and then try to mount either the original or the snapshot while both are visible to the same kernel.

Tak předpokládám, že je snad bylo dostatečně jasné, že se to zkopírované Btrfs nemountuje na stejné mašině.

[Josef Kufner]

To nestačí.

Když se udělá kopie blokového zařízení, tak není jisté které zařízení si btrfs vybere. Takže sice mountneš /dev/kopie někam jinam, ale ta kopie odkazuje na UUID druhého zařízení pro RAID1 a ty nevíš, zda si btrfs vybere jako druhý disk kopii nebo originál. A co hůř, pokaždé si může vybrat něco jiného a být značně zmatené.

[Aleš Kapica]

?

Promiň, ale tenhle text nemá ani hlavu ani patu. Btrfs si nic nevybírá. Prioritu určuje devid. A ten se při zkopírování nezmění. Navíc Btrfs v raid1 znamená, že jsou zrcadlené extenty, takže je úplně jedno který by se vzal jako prioritní, protože musí být oba stejné. To není MD raid.

Problém by mohl nastat podle mne jen v tom případě, že by s tím Btrfs laboroval přes loop zařízení na stejném stroji, kde je ten zkopírovaný FS.

Jinak jak už jsem uvedl. Osobně bych volil jiný postup. Živý subvolume ORIG na stroji A bych snapshotoval do ORIG-snapshot. A obsah ORIG-snapshot bych pak nechal rsyncem přesypat po síti na stroj B do subvolume COPY, které bych po skončení přenosu následně snapshotoval na COPY-YYYY-MM-DD.

ORIG-snapshot bych nechal do vytvoření nového snapshotu jako zálohu. V případě nabourání původního živého subvolume je pak rychlejší obnova než tahání dat ze zálohy. A když by to exlo celé, tak se může buď použít stroj B, nebo jeho úložiště.

[a1bert]

jenze nesmis namountovat ANI to ORIGINALNI, po vytvoreni kopie az do ODSTRANENI blokoveho zarizeni nesmis namountovat nic (a to nemluvim o automagickych vyfikundacich typu automount, ktere to muzou udelat za tebe ani nemrknes)

takze s timhle velmi opatrne

[Aleš Kapica]

Kdo se bojí, nesmí do lesa. A kdo neví co dělá, ať si najme toho kdo to ví a slušně ho za tu práci zaplatí.

[Vantomas]

Pořadí snapshotů je zřejmé z btrfs subvolume list -a /mnt/btrfs. ID se postupně inkrementují a tak ty s nižším ID jsou starší.

[xxl]

No jo, ale ty snapshoty mohou být nazvané úplně libovolně a ani se nemusejí nacházet v nějakém logickém umístění. A přesto k sobě mohou patřit a já to nemusím poznat. Když budu mít tři snapshoty, tak si patrně poradím. Ale když těch subvolumů/snapshotů budou desítky, tak se tutově seknu.

Příklad. Udělám kontainer debian. Pak udělám klon debian --> test-upgrade. Pak debian --> debian-upgrade-test. Pak klon test-upgrade --> test-bullseye. Pak smažu debian. Tak si mohu ještě chvíli vymýšlet a za chvíli se v tom vůbec nevyznám a mám jen ten výpis btrfs subvolume list. Když to budu nějak kopírovat, budu dost nervózní.

[Vantomas]

No, pravda, napsal jsem to špatně. btrfs sub list má ještě další parametry, viz --help. Zajímavé třeba jsou -u pro uuid subvolume, -q pro parent uuid z kterého snapshot pochází. Je tedy možné přenést všechny subvolume co nemají žádné parent uuid a k nim pak přenášet ty ve stromě níž.

Možná na to bude existovat nějaké hotové řešení, ale neznám ho, nikdy jsem tenhle usecase nepotřeboval a menší disk za větší vyměňuji přes btrfs device add/remove.

[xxl]

Jasně. Díky. Z toho se to vyčíst dá. Je to tedy pěkný maglajs, ale asi by to šlo pochopit. Taky jsem si to mohl přečíst.

Ale patrně žádné čárymáry fuk btrfs clone odsud sem nefunguje, že? Google mi moc neporadil, našel jsem sice nějaký projekt, který to patrně dělal, ale byl asi 4 roky neudržovaný.

[vee]

Nehledáš něco takového? https://github.com/speed47/btrfs-list

[Andrej]

Existuje tohle, ale vypadá to, že se současnými btrfs-progs už to nefunguje, přinejmenším ne bez tohoto pull requestu. (Který je hodně dlouho nevyřízený, projekt vypadá opuštěný atd.)

(Osobně bych to použil spíš jako zdroj informací, jak získat správné pořadí snapshotů, než cokoliv jiného…)

Jinak mám dojem, že ID snapshotů i jejich generace jsou (pro snapshoty od téhož subvolume) rostoucí:

ID 7670 gen 2464653 top level 5692 path arch_backup/-home-andrej.homedir/2022-03-13 03:29:12 1647138552424922035
ID 7922 gen 2465820 top level 5692 path arch_backup/-home-andrej.homedir/2022-06-01 04:30:18 1654050618104307446
ID 8042 gen 2467422 top level 5692 path arch_backup/-home-andrej.homedir/2022-07-10 04:31:05 1657420265191933125
ID 8168 gen 2470613 top level 5692 path arch_backup/-home-andrej.homedir/2022-08-22 03:21:39 1661131299222195966
ID 8232 gen 2471859 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-10 03:01:23 1662771683812132780
ID 8260 gen 2471987 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-19 03:46:38 1663551998097155372
ID 8278 gen 2472074 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-25 03:07:56 1664068076400995511
ID 8284 gen 2472133 top level 5692 path arch_backup/-home-andrej.homedir/2022-09-28 03:45:20 1664329520797886672
ID 8298 gen 2472136 top level 5692 path arch_backup/-home-andrej.homedir/2022-10-01 03:36:28 1664588188068882102

Tam↑↑↑ bude ovšem nutné se přesvědčit, které z těch čísel je rostoucí jenom náhodou a u kterého to opravdu garantuje dokumentace.

[xxl]

btrfs-clone bylo to, co jsem našel. Ale datumy posledních commitů, pull-requestů a issues mě odradily od testování.

[xxl]

Za určitých podmínek by se snad dal původní systém nastavit pomocí btrfstune jako seeding device, poté připojit další disk a následně odstranit původní disk(y). Tím by se zřejmě dalo dosáhnout toho, že původní systém by nebyl změněn, ale na tom novém disku by se ocitla kopie původních dat, kterou by tam umístil přímo btrfs filesystém.

Ale je to jenom za určitých podmínek, původní systém by měl být v single módu.

[xxl]

Pomocí btrfs seeding device to funguje docela dobře.

Stávající filesystém se jako odpojený označí jako seeding device. To znamená, že od té chvíle se na něj nedá zapisovat. Ale dají se k němu přidat další disky, na které se poté provádějí zápisy.

Podle toho, jakého typu je původní filesystém, je třeba zvolit počet nových disků. Například pro raid1 jsou potřeba dva. Nicméně v našem specifickém případě, když jde o to vytvořit jakýsi klon filesystému, není tak úplně nutné, aby ty nové disky byly tak veliké, aby se na ně vešel celý filesystém. Stačí, když je tak veliký jeden z nich. Ten druhý může být klidně například loop device na ramdisku o velikosti, aby se tam vešla btrfs systémová data plus metadata původního filesystému. To je nutné zjistit předem.

Pak se připojí původní filesystém. (Připojí se automaticky jako read-only a nejde to remountem změnit.) Pak se k filesystému přidají nové disky. Filesystém se remountne jako read-write. (Od této chvíle se na něj dá zapisovat, ale původní disky zůstávají nezměněny a všechny změny se zapisují na nové disky.)

A teď.... Je nutné provést rebalanc filesystému. Takže napřed metadata na dup a potom data na single.

A pak... Odebrat všechny původní disky plus to loop device. Btrfs zachroupá a samo si přetáhne obsah celého filesystému na ten jeden zbylý (nový) disk.

To je celé.

Na novém disku je celý obsah původního filesystému. Na původních discích je také obsah původního filesystému. Zatím se tam ještě nedá zapisovat, je třeba zase odebrat příznak seeding device. Pak se dá zapisovat i tam. Dokonce se dají oba filesystémy, původní i nový, připojit najednou ke stejnému počítači.

Testoval jsem na virtuálu a úplně v pohodě. V reálu ještě ne, ale zdá se, že by s tím neměl být problém.

[Josef Kufner]

To zní jako dobrý koncept pro migraci na nové disky s archivací starých. Trochu bych se bál v okamžiku, kdy disky budou už zlobit a nikoliv že jsou např. jen malé.

[xxl]

Na ty původní disky se vůbec nezapisuje. Z nich se jenom čte. Ten rebalanc je jenom informace pro nové disky, jak mají nadále provádět zápisy. Po ukončení celé operace jsou původní disky pořád ve stejném stavu, jako byly na začátku.

[Josef Kufner]

Nejde o zápis, jde o stav nového file systému kvůli chybám ve starém, neboť je to stále stejný file systém. Když se kopíruje o úroveň výš, tj. na úrovni souborů, tak to nehrozí (možná se jen nějaký soubor nepřečte).

[Aleš Kapica]

Pokud je dostatek prostoru mohl by to řešit btrfs-image.

[Petr Tomášek]

"btrfs-image is used to create an image of a btrfs filesystem. All data will be zeroed, but metadata and the like is preserved. Mainly used for debugging purposes."

To zvýrazněné mi připadá nějaké podezřelé.

[lertimir]

Souhlas, že je to podezřelé. chvili jsem přemýšlel jestli to uvést, ale mohlo by to být i tak, že btrfs-image vytvoří strukturu (subvolume, snapshots atd) a pak by třeba rsync nasypal obsah - data. Chce to asi na malém subvolumovaném snapshotovaném systému zkusit.

[Want]

Až budeš o tom přemýšlet jak to uděláš, všimni si, kdo označil kterou odpověď jako řešení a dej si tu práci se podívat jakou má s Btrfs a linuxem obecně zkušenost. Jinak to máš jednoduché. Buď to zkusíš, nebo budeš věřit Tomáškovi a bude to stejné, jako by ses neptal.

[LarryL]

Zdá se, že tazatel to udělá pomocí btrfstune, tak jak popisuje. Je na btrfstune něco špatně když to nikdo neoznačil jako řešení?

[Aleš Kapica]

To co označil Tomášek jako řešení žádným řešením není. Pokud tazatel použil btrfstune, ok. V takovém případě, ať klidně označí jako řešení reakci, která ho k tomu přivedla. Osobně bych se toho bál. Měl jsem za to, že mu jde o vytvoření kopie 1:1. Ovšem to co s tím dělá tomu rozhodně neodpovídá. Ale proti gustu…

[xxl]

To, co jsi označil za odpověď ty, také není žádným řešením. Naproti tomu to, co jsem napsal já, dělá přesně to, co jsem potřeboval a na co jsem se ptal. Jestli jsi si myslel, že mi šlo o kopii 1:1, tak jsi si špatně přečetl dotaz. Jo a žádná z reakcí mě k tomuto řešení nepřivedla.

[Aleš Kapica]

To co jsem označil já, funguje. Podobné opičky jsem dělal už x-krát. A pokud považuješ za řešení to jak jsi to vyřešil, klidně můžeš označit příspěvek svůj. Byl to tvůj dotaz, takže víš sám nejlépe co je pro tebe nejlepší.

Jinak pokud chce někdo překopírovat Btrfs aby zůstalo vše jak bylo, z mého hlediska za překopírování 1:1 považovat lze. Ale to je pochopitelně věc názoru.

[Aleš Kapica]

Ale pravdou je, že jsi nepsal o kopírování ze stroje na stroj, nýbrž z disků na disk. A v takovém případě postup který jsi popsal je ok.

[Radek]

když jsme u tho btrfs, proč ho vlastně upřednostňujete oproti ZFS? :)

[PepanB]

není to tím že btrfs je součástí většiny dister a vlastnosti tohoto fs jsou podobné s ZFS? Podle mě BTRFS má před sebou velikou budoucnost. Zatím tento fs mám na discích asi 2roky a naprosto bez problémů

[Max]

Já jsem donedávna nevnímal ZFS vs BTRFS jako nějakou konkurenci. Každý z nich mi přišel, že je pro jiné použití.
ZFS požívám na storage, co mají stovky TiB. BTRFS pak na malé storage (osobní pc, notebook, 26TB home storage apod.)
Vzhledem k režiím ZFS jej nevnímám jako vhodný pro malé nasazení. Taktéž není vhodný pro menší nasazení kvůli sizingu. Když člověk staví něco většího, je to promyšlený, je tam plán atd. Když něco malýho, tak se to pak většinou v čase dost mění, na to je zase dobré btrfs.
Stále tedy tak nějak vnímám, že ty dva FS nejsou mezi sebou plnou konkurencí.
Zdar Max

[Andrej]

Já si například myslím, že ZFS (bohužel) zabíjí jeho licence, konkrétně tedy nemožnost začlenění do kernelu.

V posledních letech jsou sice DKMS moduly pro ZFS celkem použitelné, ale i tak se mi tu a tam stane, že se s novou verzí kernelu nepřeloží a je třeba čekat pár dnů (až pár týdnů), než to někdo opraví. Kdybych měl ZFS jako hlavní (nebo jinak důležitý) filesystém, tohle by mi celkem kazilo náladu.

Na mých většinou denně (a nejdéle týdně) aktualizovaných strojích podpora pro Btrfs vždy prostě je, out-of-the-box, i na custom kernelech, a nemusím se při každé aktualizaci (která je v ideálním případě zcela automatická) zabývat otázkou, zda se tentokrát ZFS přeloží nebo ne.

Je ovšem jeden případ, kde ZFS nemá žádnou konkurenci ani alternativu: FreeBSD. Jasně, na FreeBSD Btrfs nemám a tam ZFS zkrátka rulezzz.

[lertimir]

A jak je to s potřebou ZFS na dostatek operační paměti. Všude píší paměť proti disku cca 1:1000 Tedy 1GB operační paměti na 1TB disku. btrfs je významně efektivnější. Mám např. přenosný 5TB HDD s btrfs, a když jej připojím k notebooku s 8GB paměti, tak zátěž na paměť není významně pozorovatelná. Pokud by mě stejný disk se ZFS použil více než půlku operační paměti na své struktury, tak by to bylo velmi citelné.

[Andrej]

Záleží na tom, jestli člověk opravdu potřebuje online deduplikaci na ZFS.

Na Btrfs není a mně osobně nikdy nechyběla; hodí se pro jiná nasazení a jiná data, než mám já.

No a bez deduplikace žádný zásadní problém s pamětí u ZFS nevidím. V požadavcích se píše cosi o 2 GB RAM.