Fórum Root.cz

Hlavní témata => Server => Téma založeno: ZAJDAN 13. 09. 2017, 17:59:01

Název: Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 13. 09. 2017, 17:59:01
není tomu dlouho co jsem zalozil tema na zalohovací pásky a diskuze se siroce rozvinula a mimo jiné byli zmineny zalohovací systemy jako Bacula, kterou jsem prave nasadil.
Rad bych zalohoval cele virtualní stroje, a chtel bych se zeptat jak to delate Vy...zda staci stroj pauznout, nebo treba primo za chodu a nebo je nutne vzdy virtualní stroj k zalohování vypnout.

díky
Název: Re:zalohování virtuálních strojů
Přispěvatel: j 13. 09. 2017, 18:08:33
Normalni veci normalne fungujou tak ze umej (za chodu) udelat snap ... kterej se pak zreplikuje jakozto zaloha, pripadne zdeduplikuje pro usporu mista.

Samo pokud na tom virtualu mas neco jako databazi, tak tam taky musis mit neco, co pri delani toho snapu zaridi, ze ta databaze bude konzistentni. Coz prozmenu ta databaze musi umet, prevazne pomoci nejakyho API. Bezne to funguje tak, ze zalohovac rekne krles, databaze dokonci transakci a pozastavi zapis, nacez ji zalohovac rekne hotovo, a databaze obnovi zapis. Databaze pak taky vi, ze byla zalohovana - prevazne nekde v logu i vidis, ze probeh fullbackup.
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 13. 09. 2017, 18:14:04
k cemu mi bude samotnej snapshot, kdyz se rozbije hlavni soubor..pak ten snapshot nepujde s cim porovnavat...ja mluvim o full zaloze
pro pripad ze dum shori a zaloha je mimo nej...tady by mi snapshot opravdu nepomohl
ja vim...reknes udelej si ten zasadni soubor jednou a jen prikopirovavej snapshoty
duvodem proc nechcu pouzivat snapshoty je ten ze nemam misto na disku, jedina cesta by byla je okamzite po zalohovani mergovat
Název: Re:zalohování virtuálních strojů
Přispěvatel: j 13. 09. 2017, 18:41:07
A cist uz si se naucil? Zjevne ne ...

Takze pro ty postizeny, snap se dela jaksi proto, ze predstavuje obraz systemu kterej se dal nemeni, coz je zakladni podminka toho, aby se cokoli dalo jakkoli zalohovat, protoze zalohu budes jaksi delat nejakou dobu, a zaloha, ve ktery si na zacaku skopiroval hlavicku faktury ... a na konci polozky, ktery vznikly behem toho, a ke kterejm ovsem nemas ty hlavicky je ti NAPROSTO KHOVNU.

Dale snap predstavuje prirozene take zmenovy data ... od predchoziho snapu, takze ti co nejsou natvrdli jako TY, vedi, ze kdyz si dneska udelam snap a prekopiruju ho nekam (= mam KOMPLETNI obraz), tak zitra nemusim kopirovat vse, ale staci mi vzit ten rozdil ... coz je prevazne maximalne nekolik jednotek % celkovy velikosti.

Mno a ti s mozkem pak jeste vedi, ze i v tech zmenovych datech se spousta veci bude objevovat stale dokola (nekdo soubor smaze, nekdo jinej ho za tyden vrati zpet) ... a proto se na cely soubor tech dat aplikuje prevazne deduplikace, protoze vazne nepotrebuju skladovat totez tisickrat, staci mi vedet, soucasti kterych snimku ta data jsou a mit je jednou.

Snap nezabere (s velmi mirnou davkou nadsazky) VUBEC NIC. Snap totiz kupodivu zacina rust az s tim, jak se meni data, takze v okamziku vytvoreni je jeho datova velikost presne NULA.

A pro velky uspech (radsi si na to nekoho najmi z ZAPLAT, protoze ses na nejlepsi ceste poslat firmu do krachu), jeste jednou. Na provoznim stroji se zavola snap (coz je otazka maximalne nekolika sekund), ten pak muzu klidne nekolik hodin kopirovat kamkoli, protoze se ... NEMENI.
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 13. 09. 2017, 19:11:59
A cist uz si se naucil? Zjevne ne ...

Takze pro ty postizeny, snap se dela jaksi proto, ze predstavuje obraz systemu kterej se dal nemeni, coz je zakladni podminka toho, aby se cokoli dalo jakkoli zalohovat, protoze zalohu budes jaksi delat nejakou dobu, a zaloha, ve ktery si na zacaku skopiroval hlavicku faktury ... a na konci polozky, ktery vznikly behem toho, a ke kterejm ovsem nemas ty hlavicky je ti NAPROSTO KHOVNU.

Dale snap predstavuje prirozene take zmenovy data ... od predchoziho snapu, takze ti co nejsou natvrdli jako TY, vedi, ze kdyz si dneska udelam snap a prekopiruju ho nekam (= mam KOMPLETNI obraz), tak zitra nemusim kopirovat vse, ale staci mi vzit ten rozdil ... coz je prevazne maximalne nekolik jednotek % celkovy velikosti.

Mno a ti s mozkem pak jeste vedi, ze i v tech zmenovych datech se spousta veci bude objevovat stale dokola (nekdo soubor smaze, nekdo jinej ho za tyden vrati zpet) ... a proto se na cely soubor tech dat aplikuje prevazne deduplikace, protoze vazne nepotrebuju skladovat totez tisickrat, staci mi vedet, soucasti kterych snimku ta data jsou a mit je jednou.

Snap nezabere (s velmi mirnou davkou nadsazky) VUBEC NIC. Snap totiz kupodivu zacina rust az s tim, jak se meni data, takze v okamziku vytvoreni je jeho datova velikost presne NULA.

A pro velky uspech (radsi si na to nekoho najmi z ZAPLAT, protoze ses na nejlepsi ceste poslat firmu do krachu), jeste jednou. Na provoznim stroji se zavola snap (coz je otazka maximalne nekolika sekund), ten pak muzu klidne nekolik hodin kopirovat kamkoli, protoze se ... NEMENI.
uklidni se...zalohy mame..nejsme firma co potrebuje fungovat v noci...script mi v noci virtuly povypina...zkopiruje je na vzdaleny disk a zase nastartuje
to ze se chci priucit/dozvedet jinym praktikam, neznamena ze me budes posilat do kouta
Název: Re:zalohování virtuálních strojů
Přispěvatel: Lol Phirae 13. 09. 2017, 19:24:18
script mi v noci virtuly povypina...zkopiruje je na vzdaleny disk a zase nastartuje

(https://media.makeameme.org/created/backup-qcto8u.jpg)
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 13. 09. 2017, 19:28:21
neverim, ze mate deti
jestli ano...a znalosti jim predavate timto zpusobem neochoty/rozhorcenosti ze nekdo nechape neco hned napoprve....chudaci
Název: Re:zalohování virtuálních strojů
Přispěvatel: Miroslav Šilhavý 13. 09. 2017, 19:30:36
není tomu dlouho co jsem zalozil tema na zalohovací pásky a diskuze se siroce rozvinula a mimo jiné byli zmineny zalohovací systemy jako Bacula, kterou jsem prave nasadil.
Rad bych zalohoval cele virtualní stroje, a chtel bych se zeptat jak to delate Vy...zda staci stroj pauznout, nebo treba primo za chodu a nebo je nutne vzdy virtualní stroj k zalohování vypnout.

díky

Veeam backup, nebo Acronis to dělají samočinně. Před zálohováním vyvolají snapshot. Poté zálohují jenom přírůstky. vSphere umí na vmdk vymezit pouze změněné bloky od předchozí zálohy, takže inkrementální přenos je překvapivě malý. Dále, Veeam umí snapshoty a přírůstky promítnout do zálohy tak, že z nich zrekonstruuje plný image v nejnovější verzi. Tedy, je připraveno k rychlému natažení ze zálohy, a není potřeba dělat žádný replay přírůstků.

Ta technologie je velmi hezká, určitě stojí za to se na ni podívat, budete překvapený.
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 13. 09. 2017, 19:47:32
Veeam backup, nebo Acronis to dělají samočinně. Před zálohováním vyvolají snapshot. Poté zálohují jenom přírůstky. vSphere umí na vmdk vymezit pouze změněné bloky od předchozí zálohy, takže inkrementální přenos je překvapivě malý. Dále, Veeam umí snapshoty a přírůstky promítnout do zálohy tak, že z nich zrekonstruuje plný image v nejnovější verzi. Tedy, je připraveno k rychlému natažení ze zálohy, a není potřeba dělat žádný replay přírůstků.
Ta technologie je velmi hezká, určitě stojí za to se na ni podívat, budete překvapený.
díky za tip
v tuto chvíly placený SW nepřipadá v úvahu, kdyz už tedy, tak mě ta partyzanstina něco přiučí
chápu tedy dobře, že tento scénař by měl fungovat?
a) primární virtualní stroj ve stavu OFF zkopíruji na založní místo (pouze jednou)
b) zítra na běžícím virtuálu udělám snapshot a ten zkopíruji na záložní místo vedle toho primáru
c) na běžícím virtuálu snapshot smažu/merge
 
bod b/c bych prováděl třeba každý den, ale vrtá mi hlavou, že každý nový snapshot, nebude pasovat proti výchozímu primárnímu...
pomůžete mi to objasnit?
díky
Název: Re:zalohování virtuálních strojů
Přispěvatel: Miroslav Šilhavý 13. 09. 2017, 19:52:18
Veeam backup, nebo Acronis to dělají samočinně. Před zálohováním vyvolají snapshot. Poté zálohují jenom přírůstky. vSphere umí na vmdk vymezit pouze změněné bloky od předchozí zálohy, takže inkrementální přenos je překvapivě malý. Dále, Veeam umí snapshoty a přírůstky promítnout do zálohy tak, že z nich zrekonstruuje plný image v nejnovější verzi. Tedy, je připraveno k rychlému natažení ze zálohy, a není potřeba dělat žádný replay přírůstků.
Ta technologie je velmi hezká, určitě stojí za to se na ni podívat, budete překvapený.
díky za tip
v tuto chvíly placený SW nepřipadá v úvahu, kdyz už tedy, tak mě ta partyzanstina něco přiučí
chápu tedy dobře, že tento scénař by měl fungovat?
a) primární virtualní stroj ve stavu OFF zkopíruji na založní místo (pouze jednou)
b) zítra na běžícím virtuálu udělám snapshot a ten zkopíruji na záložní místo vedle toho primáru
c) na běžícím virtuálu snapshot smažu/merge
 
bod b/c bych prováděl třeba každý den, ale vrtá mi hlavou, že každý nový snapshot, nebude pasovat proti výchozímu primárnímu...
pomůžete mi to objasnit?
díky

To byste nesměl mergovat předchozí snapshoty. Funkční scénář by mohl být: za chodu udělám v pondělí snapshot 1, ten zazálohuji. Úterý-pátek dělám další snapshoty, které zálohuji. V pondělí provedu merge všech snapshotů z minulého týdne, udělám jeden nový, a ten zase zazálohuji jako plnou zálohu.

Samozřejmě, jde to i v off stavu, jen je to bolestivější :).
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 13. 09. 2017, 19:55:58
To byste nesměl mergovat předchozí snapshoty. Funkční scénář by mohl být: za chodu udělám v pondělí snapshot 1, ten zazálohuji. Úterý-pátek dělám další snapshoty, které zálohuji. V pondělí provedu merge všech snapshotů z minulého týdne, udělám jeden nový, a ten zase zazálohuji jako plnou zálohu.
Samozřejmě, jde to i v off stavu, jen je to bolestivější :).
no a to je ten problem...vzhledem k tomu ze nemam misto na disku a uz jednou se me skarede potrapilo tak, ze jsem nedokazal udelat merge kvuli nedostatku mista na disku, nechci jiz neco podobneho zazit...proto delat snapshoty s tak dlouhym odstupem je prozatim nemozne

moc dekuji za ochotu to objasnit
Název: Re:zalohování virtuálních strojů
Přispěvatel: Miroslav Šilhavý 13. 09. 2017, 20:06:47
no a to je ten problem...vzhledem k tomu ze nemam misto na disku a uz jednou se me skarede potrapilo tak, ze jsem nedokazal udelat merge kvuli nedostatku mista na disku, nechci jiz neco podobneho zazit...proto delat snapshoty s tak dlouhym odstupem je prozatim nemozne

Rozumím, u virtualizace a u snapshotů je potřeba mít opravdu rezervy, a ideálně i monitoring. Teprve, když si pro to vytvoříte podmínky, můžete využít tyto vychytávky. Pokud nemáte dost rezerv na datastoru s VM, pak dělejte jen snapshot => plná záloha => merge. A to každý den. Zase budete potřebovat hodně místa na zálohy.

Samozřejmě, vždycky Vám zůstává možnost zálohovat agentem, po souborech. Výhody, nevýhody i cenu jednotlivých řešení znáte, dál už je to jen o výběru cesty.
Název: Re:zalohování virtuálních strojů
Přispěvatel: Miroslav Šilhavý 13. 09. 2017, 20:07:13
no a to je ten problem...vzhledem k tomu ze nemam misto na disku a uz jednou se me skarede potrapilo tak, ze jsem nedokazal udelat merge kvuli nedostatku mista na disku, nechci jiz neco podobneho zazit...proto delat snapshoty s tak dlouhym odstupem je prozatim nemozne

Rozumím, u virtualizace a u snapshotů je potřeba mít opravdu rezervy, a ideálně i monitoring. Teprve, když si pro to vytvoříte podmínky, můžete využít tyto vychytávky. Pokud nemáte dost rezerv na datastoru s VM, pak dělejte jen snapshot => plná záloha => merge. A to každý den. Zase budete potřebovat hodně místa na zálohy.

Samozřejmě, vždycky Vám zůstává možnost zálohovat agentem, po souborech. Výhody, nevýhody i cenu jednotlivých řešení znáte, dál už je to jen o výběru cesty.
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 13. 09. 2017, 20:18:13
Teprve, když si pro to vytvoříte podmínky, můžete využít tyto vychytávky.
ALFA-OMEGA vsech techto vychytavek....kloudné podmínky nemám, zbývají partyzánské metody :_)

jeste jednou díky
Název: Re:zalohování virtuálních strojů
Přispěvatel: Kit 13. 09. 2017, 20:59:16
Dale snap predstavuje prirozene take zmenovy data ... od predchoziho snapu, takze ti co nejsou natvrdli jako TY, vedi, ze kdyz si dneska udelam snap a prekopiruju ho nekam (= mam KOMPLETNI obraz), tak zitra nemusim kopirovat vse, ale staci mi vzit ten rozdil ... coz je prevazne maximalne nekolik jednotek % celkovy velikosti.

Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.
Název: Re:zalohování virtuálních strojů
Přispěvatel: Miroslav Šilhavý 13. 09. 2017, 21:09:16
Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.

VMWare od toho má funkci Quiesce, která přes vmware tools vyžádá zápis filesystému do konzistentního stavu.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180
Název: Re:zalohování virtuálních strojů
Přispěvatel: Kit 13. 09. 2017, 21:51:39
Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.

VMWare od toho má funkci Quiesce, která přes vmware tools vyžádá zápis filesystému do konzistentního stavu.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180

Takže když v aplikaci otevřu soubor pro zápis, zkrátím na 0, začnu zapisovat záznam po záznamu a mezi 3.-4. záznamem přijde požadavek na snapshot, tak v tom souboru bude co? Budu mít v tom snapshotu půlku např. zdrojáku, příp. při "uložit vše" budou 3 zdrojáky staré a 4 nové? Jedná se stále o konzistentní stav?
Název: Re:zalohování virtuálních strojů
Přispěvatel: Miroslav Šilhavý 13. 09. 2017, 22:21:50
Takže když v aplikaci otevřu soubor pro zápis, zkrátím na 0, začnu zapisovat záznam po záznamu a mezi 3.-4. záznamem přijde požadavek na snapshot, tak v tom souboru bude co? Budu mít v tom snapshotu půlku např. zdrojáku, příp. při "uložit vše" budou 3 zdrojáky staré a 4 nové? Jedná se stále o konzistentní stav?

Situaci, kterou popisujete, nevyřeší žádné opatření. Když pustíte archivaci, může proběhnout ve stejně nevhodný okamžik. Backup pomocí agenta taky. Backup VM taky. Když uděláte shutdown, abyste udělal snapshot za studena, tak i shutdown se může strefit do stejného okamžiku.

VSS + quiesce posouvá spolehlivost o kus dál, byť ne na 100 %.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Karel 14. 09. 2017, 03:27:04
Rozsirim tema zalohy virtulaek. Pod KVM virtualizaci planujeme pouzit https://www.bareos.org/ na zalohy
1.)virtualek
2.)obsahu virtualek zejmena:
2.1.)Postgre SQL
2.2.)My/MariaDB
2.3.)Staticka data

Mate nekdo zkusenosti s nasazem a ostrym provozem?  Ted implementujeme do produkce tak se nam zpetna vazba hodi.

BareOs by mel byt novy/lepsi fork bacula.org
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Miroslav Šilhavý 14. 09. 2017, 05:22:29
Rozsirim tema zalohy virtulaek. Pod KVM virtualizaci planujeme pouzit https://www.bareos.org/ na zalohy
1.)virtualek
2.)obsahu virtualek zejmena:
2.1.)Postgre SQL
2.2.)My/MariaDB
2.3.)Staticka data

Používám Bareos.
Ad 1) nemám zkušenost, ale nevidím v tom sílu bareosu.
Ad 2.1) bez problému, fs zálohuju s vyloučením datového adresáře PG, v nezávislém jobu mám script na dump po jednotlivých databázích (pro obnovu je to lepší, než pgdumpall); lze nastavit zálohování base+wal, bylo by to asi i lepší, ale u toho bych považoval za nutné naplánovat pravidelné testy obnovitelnosti, a to se mi nechtělo.
Ad 2.2) obdobně, script, který ve smyčce dumpuje databázi po databázi.
Ad 2.3) bez problémů, jen pokud chcete zálohovat i extended attributes, hlásí čas od času warningy.

Dobrou zkušenost mám s tím, že bareos provede zálohu rychle, efektivně, a při použití jeho interní lzo komprese, tak i s malým objemem dat.

Pak mám speciální případy, např. stroj, kde je několik TB fotek, a kde zákazník nemá požadavek na archivaci stavu X dní, stačí mu poslední záloha (archiv má u sebe), tam mám v jobu nastavený na dané adresáře rsync. Rsync pak dělám na ZFS s nastavenou deduplikací, protože některé fotky se opakují (dosahuji efektivity uložení 1:1,2) Takže job nejprve spustí rsync, a po něm udělá klasicky zálohu zbytku OS.

Jako slabiny vidím menší stabilitu bareosu, chybějící deduplikaci (dedup by base jobs mi moc nepomáhá), složité nastavování retence dat, a aktuálně má bug při restore, pokud máte datasety nastavené do různých adresářů (pokud je máte v jednom, je to bez problémů).

Retence dat se dá nastavit přes datasety, ale je potřeba přemýšlet o tom, jak velký bude jednotlivý soubor vs. retence dat v něm. Dá se očekávat, že na full zálohách budete potřebovat delší retenci, na inkrementech kratší. Pokud oba druhy zálohy skončí ve stejném datasetu, tak nemá možnost se uvolnit a de facto bude data držet tak dlouhou dobu, dokud nevyexspiruje i full.

Dost nepohodlné je konfigurování plánovače. Pokud máte víc strojů k zálohování, budete patrně chtít, aby full zálohy neběžely ve stejný den, ale rozložily se. Pak musíte na každý job nadefinovat i vlastní schedule, ale konfigurace není moc čitelná, takže si musíte vést evidenci bokem, třeba v excelu.

Nižsí stabilita bareosu se někdy projevuje v nekonzistentním stavu jeho databáze - není to žádná tragedie, ale když zrovna potřebujete obnovit soubor, a musíte začít řešit i toto, je to ke vzteku.

Za slabinu považuji to, že po rekonfiguraci neexistuje vždy možnost reloadu, aniž by spadly běžící joby. Opět, dá se s tím žít, ale pokud to uděláte uprostřed full zálohy, ta bude muset proběhnout znovu, ale data v datasetu už jsou, a budou čekat na exspiraci (také nedořešený stav).

Stačí popis takto?
Název: Re:zalohování virtuálních strojů
Přispěvatel: j 14. 09. 2017, 08:19:32
Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.
A dalsi kterej neumi cist ... databaze exportem ... jo to vizejo ... to bude urcite konzitentni ... treba takovy mysql ze? Ktery zalohovat neumi prosychr vubec nijak ... lol.

Filesystem je konzistejneni zcela vzdy, a to zpohledu filesystemu, protoze to je (ne)prekvapive ucel toho snapu. Ze sis zrovna neulozil otevrenej soubor, to je tvuj problem. A jak bylo receno, kdyz ti vypnu elektriku, tak si taky ulozis kulovy.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: MP 14. 09. 2017, 10:15:54
Rozsirim tema zalohy virtulaek. Pod KVM virtualizaci planujeme pouzit https://www.bareos.org/ na zalohy
1.)virtualek
2.)obsahu virtualek zejmena:
2.1.)Postgre SQL
2.2.)My/MariaDB
2.3.)Staticka data

Používám Bareos.
Ad 1) nemám zkušenost, ale nevidím v tom sílu bareosu.
Ad 2.1) bez problému, fs zálohuju s vyloučením datového adresáře PG, v nezávislém jobu mám script na dump po jednotlivých databázích (pro obnovu je to lepší, než pgdumpall); lze nastavit zálohování base+wal, bylo by to asi i lepší, ale u toho bych považoval za nutné naplánovat pravidelné testy obnovitelnosti, a to se mi nechtělo.
Ad 2.2) obdobně, script, který ve smyčce dumpuje databázi po databázi.
Ad 2.3) bez problémů, jen pokud chcete zálohovat i extended attributes, hlásí čas od času warningy.

Dobrou zkušenost mám s tím, že bareos provede zálohu rychle, efektivně, a při použití jeho interní lzo komprese, tak i s malým objemem dat.

Pak mám speciální případy, např. stroj, kde je několik TB fotek, a kde zákazník nemá požadavek na archivaci stavu X dní, stačí mu poslední záloha (archiv má u sebe), tam mám v jobu nastavený na dané adresáře rsync. Rsync pak dělám na ZFS s nastavenou deduplikací, protože některé fotky se opakují (dosahuji efektivity uložení 1:1,2) Takže job nejprve spustí rsync, a po něm udělá klasicky zálohu zbytku OS.

Jako slabiny vidím menší stabilitu bareosu, chybějící deduplikaci (dedup by base jobs mi moc nepomáhá), složité nastavování retence dat, a aktuálně má bug při restore, pokud máte datasety nastavené do různých adresářů (pokud je máte v jednom, je to bez problémů).

Retence dat se dá nastavit přes datasety, ale je potřeba přemýšlet o tom, jak velký bude jednotlivý soubor vs. retence dat v něm. Dá se očekávat, že na full zálohách budete potřebovat delší retenci, na inkrementech kratší. Pokud oba druhy zálohy skončí ve stejném datasetu, tak nemá možnost se uvolnit a de facto bude data držet tak dlouhou dobu, dokud nevyexspiruje i full.

Dost nepohodlné je konfigurování plánovače. Pokud máte víc strojů k zálohování, budete patrně chtít, aby full zálohy neběžely ve stejný den, ale rozložily se. Pak musíte na každý job nadefinovat i vlastní schedule, ale konfigurace není moc čitelná, takže si musíte vést evidenci bokem, třeba v excelu.

Nižsí stabilita bareosu se někdy projevuje v nekonzistentním stavu jeho databáze - není to žádná tragedie, ale když zrovna potřebujete obnovit soubor, a musíte začít řešit i toto, je to ke vzteku.

Za slabinu považuji to, že po rekonfiguraci neexistuje vždy možnost reloadu, aniž by spadly běžící joby. Opět, dá se s tím žít, ale pokud to uděláte uprostřed full zálohy, ta bude muset proběhnout znovu, ale data v datasetu už jsou, a budou čekat na exspiraci (také nedořešený stav).

Stačí popis takto?

Zajimave. Ja jsem dump postgre pres jednotlive databaze zrusil, protoze to pak vyzaduje i dumpovat uzivatele extra atd...Takze to pouzivam jen vyjimecne. Za zaklad povazuji zalohovani pres WAL, ale je to zrout mista, takze to nelze bez extra nastroju drzet takovou dobu, jako kompresovane dumpy - ale ty jsou pouze nouzova zaloha.

Vylouceni PGDATA z filebackupu povazuji za zaklad, to same pro kazdou DB.

S tou nedostatecnou deduplikaci souhlasim, ale zase se da udelat Always Incremental, k cemuz se snad taky nejak dostanu casem. Na deduplikace je asi lepsi borg, ale ten nema pull system :/ Co se tyce full zaloh, ja naopak delam fullky ve stejny den, nebot je to lepe prehledne, ke kteremu dni vlastne mame ktere zalohy dle retence. Samozrejme, s Always Incremental se tohle velmi zmeni.

S tou lzo kompresi, predpokladam, ze to vyzaduje LZO na klientech. Je mi milejsi, kdyz se o kompresi stara zalohovaci server, nez client, ale zatim co jsem videl, tak uspesnost komprese mi pripada lepsi na strane klienta, ale mozna se pletu, exaktne to zmerene nemam.

Director jde jeste reloadovat pres init.d, pres systemd moznost reloadu v unite neni, ze zahadnych duvodu.

Kdybych podporoval Veeam mou virtualizaci a mel bych moznost to zaplatit, tak bych nevahal, umi to neskutecne veci z hlediska DR.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Martin 14. 09. 2017, 10:29:11
Dobrý den, sice jste říkal, že jakékoliv placené řešení je pro Vás tabu, ale zkoušel jste Altaro VM Backup? Je to velmi kvalitní řešení a nestojí světy, jako takový Veeam. Také má free verzi, ale ta je notně omezena, nicméně své i udělá.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Miroslav Šilhavý 14. 09. 2017, 10:32:01
Zajimave. Ja jsem dump postgre pres jednotlive databaze zrusil, protoze to pak vyzaduje i dumpovat uzivatele extra atd...Takze to pouzivam jen vyjimecne. Za zaklad povazuji zalohovani pres WAL, ale je to zrout mista, takze to nelze bez extra nastroju drzet takovou dobu, jako kompresovane dumpy - ale ty jsou pouze nouzova zaloha.

Na to je jednoduchý script, který zazálohuje i globaldata:
for I in `/usr/bin/psql -d template1 -q -t -c "SELECT datname FROM pg_database WHERE datname NOT IN ('template0') ORDER BY datname;"`; do
        /usr/bin/pg_dump -F t ${I} | /usr/bin/lzop -1 > ${TEMPDIR}/${DATE}${I}.tar.lzo
done


S tou nedostatecnou deduplikaci souhlasim, ale zase se da udelat Always Incremental, k cemuz se snad taky nejak dostanu casem.

To ano, ale stejně musíte dělat full zálohy, mít dlouhý řetěz inkrementů není bezpečné.

S tou lzo kompresi, predpokladam, ze to vyzaduje LZO na klientech. Je mi milejsi, kdyz se o kompresi stara zalohovaci server, nez client, ale zatim co jsem videl, tak uspesnost komprese mi pripada lepsi na strane klienta, ale mozna se pletu, exaktne to zmerene nemam.

Bareos umí obojí, ale vycházím z toho, že úzké hrdlo je CPU bareosu a síť. Naopak na hypervizorech mám přebytek CPU. Proto LZO na straně klienta vychází lépe.

Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: MP 14. 09. 2017, 10:53:54
Zajimave. Ja jsem dump postgre pres jednotlive databaze zrusil, protoze to pak vyzaduje i dumpovat uzivatele extra atd...Takze to pouzivam jen vyjimecne. Za zaklad povazuji zalohovani pres WAL, ale je to zrout mista, takze to nelze bez extra nastroju drzet takovou dobu, jako kompresovane dumpy - ale ty jsou pouze nouzova zaloha.

Na to je jednoduchý script, který zazálohuje i globaldata:
for I in `/usr/bin/psql -d template1 -q -t -c "SELECT datname FROM pg_database WHERE datname NOT IN ('template0') ORDER BY datname;"`; do
        /usr/bin/pg_dump -F t ${I} | /usr/bin/lzop -1 > ${TEMPDIR}/${DATE}${I}.tar.lzo
done


S tou nedostatecnou deduplikaci souhlasim, ale zase se da udelat Always Incremental, k cemuz se snad taky nejak dostanu casem.

To ano, ale stejně musíte dělat full zálohy, mít dlouhý řetěz inkrementů není bezpečné.

S tou lzo kompresi, predpokladam, ze to vyzaduje LZO na klientech. Je mi milejsi, kdyz se o kompresi stara zalohovaci server, nez client, ale zatim co jsem videl, tak uspesnost komprese mi pripada lepsi na strane klienta, ale mozna se pletu, exaktne to zmerene nemam.

Bareos umí obojí, ale vycházím z toho, že úzké hrdlo je CPU bareosu a síť. Naopak na hypervizorech mám přebytek CPU. Proto LZO na straně klienta vychází lépe.

U Always Inceremental se dela Full pouze jednou na zacatku. Pak se jiz pouze incrementy do te Full merguji.

Na hypervizorech je mozna prebytek CPU, ale prebytek CPU nemusi byt v klientech, zatimco backup masina neresi nic jineho nez backup...U mne rozhodne teda ted plati, ze na hypervizorech je nedostatek CPU, ale backup masina se nudi vetsinu casu.

Jeste k tem virtualizovanym DB - tam se to trosku komplikuje. Pokud se udela zaloha VM pres hypervizor, tak ten vetsinou neumi vyloucit adresare uvnitr VM. Takze datovy disk treba pro postgre to resi. Jenze zase...pokud dam jako PGHOME oddeleny disk, ktery se nezalohuje pres hypervizor, tak ten PGHOME obsahuje i ssh/config soubory :/ Coz pak znamena explicitne urcit dane adresare/soubory do filebackup systemu...Proste mismas.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Miroslav Šilhavý 14. 09. 2017, 11:15:19
Jeste k tem virtualizovanym DB - tam se to trosku komplikuje. Pokud se udela zaloha VM pres hypervizor, tak ten vetsinou neumi vyloucit adresare uvnitr VM. Takze datovy disk treba pro postgre to resi. Jenze zase...pokud dam jako PGHOME oddeleny disk, ktery se nezalohuje pres hypervizor, tak ten PGHOME obsahuje i ssh/config soubory :/ Coz pak znamena explicitne urcit dane adresare/soubory do filebackup systemu...Proste mismas.

Proboha, PostgreSQL je Postgres, ne Postgre :( (První jméno bylo Postgres 95).
Pokud se zálohuje VM, tak tam stačí quiesce a maximálně přijdete o poslední segment WAL.
Zálohovat uživatelský ~/.ssh/ mi nepřijde jako žádné riziko, k zálohám se stejně nesmí dostat nikdo nepovolaný.

U mne rozhodne teda ted plati, ze na hypervizorech je nedostatek CPU, ale backup masina se nudi vetsinu casu.

Pokud se dívám do statistik, a LZO mi šetří cca 70 % přenosu, tak raději odlevím switchi. Taky se mi lépe monitoruje zdroj problémů, vyskočí mi to na konkrétním VM. To je ale opravdu věc koncepce, software podporuje obě možnosti, právě proto.

Chápu vše, co mi říkáte, ale nějak nerozumím Vašim tezím.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 14. 09. 2017, 14:24:02
Snapshoty jsou opravdu nejrozumější řešení v případě, kdy je dostatek volného místa
Jak jsem již zmínil, v minulosti mě Snapshot drsně potrestal po spustění 'merge', kdy nebylo místo na disku...rozdíl narůstal a nakonec se virtual úplně zastavil, pač to nemělo kam růst.
Dá se nějak spočítat, existuje nějaký definovaný poměr Snapshot/CurentStatus vs volné místo na disku, tak aby byla jistota, že půjde použít merge?

díky
Název: Re:zalohování virtuálních strojů
Přispěvatel: kojot4 14. 09. 2017, 19:03:08
Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.

Tohle je totální hlod, kde na to ty lidi tady na rootu chodí. Nekonzistentní rozpracované transakce databáze na disku, no to mě poser  ;D Transakce je právě o tom, že je vždy konzistentní, to je pokud v průběhu transakce lehne databáze, lehne systém, udělá se snapshot, tak transakce tak či onak vždy proběhne celá nebo vůbec, rozhodně se u transakce v případě zastavení, či pádu systému nestane to, že by proběhla půlka transakce.

Tady se člověk doví hlodů. By mě zajímalo, k čemu by pak transakce byly, kdyby nebyly konzistentní  ::)

A hlavně, databáze ke snapshotům přímo vybízí, většina databází je navržena tak, aby počítala s pády systému nebo databázového serveru. Například MS SQL má dokonce oficiální doporučené zálohování přes snapshoty (shadow copy).

Snapshoty jsou právě hodně efektivní řešení, protože jejich integrita je na úrovni, že obnova ze zálohy se = stavu při pádu/zaseknutí systému. Pokud nějaká aplikace/databáze neustojí pád systému vzhledem k integritě dat, tak je taková aplikace velmi špatně udělaná.

Problém snapshotů je jinde, a to je poměrně komplikované obnovování jednotlivých souborů. Naopak výhoda snapshotů je poměrně v jednoduchém obnovení celého systému, včetně zavaděčů atd. Ideální je oba přístupy kombinovat, to je dělat snapshoty, i klasické zálohy po jednotlivých souborech.

Jinak pro virtualizaci na linuxu se dost používá KVM, a hodně chytré je použít jako disk virtuálky Logical Volume, u které lze poměrně jednoduše udělat snapshot, a virtuálku pak není třeba vypínat.
Název: Re:zalohování virtuálních strojů
Přispěvatel: kojot4 14. 09. 2017, 19:06:34
Teprve, když si pro to vytvoříte podmínky, můžete využít tyto vychytávky.
ALFA-OMEGA vsech techto vychytavek....kloudné podmínky nemám, zbývají partyzánské metody :_)

jeste jednou díky

V takových podmínkách připojuji k serverům USB disky, je to poměrně levné, efektivní a funkční rozšíření kapacity disků na serveru, dost se to v poslední době používá. Mírná nevýhoda je, že se občas (ale je to spíše vyjímečné) USB disky zaseknou, takže na nic moc jiného, než zálohy se to nehodí.
Název: Re:zalohování virtuálních strojů
Přispěvatel: Kit 14. 09. 2017, 20:40:24
Místo rozčilování je nutné si uvědomit, že snapshoty vůbec nemusí představovat konzistentní stav systému. Pokud udělám snapshot v průběhu zápisu do souboru, tak asi moc konzistentní nebude. S databázemi je to ještě horší kvůli rozpracovaným transakcím - proto je lepší zálohovat databáze exportem, při kterém vůbec nevadí, že se mezitím data modifikují.

Tohle je totální hlod, kde na to ty lidi tady na rootu chodí. Nekonzistentní rozpracované transakce databáze na disku, no to mě poser  ;D

K službám, v tomhle ti rád vyhovím.
Název: Re:zalohování virtuálních strojů
Přispěvatel: Jenda 14. 09. 2017, 20:58:56
script mi v noci virtuly povypina...zkopiruje je na vzdaleny disk a zase nastartuje
(https://jenda.hrach.eu/f/dbfail.JPG)
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Dan 14. 09. 2017, 21:18:56
Se snapshoty to má více úskalí. Jak u VmWare tak u hyperV dochazí ke krátkému "pause" virtuálního stroje nebo disk IO operace se protahují na mnoho vteřin. Záleží co na těch virtuálech běží, normálně napsanému software by to nemělo vadit ale třeba průmyslové aplikaci využívající OPC komunikaci, nebo taková softwarová "perla" jako siemens simaticIT jsou na to  docela citlivé a často v důsledku backupu VM padaly.
Název: Re:zalohování virtuálních strojů
Přispěvatel: j 14. 09. 2017, 21:36:57
Problém snapshotů je jinde, a to je poměrně komplikované obnovování jednotlivých souborů. ...
Nikolivek, to je naopak naprosto primitivne trivialni ... protoze si proste zcela kamkoli mountnu zcela libovolnej snap ze zalohovace (klido RW), a jednoduse si z nej vykopiruju trebas jeden kilovej soubor. Co vic, klidne muzu udelat to, ze kdyz mi chcipne primarni uloziste komplet, tak proste primontuju posledni snap a pustim vse primo z HW na kterym sou zalohy.

... dochazí ke krátkému "pause" ...
A dalsi totalni blabol, nic takovyho se pri delani snapu vubec nedeje a to zcela nikde a nikdy. K vypadku stroje (velice kratkymu) muze dojit leda za situace, kdy pojde HW na kterym bezi a (oklesteny)HAcko ho presouva na jinej HW. Neoklesteny HAcko ma na vmware pozadavek na 6Gbit per virtual vzajemny konetivity, v takovym pripade je vypadek presne NULA.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Cek 15. 09. 2017, 11:15:49
Musim vyjmecne souhlasit s J, ze pri vytvareni snapshotu k prodleve, minimalne na VMWare, nedochazi. Horsi je to pri zapracovavani snapshotu zpatky, tam k prodleve dojit muze (a dochazi), minimalne IO operace tim v tu chvili trpej....
Název: Re:zalohování virtuálních strojů
Přispěvatel: ZAJDAN 15. 09. 2017, 11:29:19
script mi v noci virtuly povypina...zkopiruje je na vzdaleny disk a zase nastartuje
(https://jenda.hrach.eu/f/dbfail.JPG)
u nas v noci jsou dvere zavrene a dokonce je to pozadovano
Název: Re:zalohování virtuálních strojů
Přispěvatel: Lol Phirae 15. 09. 2017, 11:32:44
...

Tak ten byl dobrej. Přepošli to hasičům s adresou, to je potěší.  ;D ;D ;D
Název: Re:zalohování virtuálních strojů
Přispěvatel: Lol Phirae 15. 09. 2017, 11:33:43
u nas v noci jsou dvere zavrene a dokonce je to pozadovano

Krom toho, že bys asi měl začít žrát maso, chápeš rozdíl mezi stavem "zavřeno" a "nelze otevřít"?  ::)
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: chmatos 15. 09. 2017, 12:00:53
Ahoj,

virtuály na VirtualBoxu mám na lvm a stačí tedy jen vytvořit snapshot lvm a odkopírovat data. S virtuálem není třeba nic provádět a záloha je konzistentní zkoušeno i na strojích s databází.

Zálohový server si zavolá ze serveru, kde běží virtuály tento skript.

lvcreate -s -L 100G -n snap_home /dev/vg0/lvhome
mount -o ro /dev/vg0/snap_home /mnt/backup_virtuals/
perl /root/backup_virtuals.pl #Ten perl si podle krytérií volá rsync a sype to na zálohový server, odkuz se ten skript zavolal.
umount /mnt/backup_virtuals
lvremove -f /dev/vg0/snap_home

Na zálohovém serveru už je btrfs a vytvoří se snapshot přes btrbk. Tam snapshoty fungují jinak, je to kůli místu. Mám 5 kompletních obrazů virtuálů a zabírá to jen necelý dvojnásobek jedné kompletní zálohy.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 12:05:38
Na zálohovém serveru už je btrfs a vytvoří se snapshot přes btrbk. Tam snapshoty fungují jinak, je to kůli místu. Mám 5 kompletních obrazů virtuálů a zabírá to jen necelý dvojnásobek jedné kompletní zálohy.

diky za tip...
drzis nekde i zalohu celeho LVM pro pripad ze by padl?
ja chci tu zalohu delat tak abych to kdykoliv mohl drapnout a rozjet na jinem zeleze a samotny snapshot mi v tom nepomuze
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Cek 15. 09. 2017, 12:35:49
Na zálohovém serveru už je btrfs a vytvoří se snapshot přes btrbk. Tam snapshoty fungují jinak, je to kůli místu. Mám 5 kompletních obrazů virtuálů a zabírá to jen necelý dvojnásobek jedné kompletní zálohy.

diky za tip...
drzis nekde i zalohu celeho LVM pro pripad ze by padl?
ja chci tu zalohu delat tak abych to kdykoliv mohl drapnout a rozjet na jinem zeleze a samotny snapshot mi v tom nepomuze

Mi to porad pripada, ze michas dohromady 2 veci.
Snapshot jako neco, co Ti da konzistentni stav, a snapshot jako neco, co chces odlejt.

Kdyz udelas snapshot virtualni masiny, muzes v tu chvili udelat full/diff backup celeho stroje, podle sve libosti, ktery bude co se tyce souboroveho systemu konzistentni. Jde o to, ze ta zaloha se dela z toho freeze stavu, i kdyz server dal jede a do zmenovych souboru si uklada co se mezitim deje, a po ukonceni zalohy zapracuje zpatky zmeny, ktere mezitim probehly (smaze ten snapshot).

Takze kdyz udelas full backup, muzes ji drapnout uplne bez problemu a pustit jinde nebo treba z okna :)
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: chmatos 15. 09. 2017, 12:49:14

diky za tip...
drzis nekde i zalohu celeho LVM pro pripad ze by padl?
ja chci tu zalohu delat tak abych to kdykoliv mohl drapnout a rozjet na jinem zeleze a samotny snapshot mi v tom nepomuze
[/quote]

No to LVM nepadne já jen vytvořím snapshot zkopíruji kompletní VM. Snapshot je jen, aby byl konzistetní stav. Pak smažu snapshot a mám odlitej kompletní VM. Lze to použít i na klonování. Prostě máš celej virtuál, jen si pak myslí, že jsi ho natvrdo vypnul a má i čas zálohy, než si to srovná. Předpokládám, že to je to co chceš. Snapshoty na btrfs taky nepadaj to jen na tom lvm, ale tam je jen pro tu kopii, pak hned snapshot maže rovnou skript.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 13:10:19
diky hoši....
takže snapshotnu běžící virtual(aplikačně) a nebo(LVM), zkopiruji/rsyncuju si ten full(zmrazenej) nekde na zalohu, tak nebude vadit, ze kdyz to nahodim na jinem zeleze, ze budu vlastne spoustet virtualni stroj ktery je ve stavu run?
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 13:36:15
ted mi bylo konecne objasneno jak funguje snapshot LVM....celou dobu me matlo ze preci snapshot velikosti 2GB je preci k nicemu...jenze po namountovani LVM snapshotu kernel zaridi ze vidim celych 100GB a ty si vykopiruji/zalohuji
dekuji trpelivym
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 14:08:02
sleep vm, snapshotLVM, resume vm, mount LVMsnapshot, rsync LVMsnapshot, umount LVMsnapshot, destroy LVMsnapshot
i kdyz ma snapshot LVM 2GB tak po namountovani jde videt full obsah, což zařídí kernel, který ví ke kterému LVM ten snapshot patří.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 14:08:55
proto mi to neslo do hlavy, ze kopirujete ty "malicke" snapshoty :_)
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Rhinox 15. 09. 2017, 14:44:22
Zaloha beziciho stroje je snapshot filesystemu? No co se tady jeden clovek nedovi...
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: chmatos 15. 09. 2017, 19:09:45
Zaloha beziciho stroje je snapshot filesystemu? No co se tady jeden clovek nedovi...

Snapshot filesystemu zaridi jen konzistenci dat, aby jsi ten virtual nemusel vypinat. Samozrejme jen po dobu co pobezi kopirovani.

1. Snapshot nebo vypnuti virtualu
2. Rsync kompletniho virtualu
3. Smazani snapshotu, nebo spusteni virtualu

Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Jenda 15. 09. 2017, 19:23:41
sleep vm, snapshotLVM, resume vm
K čemu je tam ten sleep a resume?
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 19:38:05
sleep vm, snapshotLVM, resume vm
K čemu je tam ten sleep a resume?
kdesi jsem se docetl, ze PAUSE flushne cache, melo by se tim zaridit ze pokud se ten virtual rozbehne na jinem zeleze, bude to vypadat jako po rebootu, ale klidne se necham počit znalejším odborníkem
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: citanus006 15. 09. 2017, 19:42:51
Musim vyjmecne souhlasit s J, ze pri vytvareni snapshotu k prodleve, minimalne na VMWare, nedochazi. Horsi je to pri zapracovavani snapshotu zpatky, tam k prodleve dojit muze (a dochazi), minimalne IO operace tim v tu chvili trpej....

pokud chcete mit obnovitelnou zalohu, tak u snapshotu zapnete Quiesce, ktery znamena ze vmware pres vmtools zaridi flush dat nadisk. Sice to nepauzne virtualku, ale rozhodne to pozastavuje bezici procesy.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180

Laskave tady neplacejte blbosti.
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: ZAJDAN 15. 09. 2017, 19:59:05
pokud chcete mit obnovitelnou zalohu, tak u snapshotu zapnete Quiesce, ktery znamena ze vmware pres vmtools zaridi flush dat nadisk. Sice to nepauzne virtualku, ale rozhodne to pozastavuje bezici procesy.

https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1015180

Laskave tady neplacejte blbosti.
pokud to dobre chapu, tak Oracle na to ma:
Save the machine state: The virtual machine will be "frozen" and VirtualBox entirely saves its state to the user's local disk. The virtual machine will resume in the same position that you left in when you start it again. The user's computer will resume operation and the programs will still be available.

rozdil mezi PAUSE and SAVE STATE bude asi takto:
“You can also pause or save a virtual machine in a given state. When you pause or save a virtual machine, it stays in its current state for as long as you want.
Although pausing a virtual machine does not free up the memory that is allocated to that virtual machine, it frees up main processor resources. Saving a virtual machine frees up memory and main processor resources so that they can be used by other virtual machines or by the virtualization server.”
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Mirek Prýmek 15. 09. 2017, 20:44:23
Připojuju se k tomu, že s Bareos mám dobré zkušenosti, Bacula už dneska myslím nemá cenu. Každopádně je potřeba počítat s tím, že je to docela "velké řešení", není to úplně triviální správně nastavit, člověku docela trvá, než pochopí principy. Zvlášť když s "velkým zálohováním" nemá zkušenosti. I tak to ale imho za to stojí, je to hodně dobrý nástroj.

Za slabinu považuji to, že po rekonfiguraci neexistuje vždy možnost reloadu, aniž by spadly běžící joby. Opět, dá se s tím žít, ale pokud to uděláte uprostřed full zálohy, ta bude muset proběhnout znovu, ale data v datasetu už jsou, a budou čekat na exspiraci (také nedořešený stav).
Pokud člověk nemá systém takový, že mu tam střílí jedna full záloha za druhou, tak asi pravděpodobnost tohodle jevu bude docela malá (typicky třeba záloha běží třeba ve 4 v noci, já v tuhle dobu málo kdy upravuju konfiguraci ;) ). A když už by se to mělo stát a měl by to být problém, dá se to ručně řešit - v závislosti na systému ukládání záloh různě. Já mám systém takový, že co job to volume, takže v téhle situaci by mi stačilo volume s tou nedokončenou zálohou ručně purge-ovat a když je nastavený "Action on purge = truncate", tak se i uvolní místo.

Se snapshoty to má více úskalí. Jak u VmWare tak u hyperV dochazí ke krátkému "pause" virtuálního stroje nebo disk IO operace se protahují na mnoho vteřin. Záleží co na těch virtuálech běží, normálně napsanému software by to nemělo vadit ale třeba průmyslové aplikaci využívající OPC komunikaci, nebo taková softwarová "perla" jako siemens simaticIT jsou na to  docela citlivé a často v důsledku backupu VM padaly.
Pletou se tady dvě věci dohromady: snapshot virtuálního stroje (celého - i se stavem CPU a RAM) a snapshot úložiště. To první tenhle efekt bue mít asi vždycky (na různých hypervisorech různě vážný), to druhé nemusí.

Snapshot filesystemu zaridi jen konzistenci dat, aby jsi ten virtual nemusel vypinat. Samozrejme jen po dobu co pobezi kopirovani.

1. Snapshot nebo vypnuti virtualu
2. Rsync kompletniho virtualu
3. Smazani snapshotu, nebo spusteni virtualu
Snapshot nezařizuje konzistenci dat, ale to, že celý disk je jakoby uložen v jednom okamžiku. Je to jako bych běžící stroj vyrval ze zásuvky a poté zazálohoval disk. Takže "konzistentní" je to jenom ve fakt omezeném smyslu.

Bacha na to, že aplikací, které se po takové události nemusí nutně umět zotavit, je spousta. Nejrůznější aplikace si vytváří na disku nejrůznější zámky a při nalezení stale zámku se chovají různě. Zrovna nedávno se mi stalo, že jsem vůbec netušil, proč najednou spamassassin žere 100% CPU a nakonec se ukázalo, že to bylo právě přesně tímhle - nekorektní zastavení stroje a stale lock. Pochopitelně v logu žádná srozumitelná hláška, trvalo několik dní, než jsem objevil pravou příčinu. Takže bacha na to!

Blbý je, že se víceméně nedá nijak zjistit, jestli aplikace, které člověk provozuje, opravdu umí tuhle událost ustát - výrobce může tvrdit cokoli a nemusí to být ve všech případech pravda. Zkoušet to můžu tisíckrát a teprve po tisíceprvní se to projeví. Je to blbý prostě no :)
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Jenda 15. 09. 2017, 22:46:48
kdesi jsem se docetl, ze PAUSE flushne cache, melo by se tim zaridit ze pokud se ten virtual rozbehne na jinem zeleze, bude to vypadat jako po rebootu, ale klidne se necham počit znalejším odborníkem

To doufám i přímo s LVM snapshotem - řízne to v nějakém okamžiku a je to pak jak píše Mirek jako kdybys to vytáhl ze zásuvky.

Bacha na to, že aplikací, které se po takové události nemusí nutně umět zotavit, je spousta. Nejrůznější aplikace si vytváří na disku nejrůznější zámky a při nalezení stale zámku se chovají různě.

Tak to je docela problém ne jenom při zálohování, k náhlému zastavení systému může dojít i z jiných důvodů (hardwarová závada, softwarová chyba v kernelu či hypervizoru).

Proč to nemá lock někde kde se to při startu systému samo (tmpfs) či programově čistí?
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Jan Forman 16. 09. 2017, 11:08:12
Spamassasin je příšernost, jinak ano většina locků se po náběhu sama maže, takže to nebývá problém. Snapshot filesystému se rovná opravdu vytažení vidlice ze zásuvky, se vším co z toho vyplývá. Ovšem proběhne sync, takže přece jen o chlup lepší. Netřeba rolovat žurnál zpět atd.
Neukončené transakce apod ale samozřejmě zůstávají. Bylo by třeba notifikovat konkrétní aplikace.

Zase to ale člověk opravdu nepoužívá každý den, někdy to nepotřebuje třeba nikdy. Popř. si z toho vytáhne data jak potřebuje.
Líbí se mi selektivní záloha přes RESTové rozhraní :-) na data co se mění a zbytek prostě celý ten stroj tak jak leží běží... Respektive data zálohuju zvlášť (dle technologie) a pak celý stroj se vším všudy. Bez výpadku nebo radikálního zpomalení pochopitelně.

kdesi jsem se docetl, ze PAUSE flushne cache, melo by se tim zaridit ze pokud se ten virtual rozbehne na jinem zeleze, bude to vypadat jako po rebootu, ale klidne se necham počit znalejším odborníkem

To doufám i přímo s LVM snapshotem - řízne to v nějakém okamžiku a je to pak jak píše Mirek jako kdybys to vytáhl ze zásuvky.

Bacha na to, že aplikací, které se po takové události nemusí nutně umět zotavit, je spousta. Nejrůznější aplikace si vytváří na disku nejrůznější zámky a při nalezení stale zámku se chovají různě.

Tak to je docela problém ne jenom při zálohování, k náhlému zastavení systému může dojít i z jiných důvodů (hardwarová závada, softwarová chyba v kernelu či hypervizoru).

Proč to nemá lock někde kde se to při startu systému samo (tmpfs) či programově čistí?
Název: Re:Zálohování virtuálních strojů za chodu
Přispěvatel: Karel Zeman 13. 10. 2017, 07:48:16
Rozsirim tema zalohy virtulaek. Pod KVM virtualizaci planujeme pouzit https://www.bareos.org/ na zalohy
1.)virtualek
2.)obsahu virtualek zejmena:
2.1.)Postgre SQL
2.2.)My/MariaDB
2.3.)Staticka data

....

Děkujeme za rozepsanou odpověď. Zkusili jsme se inspirovat. Aktuálně zkoumáme barmana. Myslíte si, že barman je správná cesta pro zálohu pgsql?   ::)