Názory k článku Zálohování s Baculou: otevřený systém pro komplexní scénáře

Jeste furt to neumi vytizit vice nez jeden core na cpu?

Hele, uz jen predstava, ze nekdo bude na kazdej zalohovanej system instalovat nejakou vopicarnu, je naprosto mimozni.

A snad jeste vic mimo je predstava, ze nekdo bude pouzivat 10 ruznych zalohovacu pro 10 ruznych systemu, protoze neznam ani jednu jedinou situaci, kde by se vyskytovalo homogeni prostredi = vsude tux (a idealne totez distro).

Ve finale vubec nevim, proc bych mel pouzivat uchylnosti jako tar nebo dump ... kdyz tu mame btrfs snap. Pricemz drtiva vetsina zalohovanych stroju bezi virtualne, takze je uplne jedno co je uvnitr za system, protoze se zalohuje cely VMko zvenku.

Když zálohujete VM "zvenku", tak je to sice zdánlivě méně práce, ale systémy uvnitř se nedoví, že byly zálohovány. Což je, speciálně pro MS aplikace (Exchange, SQL), problém. Jasně, řešitelný problém, ale pořád je to práce navíc.
A třeba já jsem v situaci, kdy mám cca 180 virtuálů a 2/3 z nich zálohuju "zevnitř" lokálním klientem - protože máme takový malý privátní cloud pro naše organizace, kterým hostujeme servery a tak budu buď zálohovat celý VM a pak řešit požadavky "účetní si přepsala excel XY, obnovte to", nebo dostanou přístup do lokálního klienta a na základě návodu si soubory obnovují sami.

"ale systémy uvnitř se nedoví"

Rekl kdo? Virtualni system se samozrejme muze dozvedet ze se chysta zaloha a pokud o to admin stoji, tak i dozvi. S tim zadny problem neni. U drtivy vetsiny systemu je to ovsem sumafuk.

Pokud se budem bavit o databazich, tak ani zdaleka nestaci, ze se o nejakem zalohovani dovi nejaky system ... a pokud je rec o MS ... tak pod uplne spatnym clankem ze? Kdyz je to tux only.

Edit: Mimochodem, u VM lze vytvorit snapshot vcetne RAM, tudiz se pripadne system da obnovit do beziciho stavu ... vcetne te RAM.

19. 12. 2024, 14:34 editováno autorem komentáře

Jak jsi prisel na to, ze je Bacula tux only?
https://www.bacula.org/binary-download-center/

Aj komerčné systémy napríklad IBM Storage Protect (teda bývalý IBM Spectrum protect alebo Tivoli Storage Manager) inštalujú klienta na každý zálohovaný stroj.

No pokud mam DB v HA, tak je celekm dobrej napad zalohovat dump. Zvlast kdyz mi v tom HA toho slitne vic (nebo vsechno).

Předně, k instalaci aplikace, krom toho, že to je "mimózní" vlastně z vašeho příspěvku není jasné, co je na tom špatného, klienti existují pro velké množství OS a homogenní prostředí nevyžadují, a myslím že i v článku je zmíněn klient na Windows.

K vašemu btrfs snap, snapshoty jsou spíše pro disaster recovery.

Instalovat cokoli kamkoli === udrzovat to, a resit, co to kde rozbije. Setrvale a dlouhodobe. Pri stovkach nebo vetsim mnoztvi instanci neco takoveho nikdo svepravny nepripusti.

Jako bonus to samozrejme znamena dalsi zatizeni toho potencielne zalohovanyho stroje, krat jejich pocet.

To je ale realita doby, zvlast v Enterprise a Midsize spolecnostech.
Proste na pozadavek vytvoris VM, nainstalujes vyzadany OS a v nem podle sablon instalujes mimo aplikacni veci i tunu admin/security SW (zalohovaciho klienta, linuxovy antivir, monitorovaciho klienta, atd.).

Tyhle odpovedi/reakce lidi, kteri nevidi dal za svuj usecase me vzdycky pobavi...

ad btrfs: asi záleží taky na use casech, ale neřekl bych, že je to jenom pro disaster recovery. Notebook a workstation mám zálohovanou přesně takhle. Ano, dá se to použít pro disaster recovery (a u notebooku pro migraci na nový hardware), ale jako backup dat to funguje taky velice krásně. Na backup serveru mám normálně přístupnou celou adresářovou strukturu, takže bez problémů z toho jednoduše vytáhnu jakýkoliv soubor z doby, kdy jsem chtěl. A zálohování je taky o dost jednodušší, protože když vytvořím páš malých souborů a udělám backup, tak se ten rozdílový snapshot odešle mnohonásobně rychleji, než rsync/bacula nebo libovolný jiný file-based zálohovací systém projde celý seznam souborů a bude zjišťovat, co se změnilo... (nehledě na fakt, že já mám na tom disku takové krásy, jako desítky GB velké disky k virtuálům, kde zase, když virtuál pustím, tak file-based systém zálohuje celý ten obří soubor; rozdílový snapshot zabere podstatně méně dat).

Vsechny svepravny zalohovace pouzivaji snapshoty, jinak se dneska pokud je to technicky mozny vubec nezalohuje. Totez obnovovani zaloh ... jestli neco vazne nechces delat pokud mozno nikdy, tak to je nejaka full scale obnova. Proc? Protoze to potrva dny, kdyz malo. Kdyz obnovis nejakej diff, je to otazka maximalne minut.

Děkuji za článek, ale bohužel mi v něm spousta věcí chybí. Kdysi jsem baculu zdědil na několika systémech, ale nepochopil jsem ji a musel ji opustit. Nemohl byste ten článek, prosím, trochu rozvést?
Například sekce storage: Jedna storage na jeden zálohovaný systém? Kam se data sypou?
Sekce job: Co to vlastně je? Každý zálohovaný stroj musí mít vlastní job?
Sekce klienta: Heslo k directoru? Ano je to hlavumotající.
Sekce bconsole: Jak se obnovuje? Kam se obnovuje? Dá se vytáhnout jeden soubor z nějaké starší verze?
Co takhle přidat ještě další fiktivní stroj, který se má zálohovat?

Je to spíše takové intro, na vaše dotazy se není problém doptat třeba ChatGPT, dělám to často také tak. Většinou konkrétní dotazy dokáže ChatGPT zodpovědět poměrně dobře.

To intro je taky od chatgpt? Nic ve zlym, ale pokud napisu nejaky clanek, vim odpovedet na dotazy ctenaru tak je preci nebudu posilat k chatgpt (nebo do prd…), to preci nedava smysl.

Já bych řekl, že to byla, v dobrém, míněná rada, jak se můžete rychleji, dobrat k hledaným informacím.

Díky za článek. Kdysi jsem přešel z Baculy na Bareos (hlavně z důvodu dynamiky vývoje). Ale jak Bareos v community verzi přestal podporovat distribuci přes binární balíčky, tak stále víc uvažuju o návratu a článek mi to připomněl.

Pořád u Baculky (pun intended) platí, že obnovit jeden soubor z obrovské zálohy = tady vidím velký špatný?

Zkoušel jsem obnovovat jednotlivé soubory a problémy jsem nezaznamenal.

to zalezi na tom, kolik je ve fullu + incrementech souboru, kdyz je jich hodne, tak si pockate nez si to vytahne z db.

Synology za cenu NAS pokryje pomoci user-friendly tools v smb segmentu win stanice, linux i hyperv/esxi (block change per vm). Proxmox backup mam v kvm na NAS, storage ma mountnuty via cifs (ze stejne NAS). ++ rsync, AD, synchronizace mezi lokalitama a offline archivace na ext USB.Toto je zbytecne slozite a neprakticke, heterogenni prostredi, rychlou obnovu per soubor ani verzovani souboru mi to imho moc efektivne neresi. Navic nez to predate novemu adminovi, bude Vas to stat spoustu casu a mozna i nejaka ta data.

Zase tak strašné to není, obnovu jednotlivých souborů i verzování to řeší, je to komplexní řešení a máte pravdu, že Synology asi bude snadnější, na druhou stranu i z hlediska nějakého Ransomware a bezpečnosti ne vždy chcete, aby zálohovací klient měl přístup ke kompletním datům záloh.
Nějaké detaily si myslím, že dobře poladíte přes ChatGPT, stačí se zeptat.

No jo 25 let stary SW. Jediny duvod proc dnes Baculu pouzivat je zaloha na pasky. Nevim o zadnem jinem SW(zdarma), ktery by umel pracovat s automatickou knihovnou.

To si úplně nemyslím, ono kvalitnější software zdarma, co něco umí, na trhu moc není. A stáří podle mě není problém, klient mi funguje pod Windows 11 a server i pod nejnovějšími verzemi Linuxu. Staré věci nejsou vždy špatné, ostatně se podívejte jak všichni nadávají na nová auta, která tu za 30 let fakt nebudou, často ani ne za 20, novější != lepší

Bacula byla dobra, ale sva nejlepsi leta ma za sebou. Jak je na tom jeji fork Bareos?

Do dnesni doby se uz nehodi. Bacula sice zalohuje (i) na filesystem, ale chova se k nemu jako k virtualni pasce. Kdo dnes zalohuje na pasky?

Kdybych dnes resil zalohovani nove aplikace/firmy/sys­temu, vezmu na to Restic backup, k tomu repository na lokalnim NAS pro rychly pristup k zaloze, k tomu S3 buckety od ruznych cloud provideru, kam budu odlevat Restic snapshoty a jsem na 99,999% safe.

21. 12. 2024, 23:50 editováno autorem komentáře

Paska je porad nejvhodnejsi medium na offlin (ev. i offsite) zalohy. Proste tu pasku vyndate, zamknete do trezoru a mate velkou jistotu v tom, ze to prezije. HDD na tohle dobry neni - konektor neni kostruovan na caste vymenovani disku, dle specifikace jen 50 cyklu... aneb ano, ssi to vydrzi vic, ale uz vam nikdo nezaruci spravnou funkci. Sporilkove tyhle detaily neresi... :-)

Skoda, ze neexistuje moznost ten disk zapojovat jinak nez pres SATA, idealne tak, aby se nemuselo hrabat do pocitace ;-(

Ale ona jiná možnost existuje, vždycky tu byly rámečky - ať už levné "desktopové" plasťáky za pár šupů, nebo profesionální "serverové" i s možností hot-swap.

Pro externí zapojení tu máme eSATA, jen si to chce pohrát s kabeláží. (A teoreticky je možnost zapojení i přes USB).

Asi začnu používat /s když nestačí, že to z toho textu kape...

Ale ani ty serverove hot-swapy nejsou stavene na to, abyste ten disk kazdy den vyndaval. Jasne, muzete... ale vlivem opotrebeni pak muzete v dusledku nasledne menit cely backplane... :-)

"Paska je porad nejvhodnejsi medium"

Coz je dalsi tvuj naprostej blabol ... pasky nikdo normalni nikde davno nepouziva, a primarni duvod je prave ten, ze je treba se o to neustale starat jak o tamagoci. Navic je to pomale a dostat se k datum z toho je horor.

Chci videt toho nekoho, kdo bude rekneme i kdyby 1x mesicne nosit neco nekam do trezoru ... a rekneme 1x rocne overovat, ze je to vazne jeste citelne ... a chci vite toho dalsiho, kdo ho za to bude platit, protoze to bude fulltime job.

Jasne, pasky se nikde nepouzivaji... a v Cernu jsou blbci, ze se neridi vasimi radami a tape storage provozuji :-)

Psal, ze nikdo normalni.

A CERN skutecne je hodne daleko od normalu.

ty virtualni pasky jsou nejvetsi slabina, problem je, ze se o ne clovek musi i starat jako o pasky a to je nejvetsi bolest, pak ma clovek bud hromadu alokovaneho mista navic, resi to rucne a nebo na to ma milion scriptu. Ve vysledku je jednodusi to cele napsat sam (a nebo radeji pouzit neco jineho).