Dotaz: Kopie btrfs disku

[lertimir]

Potřebuji na jednom starším systému provést následující operaci. Zazálohovat data z btrfs volume (formálně btrfs na single disku, ale pod ním jsou blokové vrstvy jako mdraid), smazat mdraid, vytvořit btrfs RAID10 a vrátit data ze zálohy. BTRFS nemá subvolume a snapshoty, stačí mi proto pro zálohu prostý tar, a budu mít na vše zpět nebo jsou zde rizika?

---

---

Odpovědi

[Jendа]

Pozor na xattrs (tar --xattrs), posledně jsem takhle kopíroval systém a pak nefungoval ping pro ne-roota protože neměl CAP_NET_RAW (getcap /bin/ping). A pak prej ještě --sparse a -p ale to je snad default. Další moje oblíbená chyba je že se /tmp a podobným adresářům nezachová +t, takže tam uživatelé nemohou vytvářet soubory.

[xxl]

Vzhledem k tomu, ze btrfs začíná tím, že si udělá „root“ subvolume, tak subvolume máš. Pokud budeš zálohovat na btrfs, můžeš použít i btrfs send | btrfs receive.

[Max]

Záleží, zda je bootovací apod. Pokud je bootovací UEFI a uděláš kopii, nic se nemění. Pokud je to bios boot, tak musíš zapsat bootloader / grub (pokud překopáváš celý disk a né jen partition).
Jinak zálohovat můžeš tarem, nebo pokud zálohuješ na další místo s linuxovým fs, tak i jen kopií (cp -av). Pro správné kopírování bych použil bind mount, aby jsi se vyvaroval kopírování dynamických věcí v dev, proc, sys, run apod.:

mkdir /mnt/old
mount -o bind / /mnt/old
cd /mnt/old
cp -av * /mnt/zaloha/

Zdar Max

[Zoufalec]

Jinak zálohovat můžeš tarem, nebo pokud zálohuješ na další místo s linuxovým fs, tak i jen kopií (cp -av). Pro správné kopírování bych použil bind mount, aby jsi se vyvaroval kopírování dynamických věcí v dev, proc, sys, run apod.

--one-file-system ?

[Max]

Dříve třeba v "/dev" byly jak statické, tak dynamicky generované soubory. Ten parametr to podle mě nerozliší.
Já opravdu nechci řešit, že se někde něco nezkopíruje, nebo něco zkopíruje navíc. Chci to mít 1:1 a nejbezpečnější je to podle mě přes bind.
Zdar Max

[Max]

Koukám, že už nějaké bugy jsou opravený, takže beru zpět, asi to je také použitelný.
Zdar Max

[xxl]

Nemusíš brát nic zpět.

cp ani rsync, i při použítí volby --one-file-system, nezkopírují soubory z adresářů, přes které je namontováno jiné zařízení. Neříkám, že je to chyba, ale prostě tak to je.

Takže kopírování s pomocí mount --bind má pořád smysl.

[Max]

O tom vím, ale point s bindem byl o tom, aby tam právě nebyly zbytečné mountpointy a nedošlo k mylnému kopírování. Záleží, co od toho člověk chce.
Zdar Max

[lertimir]

S bootem to nemá nic společného. Je to pouze datový disk na který píše BackupPC své zálohy (standardní mount v /var/lib/backuppc). V současné době je skladba od železa: 4 stejné datové partišny, RAID-10 nad nimi, LUKS nad tím, a v něm btrfs. A připojen přímo kořen btrfs, žádné subvolumes. Cíl šifrovaný záloha na RAID 10. A když bych chtěl btrfs RAID10 místo mdraid tak pro stejnou funkcionalitu (šifrovanou zálohu) musím mít samostatné LUKS na partišnech a nad tim btrfs RAID10. A třeba opět připojený kořen. Což mi způsobí vyšší nárok na výkon pro LUKS (asi pouze 2x). Změna proběhne na místě, takže data potřebuji odložit, disky změnit a data vložit. Prostoru mám dost. Mezi tím jsem zastavil zálohování, nechal proběhnout tar, za 12 hodin dojel. Mám tedy odložený strom (jsou to asi 3 miliony kompresovaných souborů pod jejich hash hodnotami ve struktuře adresářů daných na prvních dvou úrovních prvním a druhým bytem hashe a další miliony odkazů u jednotlivých strojů, které na tyto zazálohované soubory odkazují ve struktuře jejich adresářů, dělá to přirozenou deduplikaci: jeden soubor je jeden hash i když je na mnoha strojích). Žádné xattr v stromu nejsou takže tento problém není. btrfs send | receive jsem nikdy nedělal a nebyl jsem si jist, jestli změna ze single disku na raid10 nebude potřebovat nějaké zásahy. Fakticky btrfs používám zde pouze pro scrub (kontrolní součty). Nic víc u těchto dat nevyužívám.

[lertimir]

Jen pro doplnění, tar tam a zpět provedl správně, co měl. Záloha byla zrestaurována a rychlost běhu na btrfs10 nad čtveřicí šifrovaných LUKSů je znatelně větší než původní sestava btrfs single nad LUKS nad mdraid10.

[Aleš Kapica]

Mohl bys to trochu víc objasnit? Pokud vím, LUKS je vrstva, která šifruje data. Pokud používáš Btrfs v multidevice módu, a LUKS má to být POD Btrfs, pak to znamená, že používáš dm-crypt a do Btrfs máš integrované pseudozařízení přes které se data sypou kamsi kde se šifrujou. Takové řešení ale podle mne postrádá výhody Btrfs multidevice. I když rychlost může být větší, protože se data před uložením honí v RAM.

[Andrej]

Aniž bych tušil, jakou konfiguraci tazatel používá, jen upozorňuji, že tady něco nesedí:

Pokud používáš Btrfs v multidevice módu, a LUKS má to být POD Btrfs, pak to znamená, že používáš dm-crypt a do Btrfs máš integrované pseudozařízení…

Proč jedno? Co když tam má integrovaná (mnohá) pseudozařízení?

Na stroji, u kterého zrovna teď sedím, vypadá kořenový FS (Btrfs RAID1) takto:

NAME       FSTYPE      FSVER MODEL                                   SIZE UUID
nvme0n1    crypto_LUKS 2     Seagate FireCuda 520 SSD ZP2000GM30002  1,8T 8fbfe3ee-6721-4025-af7a-4ca577dd42c7
└─dustbin0 btrfs                                                     1,8T 4bf8d9ff-a1b8-4fc2-927a-7764a374876a
nvme1n1    crypto_LUKS 2     Seagate FireCuda 520 SSD ZP2000GM30002  1,8T 8fbfe3ee-6721-4025-af7a-4ca577dd42c8
└─dustbin1 btrfs                                                     1,8T 4bf8d9ff-a1b8-4fc2-927a-7764a374876a

Další FS (Btrfs RAID6 data, RAID1C3 metadata) vypadá takto:

NAME       FSTYPE      FSVER MODEL                                   SIZE UUID
sdc        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T 923968d8-4526-4521-b4a3-35dc7f8564de
└─crypt5   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sdd        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T daa7a9f6-50de-4e3c-a3b2-c4a77bd7f410
└─crypt4   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sde        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T 28bad0e0-9328-49e8-af3a-6a5c39ab4988
└─crypt2   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sdf        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T b7d31ea4-e79b-41c6-9798-cdb28d67f251
└─crypt7   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sdg        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T 413861b8-262f-4c5b-839e-0d95117e1ed0
└─crypt0   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sdh        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T 83183f5e-0839-49c0-b023-b34f8e187cf0
└─crypt1   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sdi        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T 605f7a74-1c33-4580-8eee-c2f1b121b1c2
└─crypt3   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef
sdj        crypto_LUKS 2     WDC WDS400T1R0A-68A4W0                  3,6T 4c7375bd-51bd-4f2e-a75d-af1bac1d7eb9
└─crypt8   btrfs                                                     3,6T 9e439e61-7540-40a7-95f9-6922707389ef

Po jednom společném zařízení tam↑ není ani stopy. UUID LUKS zařízení se liší a jde tedy o různá zařízení, zatímco UUID filesystému (4bf8d9ff-a1b8-4fc2-927a-7764a374876a u menšího, e439e61-7540-40a7-95f9-6922707389ef u většího) se shodují, přesně dle očekávání.

Výhody multi-device Btrfs výše uvedená konfigurace rozhodně nepostrádá:

Label: 'dustbin' uuid: 4bf8d9ff-a1b8-4fc2-927a-7764a374876a Total devices 2 FS bytes used 1.05TiB devid 1 size 1.82TiB used 1.62TiB path /dev/mapper/dustbin0 devid 2 size 1.82TiB used 1.62TiB path /dev/mapper/dustbin1		Label: 'crypt' uuid: 9e439e61-7540-40a7-95f9-6922707389ef Total devices 8 FS bytes used 8.41TiB devid 1 size 3.64TiB used 1.44TiB path /dev/mapper/crypt8 devid 2 size 3.64TiB used 1.44TiB path /dev/mapper/crypt1 devid 3 size 3.64TiB used 1.44TiB path /dev/mapper/crypt2 devid 4 size 3.64TiB used 1.44TiB path /dev/mapper/crypt7 devid 5 size 3.64TiB used 1.44TiB path /dev/mapper/crypt4 devid 6 size 3.64TiB used 1.44TiB path /dev/mapper/crypt5 devid 7 size 3.64TiB used 1.44TiB path /dev/mapper/crypt0 devid 8 size 3.64TiB used 1.44TiB path /dev/mapper/crypt3
Data, RAID1: total=1.58TiB, used=1.05TiB System, RAID1: total=32.00MiB, used=320.00KiB Metadata, RAID1: total=43.00GiB, used=7.12GiB GlobalReserve, single: total=512.00MiB, used=0.00B		Data, RAID6: total=8.57TiB, used=8.38TiB System, RAID1C3: total=32.00MiB, used=528.00KiB Metadata, RAID1C3: total=23.00GiB, used=20.55GiB GlobalReserve, single: total=512.00MiB, used=0.00B

(Pravda je, že total= je v tomto výpisu celkem odjakživa nesmysl; ve skutečnosti i podle df -h je to 1,9T a 30T.)

[Want]

Nebuď zas takový jazykový purista. To, nebo ta, je vcelku jedno, podstatné je, že to máš tak jak jsem to měl na mysli.

[lertimir]

Asi jsem se nevyjádřil přesně: Mám 4 fyzické oddíly, sda1,sdb1,sdc1,sdd1 (samozřejmě označované UUID), nad každým je samostatný LUKS otvíraný klíčem, který je někde na root oddílu (také šifrovaném). LUKSy vytváří 4 šifrované zařízení /dev/mapper/backup1 až backup4. Nad těmito zařízením je btrfs raid10. A ten je mountlý do /var/lib/backuppc

Původní sestava byla: 4 fyzické disky, nad nimi mdraid 10. Což vytvořilo blokové zařízení /dev/md126, nad ním byl LUKS vytvořil /dev/mapper/backup, a nad ním byl btrfs single disk.

Původní idea byla: výhoda bude v méně šifrování - datový blok se zašifruje jednou a pak se rozdělí do raidu již stejná data. Ale současné pozorování je, že i když se každá kopie musí zašifrovat zvlášť do každého disku (dvakrát vetší množství dat zašifrovat), tak celkový průtok dat je vyšší.

BackupPC, jak jsem již psal, provádí deduplikaci záloh tím, že každý zálohovaný soubor je kompresovaně uložen pod názvem, kterým je hash hodnota souboru (zapsaná hexa), a je umístěn v adresářové struktuře, která má první a druhou úroveň adresářů odpovídající první a druhý byte toho názvu (např ./04/ac/04ac02024c52...) v druhé větvi jsou počítače, podtím jejich konkrétní zálohy a podtím jejich adresářové stromy, které obsahují jen odkazy na tu primární datovou zálohu. Tedy jeden konkrétní soubor je v záloze umístěn jen jednou, i když je na mnoha počítačích a mnohokrát z jednoho počítače zálohován. Navíc pro zálohu BackupPC používá standardní rsync na zálohovaném systému, ale na serveru používá upravený rsync server (rsync_bpc). Nezkoumal jsem zdroják, ale podle chování a zátěže serveru jsem si jist, že rsync_bpc si uchovává (čte ze stromu) hashe místo toho, aby četl a porovnával soubor, protože v případě zálohování dat, které se nezměnili od poslední zálohy, je klient silně zatížen a server nedělá téměř nic.

[Andrej]

Jen pro doplnění, tar tam a zpět provedl správně, co měl.

Možná… Téměř…

Jistota správného přenosu je jen a pouze u btrfs send ... | btrfs receive ....

V případě utilit typu tar je potřeba myslet na --xattrs, --acls a --selinux, což bývá implicitně vypnuté, tj. implicitně se všechna tahle data ztratí, pokud existují. (To třeba rsync je na tom ještě hůř: podporuje jen první dva uvedené argumenty, zatímco SELinux data potichu zahodí.)

[lertimir]

Právě, před tím než jsem původní strukturu zrušil, jsem si zjistil, že xattrs a ACL ve struktuře není uplaťněna. A proto jsem se spokojil s tarem, a jak jsem psal dříve, z btrfs rysů na tomto oddíle mě zajímal využíval jsem kontrolní součty.

[pavele]

rsync samozřejmě atributy SELinux umí zkopírovat, slouží k tomu překvapivě parametr "X".

Příklad kopírování:

rsync -avxHAX --delete --numeric-ids /zálohovaný-adresář/ root@192.168.0.17:/mnt/backup/zaloha/zálohovaný-adresář/

Otestováno na starém systému CentOS 7.

[Andrej]

Já bych volil btrfs send místo tar; tím je zaručeno, že se přenesou fakt všechna metadata, i taková, o kterých rsync nebo tar na své úrovni abstrakce vůbec nemusí vědět.

A pak z těch serializovaných dat udělat na novém FS btrfs receive, vzniklý subvolume prohlásit za hlavní a je vymalováno.