reklama

Zálohování virtuálních strojů za chodu

Re:zalohování virtuálních strojů
« Odpověď #15 kdy: 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

reklama


Kit

Re:zalohování virtuálních strojů
« Odpověď #16 kdy: 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?

Re:zalohování virtuálních strojů
« Odpověď #17 kdy: 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 %.

Karel

Re:Zálohování virtuálních strojů za chodu
« Odpověď #18 kdy: 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

Re:Zálohování virtuálních strojů za chodu
« Odpověď #19 kdy: 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?


j

Re:zalohování virtuálních strojů
« Odpověď #20 kdy: 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.

MP

Re:Zálohování virtuálních strojů za chodu
« Odpověď #21 kdy: 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.

Martin

Re:Zálohování virtuálních strojů za chodu
« Odpověď #22 kdy: 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á.

Re:Zálohování virtuálních strojů za chodu
« Odpověď #23 kdy: 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.


MP

Re:Zálohování virtuálních strojů za chodu
« Odpověď #24 kdy: 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.

Re:Zálohování virtuálních strojů za chodu
« Odpověď #25 kdy: 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.

ZAJDAN

  • *****
  • 1 118
    • Zobrazit profil
    • E-mail
Re:Zálohování virtuálních strojů za chodu
« Odpověď #26 kdy: 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
pokud nemáš trpělivost, pokud nemáš odpověď na dotaz, chceš ostatní posílat do kouta nebo je odrazovat, že na to nemají?...nemrhej síly a raději se nevyjadřuj...prostě to ignoruj

kojot4

  • ***
  • 117
    • Zobrazit profil
    • E-mail
Re:zalohování virtuálních strojů
« Odpověď #27 kdy: 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.

kojot4

  • ***
  • 117
    • Zobrazit profil
    • E-mail
Re:zalohování virtuálních strojů
« Odpověď #28 kdy: 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í.

Kit

Re:zalohování virtuálních strojů
« Odpověď #29 kdy: 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.

 

reklama