Dotaz: Rsync - migrace OS z Ext4 na Btrfs

[Petr Fiedler]

Zdravím,
poraďte prosím, jak migrovat OS z Ext4 na Btrfs? Moje laická představa je taková, že bych pomocí rsync s patřičnými parametry OS vykopíroval z SSD na externí HDD, na tom SSD vytvořil GPT, vytvořil oddíl FAT32, druhý Btrfs a rsyncem tam vše vrátil. Mám 4 otázky:

1. Jaké parametry použít pro rsync? Vím o 2 variantách, respektive o 3.
   Buď
   

   rsync -avxHAXS --numeric-ids --info=progress2

   nebo
   

   sudo rsync -aAhHPSvXz --inplace --numeric-ids --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / /path/to/backup

   U druhé varianty mi bylo řečeno, že to nezkopíruje z /dev statická zařízení, která tam mají být a která by byla vidět v rootfs z live, kdy do /dev neni připojen dynamický generátor udevfs. Prý by tedy bylo lepší:
   

   sudo mount --bind / /mnt/source
   sudo rsync ${parametry} /mnt/source /mnt/target

   Takže jak?
2. Jak to udělat, aby to bootovalo?
3. Jak udělat subvolumes a čeho?
4. Na tom SSD poběží Raspberry Pi OS s Nextcloud a Mariadb. Myslím, že s Btrfs je pro databáze doporučeno něco vypnout, ale už nevím co. Jak to nastavit?

Uvítám i jakoukoli jinou radu.

Odpovědi

[Max]

Já používám klasiku po staru. Tj.

mkdir /mnt/source
mount -o bind / /mnt/source
rsync -Pav /mnt/source /mnt/target

Nebo místo rsync použít "cp -av", je to jedno. Existují i parametry, pomocí nichž lze přeskočit /run /dev /proc apod., ale já raději jedu přes bind.
EFI lze taktéž úplně normálně kopírovat přes cp.
Registraci boot entry do UEFI lze udělat pomocí efibootmgr, ale pokud je grub.efi pojmenován jako boot64.efi v příslušné adr struktuře, tak to většina UEFI načte bez registrace, protože koukají na default názvosloví Windows.
Zdar Max

[Petr Fiedler]

mount -o bind / /mnt/source

To jako tímhle způsobem mountuješ a následně exportuješ běžící systém?

[Max]

Ano. A pokud josu tam služby jako MySQL apod., tak před posledním rsyncem je stopnu, abych měl konzistenci dat.
Zdar Max

[Petr Fiedler]

A není lepší nastartovat live a rsyncnout vypnutý systém?

[xxl]

To víš, že je to lepší. Ale ty sám jsi formulováním svého dotazu navodil dojem, že chceš kopírovat běžící systém.

Pokud však nabootuješ do nějakého live systému, nemusíš se o obsah adresářů, které chceš vyloučit z kopírování kvůli tomu, že na běžícím systému obsahují nějaká dočasná data, vůbec starat.

[Max]

Pokud služby neběží, tak je to vážně jedno.
Zdar Max

[k3dAR]

pokud nemas problem s restartovanim, tak ano, ale jinak je to v podstate jedno (pri pouziti vise zmineneho bind rootfs do dir ktery pro rsync source pouzijes), vadilo by to pripadne jen databazi, kterou muzes na chvili stopnout... osobne to tedy delam z ziveho tak ze nejdriv projedu poprve rsync a pak jeste 1-2x stejne aby se dorsynclo to co se od predchoziho zmenilo...

[Andrej]

Částečně off-topic, ale přece:

Matně si vzpomínám (ale pouze matně, přece jenom hodně chlastám atd.), že od doby, kdy je systemd a udev a kamarádi už přímo v initramfs / initcpio / initjakkolivsetojmenuje, už v adresáři (mount pointu) /dev vůbec žádná zařízení (uzlové soubory) permanentně být nemají + nemusí.

Přinejmenším já tam tedy nic nemám; když mountnu kořenový filesystém ještě jednou do /mnt, abych tudy mohl nahlížet pod mountpointy, tak v /mnt/dev (nebo případně /mnt/kořenový/subvolume/dev, v závislosti na uspořádání FS) opravdu není vůbec nic. Prázdno.

Tj. ten přenos /dev uzlů dost pravděpodobně není žádoucí ani potřebný.

Jak to udělat, aby to bootovalo?

1. Upravit /etc/fstab, aby to odpovídalo realitě.
2. Upravid příkazovou řádku kernelu, aby to odpovídalo realitě. (Což u některých bootloaderů, třeba u GRUBu, vymyslí sám od sebe nějaký mkconfig skript, zatímco u jiných je potřeba v příkazové řádce kernelu něco explicitně (po)upravit, root=UUID=... (pokud se při mkfs.btrfs neobnoví UUID původního FS), rootflags=subvol=... (pokud se nepoužívá implicitní subvolume), atd. atp.)
3. Vygenerovat znova initramdisk (dracut, mkinitcpio, update-initramfs, … — každé distro má na to nějaký návod).
4. Nebo znova vygenerovat a případně podepsat Unified Kernel Image (pomocí ukify nebo co se používá), pokud je to jediný způsob, jak upravit příkazovou řádku kernelu.

Jak udělat subvolumes a čeho?

Třeba /etc pro snadné zálohování / porovnávání / verzování. Taky různé podadresáře /var (případně /var samotný), podle velikosti a míry využití. Aby se dali třeba různí démoni odděleně snapshotovat a zálohovat, aby se spolu s důležitými daty nezálohoval taky /var/cache, atd. (Virtualizace typu libvirtd si obvykle nějaké snapshoty vytvoří samovolně.) Pokud jde o /home, tam je nejlepší nedělat manuálně žádné subvolume, ale nechat to na systemd-homed (/etc/systemd/homed.conf):

[Home]
DefaultStorage=subvolume
DefaultFileSystemType=btrfs

[a1bert]

btrfs umi pomoci btrfs-convert in-place imgraci ext? na btrfs

https://btrfs.readthedocs.io/en/latest/Convert.html

[Petr Fiedler]

Vím o tom, ale chtěl jsem mít OS zašifrovaný LUKSem, takže vize byla taková, že na ext. HDD přemístím OS, vytvořím na původním SSD GPT, FAT32 oddíl pro EFI, zbytek zašifruji, vytvořím Btrfs, vrátím OS a doladím.

[Petr Fiedler]

Zapomněl jsem napsat, že třeba k3dAR s tím nemá moc dobrou zkušenost. OS se mu pár dní po konverzi rozsypal.

[k3dAR]

potvrzuji, sice to bylo asi pred 3(?) lety, ale byla to jedna (prvni) z mejch 2 zkusenosti testovani a zaroven "zboreni" BTRFS, kdyz sem se o tom pak nekdy zminoval, bylo mi od "BTRFS Ultras" "naznaceno" ze primej prevod ext4=>btrfs je rozhodne spatnej napad...

[k3dAR]

spis nez jak to prenest bych se zamyslel nad tim jak/zda Raspberry podporuje to co je tvuj cil
- RPi UEFI normalne neumi, maji neco experimentalniho(uz par let?) ale nezkoumal sem to
- boot z LUKS zda se normalne neumi, nasel sem snad aktualni treba tohle jen sem to hodne rychle prolitnul, skripty doinstalji potrebne balicky, pridaji skript pro initramfs pro dotaz na luks heslo pri startu...
- ad BTRFS rootfs, tady je celkem dlouhe howto (ale z 2017) ktere sem jakozto Non-BTRFS user ani nekoukal co dela