Konverze ext4 --> BTRFS
Nástroj btrfs-convert byl z balíku btrfs-progs odstraněn údajně kvůli nespolehlivosti.
Já jsem si ho však do /bin doplnil (ze starší verze).
Konverzi jsem prováděl mnohokrát a vždy to bylo naprosto bez problému.
Alternativní metoda je nejprve data zálohovat pomocí TAR, pak oddíl ext4 zformátovat na btrfs a potom data obnovit zpátky. Nicméně to už není tak rychlé/elegantní....
Myslím, že Btrfs není vhodná volba, pokud máte data rozložená takto. Nepřinese prakticky nic navíc a nutně zvýší rizika (a to by platilo, i kdyby nemělo spoustu známých bugů).
Konverze bude vždy nebezpečná, nástroj závisí na dokonalé znalosti zdrojového i cílového formátu a hlavně na správnosti a konzistenci dat. Když bude problém v něčem z toho, docela se zapotíte.
Tar je IMO naprosto vhodné řešení, stejně potřebujete kapacitu na plnou zálohu, takže to samé vyžaduje i tar.
A jaký FS je dobrá volba pro držení záloh? Zrovna teď řeším, nějaké řešení záloh domácích strojů a napadlo mě postavit nějaký backupserver nad btrfs s disky v jeho nativním raidu. (Popravdě díky seriálu co vychází zde na rootu, dříve bych na prvním místě sáhl po zfs, pokud by bylo malo RAM pak po mdadm+lvm+xfs).
Já bych na takový případ nevolil snapshoty na úrovni FS. Pokud stroje běží na Linuxu, nasadil bych obyčejný Borg Backup, který šifruje, komprimuje, deduplikuje a je rychlý. Obnova je snazší, než se crcmat s proudem dat snapshotu. Jednou z nevýhod záloh snapshotů je, že nezískáte jednoduše a rychle jen část souborů. Tradiční zálohovací mechanismy jsou lépe připravené na obnovu na menší disk (s vynecháním určených souborů) apod.
Snapshoty jsou jednoznačně užitečné, ve spoustě případů se hodí, ale rozhodně ne tak moc, jak se rádo v populárních článcích prezentuje.
Osobně bych rozhodně volil ZFS nad Btrfs. Umí vše, víc a líp, a je jen málo vlastností, a ke všemu jen teoreticky, které má Btrfs lepších.
Ja len doplnim, ze ked zfs, tak:
1) zfs a taku distribuciu, kde je zfs podporovane;
2) pokial uz niekto porusi bod 1, tak nedavat root systemu na zfs, ale na fs, ktory je v danej distribucii podporovany. Daleko lahsie sa riesia problemy, ked nabootovany system nevie najst zfs volume so zalohami/zdielanymi subormi/atd, ako ked pri boote nevie najst svoj vlastny root.
Ale jasně že můžete. Kolegou výše odkazovaný btrbk to tak přesně dělá, stejně jako celá řada dalších btrfs backup řešení, včetně komerčních (od Synology třeba). Typicky i s retenčními politikami a "chytrými" diferenciálními snapshoty (kdy můžete svévolně promazávat dílčí snapshoty aniž by se ztratilo něco na ně navazujícího).
Jak to? Spíš naopak - vykopíruju si přesně to co potřebuju.
Pokud to máte odlité jinde, je situace jiná. Snapshot na běžícím úložišti není záloha, o tom nemluvím - k tomu se snapshoty hodí ideálně, jen to nenazývejme zálohami.
Když srovnáte zálohování btrfs snapshotů (tedy odlití dat jinam, třeba i off-site) proti tradičním zálohovacím mechanismům, btrfs se nejeví moc jako přínos. Smysl to dává tam, kde potřebujete zajistit atomicitu, ale takových situací není moc na to, aby to bylo dobré "platit" režii za univerzální řešení.
> Pokud to máte odlité jinde, je situace jiná.
Není.
Stačilo by se aspoň podívat na existující řešení a nevařit z vody. Mám-li zálohy "odlité jinde" (jde zálohovat nějak jinak?) pomocí btrfs send/receive, mám tam 100% read-only kopii, absolutně bez omezení přístupu nebo použitelnosti. Není to tar, ze kterého smím vybalit soubory, co chci, je to plně funkční subvolume, na kterém v případě potřeby můžu okamžitě rozjet provoz. A k tomu tenké inkrementální zálohy. A historii. Deduplikaci.
Ano, ale to musíte získat tu zálohu zpět lokálně, abyste s ní pracoval. Když máte zálohu na vzdáleném úložišti, tak to už situaci komplikuje. Omezuje Vás to i vlastnostmi úložiště, jestli tam snapshot dostanete.
Jak znovu a znovu píšu, snapshoty jsou užitečné na mnoho věcí, ale nedá se říct, že je to univezrálně nejlepší způsob zálohování dat.
Ja jsem fanda hlavne ZFS, ale to je asi jedno a mam predpoklad, ze zdrojovy i cilovy (zalohovaci) disk je ZFS. Pak mi na cilovem ulozisti (zalohovacim serveru) vznika po "odliti" snapshotu uplne stejna struktura jako na puvodnim disku a s temi snapshoty (na tom zalohovacim serveru) mohu zachazet uplne stejne snadno, jako s puvodnim diskem, protoze je to oboje uplne stejne ZFS.
Neni v tom zadny rozdil a docela me zajima, kde vam vznika ta komplikovanost. Ja chapu ze mate na mysli nejakou konkretni situaci ve ktere to tak je a ktera je v necem odlisna. Vazne jen hadam, ale mozna ze ukladate ta presouvana data do souboru na uplne jinem ulozisti misto do ZFS, pak je jasne, ze s tim zachazet neni tak snadne, ale pokud je cilove uloziste take ZFS, tak zadny problem nevznika. Pokud tedy navis s tou zalohou pracuji primo na zalohovacim serveru. Je to tak nebo nejak jinak?
14. 2. 2020, 16:31 editováno autorem komentáře
Asi jsem to blbě napsal - teď mám data na locale a jednou za čas udělám readonly snapshot a ten přes rdiff-backup nasypu na NAS, na kterém je disk s ext4. Kdybych ho předělal na btrfs, tak můžu použít btrfs send | recieve a vynechat jeden mezikrok
Otázka třeba je za jak dlouho chyba v btrfs na archu proteče do debianu stále na NASu