Dotaz: Zálohovat běžící VM z vnějšku nebo z vnitřku?

[Michal]

Ahoj. Mam nekolik virtualu ve vmware workstation (pracovni veci - kubernetes cluster, oracle db server, windows na vyvoj nejake desktopove .net aplikace, ...), ktere nonstop bezi. Disk je na btrfs na SSD. Kazdou hodinu udelam snapshot toho LUN a ten replikuju na rotujici rez. Parkrat jsem si to vyzkousel a funguje to ok. Po obnove se to chova v podstate tak, jako kdybych ve chvili vytvoreni snapshotu vypnul napajeni. Je to navic super pohodlne. Obnovim za par minut a prijdou akorat o otevrene veci. Ext4 i NTFS takove zachazeni zvladaji podle vseho bez problemu.

Vmware ale rika, ze to pry neni bezpecny zpusob jak zalohovat bezici VM. Principialne to chapu - z DB se ztrati necommitnuta (nebo commitnuta ale jeste nezapsana) transakce atd. Zalohovat bezici VM umi Vmware ESXi podle vseho tak, ze vmware udela vlastni snapshot vcetne obsahu pameti a zalohuje se pak ten. ESXi ale nechci. Zastavovat VM kvuli zalohovani kazdou hodinu take prekvapive nechci Takze je posledni moznost- zalohovat ten server z vnitrku baculou nebo necim takovym. To je ale dessssssny opruz pri obnoveni, kdyby se sesypal cely OS tak musim vytorit novy cisty a restornout z baculy do neho - robota na par hodin. Na tuty to pri zalohovani take zpusobi vice IO nez vytvoreni snapshotu. No a v neposledni rade- zajisti vubec bacula ze treba myi a myd soubory mysql jsou vzajemne konzistentni?

Takze bych se chtel zkusenejsich zeptat - jak moc riskuju tim snapshotovym zpusobem zalohovani kdyz se nejekdna o produkcni prostredi? Pouzivat zalohovani z vnitrku nebo mam pouzivat kombinaci obojiho?

Odpovědi

[X]

Zeptam se a] Co kazdou hodinu zalohujes? b] Proc se to neda zasavit?

[Michal]

a) Co se zalohuje je napsano hned ve druhe vete dotazu Pokud ten dotaz byl minen ve smyslu proc se zalohuje tak casto, tak bych si dovloli odpovedet otazkou - proc ne? Kdyz je vytvoreni snapshotu okamzite tak proc mam v pripade vypadku prijit o vic prace, nez musim? Popravde jsem uvazoval i o 10 minutach.

b) Protoze s tim vsim vicemene porad interaktivne pracuju. Kdyby se mi kazdou chvili ty VM pauzovaly (to trva docela dlouho, musi se zapsat cela pamet na disk a po tu dobu je VM zamrznuty), tak bych se z toho opumprlikoval. O shutdown pred kazdou zalohou nemuze byt samozrejme ani rec.

[X]

Mam trochu pocit, ze pouzivas snapshoty jako verzovaci system, vubec nemluve o databazi. Proto se ptam na detaily. Jak moc riskujes totiz zalezi na tom, co se skutecne snazis zalohovat. Dozvime se to?

[Michal]

Snazim se zalohovat stav disku tech VM v danych okamzicich a to pokud mozno tak, aby vse zustalo konzistentni. Mozna bude napomocne proc zalohuju:

a) Kdyz chcipne ten disk s VM tak mam ty repliky na rotujici rzi - to plni funkci klasickeho backupu b) Kdyz neco podelam ( rm -rf / , v kubernetes smaznu jiny image, nez jsem chtel, delete from table se zapomenyutym where, instalace update windows, ktery rozbije Visual Studio (to uz se mi stalo 2x), update linuxu ktery rozbije python/php (i to se mi stalo)... ) tak abych se mel moznost vratit z5 a to i ve chvili, kdyz zjistim, ze jsem to podelal pred tydnem. To by se mozna dalo oznacit jako verzovani

[Peter Golis]

Konzistencia bežiacej služby alebo systému vyžaduje uchovať okrem obrazu disku aj obraz RAM a stav CPU, alebo rovno použiť integráciu služby pre zálohovanie. Spoliehať sa na také to "nabehnutie ako po výpadku elektriky" je dosť rizotové.

[Max]

Není to rizikové, jen člověk musí počítat s tím, že přijde o to, co je v ram. Když by i toto chtěl minimalizovat, tak se to dá řešil celkem jednoduše. Prostě se scriptem, co dělám snapshoty, přihlásím před vytvořením snapshotu do VM a dám flush transakčních logů / zápisů na disk. A mám pak jistotu, že bude rollback dat plus mínus minutu od času snapshotu a nestane se, že bych přišel třeba o půl hodiny. Pokud tedy dělám snap každých třeba 5min.
Zdar Max

[Peter Golis]

A tou stratou údajov v RAM mu vznikne nekonzistencia. Ale to je zbytočné rozoberať.

[Max]

OracleDB, ale i další služby si s tím hravě poradí a nekonzistence dat nevznikne, maximálně rollback, ale to je asi stejně fuk, když se dělá záloha v nějakých intervalech a nemá to v HA na aplikační úrovni.
Čistě teoreticky by mohla nastat nekonzistence v rámci struktury dat v db v případě, že někdo udělal prasoaplikaci, které neposílá data v transakcích. Ale to se bavíme o věcech, co se prasily před hafec hafec lety. Dnes už se programuje o něco čistěji a většinou se používá orm, takže bych se ani tohoto nebál. Nicméně to jsou všechno věci, co už by měl vědět správce.
Zdar Max

[Peter Golis]

Takých vyjadrení som zažil. Ideál bola DB ktorá mala kvôli výkonu vypnuté zrkadlenie online redologov z RAM na disk. Offline redology sa tým pádom netvorili vôbec, a undo/redo žurnálu s transakciami tým pádom nebolo možné.

Ale je pravda že na nejakej hračkárskej inštancii čo beží niekomu na notebooku sa toho veľa nestane. Tá sa dá replikovať z testovacej inštancie ľavou zadnou.

PS: Hravo si to poradí so snapshotmi len ak je splnených viac podmienok. Tie podmienky ale znižujú výkon.

[Max]

Nojo, ale standard u db je generování transakčních logů a jejich ukládání. Pokud někdo provozuje db nestandardně, tak s podobnými věcmi musí počítat.
Jinak mi ještě navíc máme shcválně 10% performance impact, bo provozujeme RAC. Přenos transakčních logů pak řešíme async (nečekáme, až nám to standby potvrdí). Takto nám to vyšlo v risk managementu.
Zdar Max

[Peter Golis]

Keď som sa hral s Oracle XE (kvôli licencii, potreboval som len nejaké demo pre obchodníka), tak to bolo po inštalácii vypnuté. Musel som to zapnúť. Takže s tým štandardom by som bol veľmi opatrný. A ľudia si to občas zvyknú vypnúť aj podnikovej produkčnej databáze ktorá to mala po inštalácii zapnuté.

[X]

abych se mel moznost vratit z5 a to i ve chvili, kdyz zjistim, ze jsem to podelal pred tydnem

To nasekas tolik chyb, ze to potrebujes kazdou hodinu/10 minut? Trochu prehanis ne? Podle popisu to neni tak vazne, aby se to nedalo udelat i standartni cestou a nastroji ktere jsou urcene po konkretni behove prostredi. Mam databazi => zalohuju to jako databazi, mam kod v .NETu => verzuju etc. + snapshoty jako nouzova zaloha, ale v rozumnem meritku! Mimocodem ,takto to budes mit osetrene dvakrat a nebudes riskovat..

[Peter Golis]

Oracle DB by som radšej zálohoval pomocou rman do flash recovery area, a nespoliehal sa na nabehnutie ako po výpadku elektriky.

Ale každú hodinu, ...

[Max]

Opravdu není problém. SAP s OracleDB běžně tahám ze storage snapshotu a no problemo, vždy ok. Nestalo se mi, že by to nenaběhlo.
Zdar Max

[Peter Golis]

Pokiaľ má zapnuté online redology na disk a DB je v backup móde, tak je to v poriadku. To ale nie je vždy splnené.

[Ivan]

Korektni by bylo aby databaze byla archivelog modu. A pred snapshotem spustit: "alter database begin backup;" Po snapshotu spustit: "alter database end backup;"

[Peter Golis]

Ak to chceš bez použitia RMAN (čo neodporúčam), tak ešte potrebuješ odzrkadliť online redology z RAM do FS príkazom 'alter system switch logfile;' a skopírovať aj tie.

[Max]

Nevidím v tom problém. Jak už jsem psal, pokud chceš mít u db jistotu, že nebudeš mít od času vytvoření snapshotu velký rollback dat, tak se scriptem připoj do vm a dej flush zápisů / transakcí. Záloha ram a věcí okolo nedává smysl, bo stejně jedeš snapshoty v nějaých intervalech. Reálně ti tedy něco jiného nedá nic navíc.
Já zálohuju jak snapama a replikací jinam, tak konzistentní zálohou. V 99% používám na obnovu dat snapshoty. A to jak u MS Exchange, tak OracleDB, SAPu apod.
Zdar Max

[Michal]

Diky vsem za odpovedi. Zustanu tedy u tech snapshotu a zvysim jejich frekvenci na dvojnasobek, tedy jednou za 30 minut. Pokud bude nejaky problem kvuli tomu "nasilnemu vypnuti" (rozpadly FS, rozbita DB,...), tak se proste vratim o jeden snapshot zpet. No big deal, neni to produkce.

[Max]

fs by se rozpadnout neměl a db záleží na aplikaci (aplikační konzistence) a na zapnutém logování transakcí (bez nich by mohlo dojít k poškození nějakého datafile, ale nemám s tím zkušenosti, pravděpodobnost záleží asi na vytížení, ale třeba ani při něm nic nenastane).
Zdar Max

[ChatBot GPT-3]

Ahoj! Je to skvělá otázka a rozhodně záleží na tom, jaký je tvůj přístup k zálohování a jaké jsou tvé potřeby ohledně dostupnosti a obnovy dat. Zde jsou některé věci, které bys měl zvážit:

Snapshoty ve VMware Workstation:

Snapshoty jsou rychlým a pohodlným způsobem zálohování, ale mají svá omezení, zejména pokud jde o konzistenci dat. Pokud snapshoty vytváříš každou hodinu, může dojít k větší ztrátě dat, pokud běžící transakce nebo operace na disku nebudou uloženy na snapshotu. Pokud to pro tebe není problém a můžeš akceptovat určitou úroveň datové ztráty, může tento způsob fungovat pro tvé potřeby. Ale měj na paměti, že může dojít k problémům s konzistencí. Bacula nebo jiný zálohovací software:

Použití specializovaného zálohovacího softwaru, jako je Bacula, může poskytnout lepší zajištění konzistence dat. Tento software je navržen tak, aby umožňoval tvorbu konzistentních záloh a obnovu. Ovšem s použitím Baculy nebo podobného software budou zálohy obvykle náročnější na správu a údržbu, a obnova může trvat déle než u snapshotů. Kombinace snapshotů a zálohovacího softwaru:

Můžeš také zvážit kombinaci obou metod. Použij snapshoty pro rychlé a časté zálohy pro rychlou obnovu a použij zálohovací software pro periodické, důkladné zálohy pro maximální konzistenci. Testování obnovy:

Bez ohledu na zvolenou metodu je velmi důležité pravidelně testovat proces obnovy. Musíš se ujistit, že v případě havárie budeš schopen úspěšně obnovit svá data. Oracle Database a MySQL:

Pro databáze, jako je Oracle nebo MySQL, je důležité používat jejich vlastní nástroje pro zálohování (například RMAN pro Oracle nebo mysqldump pro MySQL). Tyto nástroje mohou zajistit konzistenci a úplnost dat. Celkově závisí rozhodnutí na tvých konkrétních potřebách, dostupnosti a toleranci k datové ztrátě. Je důležité mít správnou strategii zálohování, která odpovídá tvým konkrétním požadavkům na obnovu dat. Pokud máš možnost, konzultace s odborníkem na zálohování a obnovu dat může být také užitečná.