Názory k článku Borg: odpor je marný, budete zálohováni, komprimováni, šifrováni a odesláni

Doplnil bych, že pro desktop existuje grafické rozhraní Vorta. I ve flatpaku s integrovanou instalací borgu.

A zálohování více strojů na jednu instanci je komplikovanější, borg neumí provádět dvě operace nad jedním úložištěm zároveň, takže je potřeba ty instance časově rozložit.

:D hned spreaduju na svý mašiny :D

Ne pižďucha, ale pišťucha.

Pika je zvíře a autorka aplikace si přeje, aby se jeho název lokalizoval. No a v češtině má takový ujetý název.

https://cs.wikipedia.org/wiki/Pi%C5%A1%C5%A5uchovit%C3%AD

Mam osobnu skusenost s Vorta pre zalohovanie osobneho PC na harddisk a mozem odporucit. Predtym som pouzival rsnapshot, co je vlastne jeden zlozity bash skript vyuzivajuci hard-linky a rsync - spartanskost tohto nastroja ma svoje caro, ale u mna s vekom prichadza pohodlnost a tam Borg s Vorta GUI malinko vedie :)

Diky za clanok!

Ad: zálohovat bez šifrování není nikdy dobrý nápad.
Přinejhorším vám zálohy zašifruje nějakej ransomware. ;o)

Poznámka: parametr --append-only jsem nepřehlédl - však píšu, že přinejhorším.

Nějaký čas jsme používali na zálohování cca 5x100GB dat s velkým počtem souborů (jednotky milionů) restic a spotřeba paměti byla neúměrná tomu, co na těch serverech běželo. Borg funguje podobně, takže se tam ten problém objeví pravděpodobně taky. Máte někdo zkušenosti jak na tom je?

Zalohuji s borgem 15TB dat, neco pres 40M souboru, stroj na kterem backup bezi ma 128GB RAM, borg z toho vyuziva minimum.

To nezní špatně, díky za info.

Porovnání bylo na https://blog.stickleback.dk/borg-or-restic/ ale bohužel už neběží. Co si pamatuju, restic umí víc storage backendů, ale je pomalejší a náročnější na prostředky (hlavně paměť).

Já mám porovnání s Proxmox Backup Serverem a i tam je Borg výrazně rychlejší (spotřebu paměti nevím).

Backendů má Restic fakt hodně. Umí nastrkat data prakticky do čehokoli. Vysoké nároky na paměť byly způsobené tím, že měl celý index v RAMce. V době, kdy jsme ho používali, na to už existovalo PR, ale netuším, zda to ten člověk dotáhl. Už to jsou dva roky, tak ta situace teď může být úplně jiná.

> Máte někdo zkušenosti jak na tom je?

máme. Někde mi běží backup skrze borg, a jsou tam nižší desítky milionů souborů a nějaký toxický patterny ve využití memory jsem neviděl.., resp.

Jestli chceš nějakou konkrétní metriku, která se umí měřit telegrafem od influxů, tak ti to klidně naměřím a z grafany vyprintscreenuju.

.cache/borg má okolo 15 GB, tj to se v pohodě do ramky vejde...

> spotřeba paměti byla neúměrná

co si pod tím představuješ?

Moc díky za nabídku. Zajímalo by mě maximální využití paměti při zálohování a počet zálohovaných souborů a množství dat. I tak ale myslím, že na tom Borg bude líp než restic. Píše se to i v porovnáních ze současného roku.

Neúměrná mám na mysli, že když aplikacím na serveru stačí 16 GB RAM, tak by zálohování nemělo vyžadovat dalších 8.

> Neúměrná mám na mysli, že když aplikacím na serveru stačí 16 GB RAM, tak by zálohování nemělo vyžadovat dalších 8.

jo, no nižší jednotky GB si to určitě vezme. Mám to na fileserverech na kterých mám kvůli cache nižší stovky GB RAM, takže se mi to v tom úplně ztratí.

Ješě mi běží borg check, což ještě pár dní zabere (remote repo over sshfs) tak pak kouknu jestli ta čísla z grafany budou nějak smysluplná.

8. 12. 2022, 14:01 editováno autorem komentáře

Dneska už taky máme servery se 128+ GB RAM, ale tenkrát jsme jeli v DigitalOcean a tam je každé GB navíc krvavě zaplaceno.

Na čísla jsem zvědav.

S Borgbackup mám asi 5 let zkušeností z desítek strojů a můžu ho vřele doporučit. Je velmi efektivní, hodný na prostředky včetně storage, spolehlivý, nechybí mu důležité vlastnosti.

Komprese může být "auto,zstd", což znamená "Use a built-in heuristic to decide per chunk whether to compress or not."

Pokud nemůžete na druhé straně spustit borg server, dá se zálohovat i přes sshfs.

Pokud byste chtěli zálohovat úplně jinam tak je možnost třeba tady: https://www.borgbase.com

Nějaký nezávislý webxicht měl být asi tady, ale nějak to umřelo: http://www.borgbackupserver.com

Umi Borg pouzivat S3 kompatibilni uloziste?

Ne primo.

neumí. A a je mi to dost líto, s ohledem na deduplikaci by to byla bomba, takto je člověk odkázaný na tooly typu duplicity.

Já osobně mám borgový archiv uložený na Backblaze připojený pomocí rclone, funguje to poměrně dobře a stojí to pár korun. Bude v něm rozhodně dost přes milion souborů a tak terabajt dat.

rclone znám a na cosi i používám.. Stackovat to pod borg se bojím, protože se zálohami jsem konzerva.. Ale asi tomu dám šanci.

Take se pripojuji ke chvale Borga. Pouzivam ho uz ctyri roky, zalohy delam na externi, pro tento ucel specialne urceny disk a nemuzu si ho vynachvalit. Ma pomerne velke mnozstvi funkci a parametru, ale presto je zakladni prace s nim (aspon pro me) snadno pochopitelna. Me se hodne zalibilo prochazet obsah zaloh mountnutim pres fuse, to je opravdu velmi uzitecna vec. Dokonce mi hodne pomohl s migraci dat z PC do notebooku, kdy jsem byl cca 2 roky odkazan pouze na notas. Usetril mi spoustu casu a nervu :)

Jedine s cim jsem se trochu musel poprat bylo nastaveni seznamu souboru a adresaru, ktere se budou vzdy zalohovat a tech, kterych si nema vsimat (vzdycky zalohuji jen vybrane soubory a adresare, nikdy ne vsechno - povazuji to za zbytecny luxus). A potom pozadavek, aby zalohovani zacalo okamzite, kdyz pripojim do pocitace dany zalohovaci disk (to je ale spis uz vec systemu. Zatim to mam nejak poresene pres udev, ale nejsem s tim jeste uplne spokojeny).

Jeste bych doplnil, ze se silne doporucuje, aby zalohy v jednom repositari delal vzdy jeden a tentyz uzivatel, protoze potom to muze namixovat prava zaloznich souboru a nemusi to dopadnout uplne dobre.

Jinak pekny clanek, diky :)

Když se namixují práva záložních souborů, problém to není, jen zálohování selže a Borg samozřejmě sletí proto, že nemůže zapisovat. Stačí pak nastavit práva správná a spustit zálohování znovu. Stalo se mi mnohokrát.

Jak zvládá Borg zálohovat velké soubory - obrazy virtuálních strojů? V dokumentaci jsem našel jen to, že je potřeba použít systém souborů (FS) podporující snapshoty, aby byla záloha konzistentní. Takže to asi někdo používá. Věřím, že záloha je díky deduplikaci malá, ale jak dlouho trvá, než Borg najde změny ve velkém souboru? Lze ho přimět, aby pro zjišťování změn využil vnitřní strukturu CoW FS (jako 'zfs send/receive')?

Jeste, kdyby to bezelo i na widlich...

Nativne to nebezi ale da se vyuzit wsl. K inspiraci - https://vorta.borgbase.com/install/windows/

Ako je to so spolupracou s paskou? Da sa jeho "repository" aspon raz za cas hodit na pasku a v pripade potreby to dat spet a obnovit zo zalohy?

repository je nějaká adresářová struktura, ve který je directory "data", ve který jsou ještě dvě úrovně directories a v nich půlgigový chunky.

Tj. nevidím důvod, proč by to nemělo jít odlejt na pásku, pokud to repo není zdrovna aktivně zapisovaný.

S ohledem na důvěryhodnost pásky bych zvážil i (ne)odlití klíčů, ale to je na separátní téma.

Velikost chunku se dá, mimochodem, nastavit, což člověk ocení právě když to má někde v cloudu.

Nemáte někdo, prosím vás, zkušenost, jak ta technologie funguje na zálohování fotek (jpg, psd, tif)? Uspoří to nějaké místo?

Podobně, jako u zálohování jakýchkoliv jiných běžně komprimovaných dat. Čili úspoří pouze za předpokladu, že půjde o identické soubory, zjednodušeně řečeno.

Konkrétně to funguje tak, že jsou soubory rozděleny na různě velké bloky, pro každý z nich je vypočítán haš (HMAC-SHA256) a do zálohy jsou uloženy jen ty bloky, které v ní ještě nejsou. V každém repozitáři se zálohou se pak takový blok nachází právě jednou, bez ohledu na to, odkud pochází.

Mám související dotaz: Pokud se existence bloku v úložišti posuzuje jen podle haše, nemůže se stát, že dojde - byť s minimální pravděpodobností - ke kolizi a po obnovení dat ze zálohy dostanu něco jiného? Odhaduju, že to asi bude souviset s tou velikostí bloku - ale i když ji shora omezím, dá se pracovat s jistotou, nebo jen velmi, velmi nízkou pravděpodobností, že k takovému problému dojde?

Je mi jasné, že do hry vstupují i další jevy možná s řádově vyšší pravděpodobností, jako třeba otočení bitu v paměti nebo při cestě po sběrnici, ale zrovna u procesu zálohování bych radši pracoval s jistotou než s pravděpodobností, pokud ta možnost kolize existuje :-).

4.3*10-60 pravdepodobnost kolize je dostatecne nizka.

Diky moc za tento clanek. Zrovna se tady uz janevim jak dlouho trapim s backupama na Synology pomoci rsync. Narazil jsem na nekolik problemu, ktere by se resily tezko a navic je to samozrejme jenom kopie systemu bez historie.
Po precteni tohoto clanku zahazuju vsechno a zacinam delat pokusy s borgem.

Pro Synology existuje package Borg od SynoCommunity. Je to verze 1.2.1-12. Vyzaduje Python 3.10, ktery se automaticky nainstaluje.
Na https://borg.bauerj.eu/ jsou pak predkompilovane binarky posledni verze Borgu pro ARM, Staci jen stahnout a updatnout

wget https://borg.bauerj.eu/bin/borg-1.2.2-armv6 -O /usr/bin/borg
chmod a+x /usr/bin/borg

Bhehehe v man borg je ohledně formátu data odkaz na XKCD 1179 :-D

Přidám ještě jednu reakci do záznamu.
Autorovi dík za článek - přišel poměrně vhod a v pravou chvíli :-)

Narazil jsem na určitý zádrhel v souvislosti s povelem prune , kde se snažím o zmíněné rotační schéma "děda otec syn".
Volby jako --keep-daily, --keep-weekly nebo --keep-monthly podrží vždy poslední zálohu, která spadá do daného dne, týdne, měsíce. Poslední zálohu, tzn. poslední "archive" v rámci předmětného repozitáře, za daný časový úsek.

Usmyslel jsem si, že bych rád do společného repozitáře zálohoval několik dílčích "oblastí" - zdá se, že autoři a zastánci Borgu jim tu a tam říkají "topics". Řekněme, že mám databázovou aplikaci, kde se vyvíjejí jak data, tak bináry aplikace (pravidelnými aktualizacemi) - a já bych rád zálohoval sice každý den oboje, ale do oddělených archivů, protože pro bináry jsem schopen připravit data k záloze jiným (vhodnějším) způsobem než image databáze.

Mám samozřejmě možnost, jednotlivé zálohy (archives) uvnitř společného repa po svém pojmenovávat. Zádrhel spočívá v tom, že když budu mít každý den dva archivy, tak bez dalšího doladění by mi borg prune --keep-daily jedno z obou zálohovaných temat obratem vyřadil při rotaci - přežilo by pouze téma, které se v denním skriptu zálohuje jako poslední v pořadí.

Protože se mi nechtělo, dělit repo do dvou jenom kvůli tomu, abych mohl důstojně rotovat zálohy, pro jistotu jsem se zeptal. A obratem přišla odpověď! :-) Zřejmě přesně tomuto účelu slouží volby --prefix a --glob-archives . Slouží k filtrování v názvech. Tyto dvě volby se navzájem vylučují. Pokud jednu z nich použijete, borg prune "vyjednotí" pouze archivy, jejichž název odpovídá zadanému výrazu - ostatních si nevšímá. Tzn. můžete provádět operaci "prune" per téma.

Prefix je prostě prvních pár pevných znaků - ovšem zdá se, že i zde funguje substituce proměnných. Glob je pružnější výraz s využitím hvězdičkové konvence - dokonce je možné, že lze do globu kódovat i regulární výraz.

Dokumentace: man borg-prune a borg help patterns

Mimochodem v Debianu 11 je borg v1.1.x, který ještě nemá oddělený povel compact. Zaslechl jsem v neformálních komentářích, že předchozí verze měly fázi compact jako nedílnou součást povelu prune. Důvody k oddělení compact vidím dva: jednak compact dlouho trvá, druhak lze nyní provádět explicitní <compact> následně po promazání záloh povelem delete (pokud bych si chtěl algoritmus výběru archivů pro pruning napsat externě).

Nikde jsem nenašel vysvětlivku, zda po provedeném prune bez následujícího compact bude při dalších zálohách borg znovu využívat již alokovaný a nyní pouze nevyužívaný prostor (pozůstatek po prune) - nebo zda si prostě alokuje v souborovém systému další...