Poskytovatel virtuálního serveru z logiky věci nemůže odpovídat za chování aplikací, kterou si zde zákazník nainstaluje a provozuje. Zálohuje se vlastní úložiště, poskytovatel ani nemá administrátorský přístup k vlastnímu serveru. Zodpovědnost za aplikační zálohy je především na administrátorovi systému.
A tato diskuze přímo přehlídkou těch neschopných administrátorů, co nechápou základní terminologii a fungování technologií. Normální fušeři :-)
To prece vubec nemusi lhat, proste delali kazdou hodinu snapshoot filesystemu. Jenze ten je ekvivalentni stavu disku po nasilnem vypnuti serveru, pokud v tom virtualu nebezi procesy, ktere ho po dobu snapshootu uvedou do konzistentniho stavu. Takze pokud nekdo po dobu snapshootu neudelal na mysql "FLUSH TABLES WITH READ LOCK", tak celkem ocekavane nemusi byt ty tabulky vubec konzistentni. Ale nevim jak konkretne to meli resene u nich.
mysql se nas netyka
celkemse tu resi zbytecna vec - resenim at uz s mysql nebo bez byla ta replikace, kde to melo nabehnout po padu primaru - pak by byla veskera debat na tema jak obnovit tabulky mysql celkem zbytecna - problem to muze byt tam kde mysql pouzivaji, pocitali s tou replikaci a ted misto toho maji nefunkcni zalohu
a vy vite co maji postizeni zakaznici ve smlouve?
To není pravda - MySQL runtime replikaci bez problémů umí a zvládá. Samozřejmě za cenu vyšších výkonových nároků.
A v tom je možná ten problém - pokud (a myslím tím pokud) Casablanca používá smlouvy jako toaletní papír a obchoduje s deštěm...
V každém případě - jiné zálohy nemají smysl - k čemu je snapshot se stovkou nedokončených transakcí?
Ono je si treba uvedomit ze kdyz dela nekdo zalohu tak ji musi delat tak aby byla po srsti technologii ktera je zalohovana. Proto taky kdyz si kupujete zalohovaci reseni tak nemaly prachy date za "pluginy" pro dane technologie.
Proste musite rict MySQL/Oracle/Lotus Notes ze se je zrovna chystate zalohovat aby ta data byla v konzistentnim stavu. Nestaci tudiz vzit "aktualni stav filesystemu" ( snapshot ).
Dělalo to snapshoty, ne kopie. Kopie je stav jednotlivých souborů ve chvíli, kdy se ten který soubor začal kopírovat, zatímco snapshot je stav celého souborového systému najednou ve chvíli, kdy byl vytvořen. Ten zásadní rozdíl, kteří mnozí rádobyadministrátoři nikdy nepochopili, je, že při kopírování se mezitím ostatní soubory mění, takže u DB pak máte tabulku z jedné doby a transakční log z jiné, což DB nezvládne. Snapshot tímhle netrpí, pro DB to vypadá stejně jako výpadek proudu (který každá normální databáze umí zvládnout) a proto se taky používá jako běžná zálohovací strategie.
Jenze AFAIK Casablanca tem lidem neprodavala "aplikacni cloud" s MySQL.
Je to stejne nedorozumeni, jake meli i vetsi hraci pri vypadcich EC2 od Amazonu. Pri designu sluzeb je treba poradne nastudovat, co mi vlastne poskytovatel nabizi. To, ze je dana vec prikryta nalepkou "cloud" jeste nemusi nic znamenat.
Doufejme, ze se (vsichni) uzivatele pouci a budou chtit po svych poskytovatelich neco jineho nez "cloud, ale levne prosim".
No ja teda nevim jak to chodi ve vasi casti planety, ale v te me, pokud nekdo tvrdi, ze neco zalohuje, tak se samosebou rozumi, ze konzistentne. => pokud ma zakaznik na necem nejakou databazi, tak by tam zaroven mel byt nainstalovan prislusny klient, ktery zajisti prave konzistenci zalohy (= zahohovac mu rekne "krles", SQLko pozastavi zapisy, udela nejakej ten flush a laduje data jen do logu ... udela se snap, a nasledne zalohovac rekne "hotovo" ...).
Samo, ne vse se konzistentne zalohovat da, ale to by mel zakaznik vedet a provozovatel by jej na to mel prosychr vyslovne upozornit. Nekdy totiz muze byt problem i nekonzistentni zaloha FS.
Tohle libovolny provozovatel resit muze, jen chtit. Samozrejme ze zalohovani KAZDE databaze probiha VZDY na aplikacni urovni. Pokud se databaze nedozvi, ze se ma zalohovat, tak jaksi nemuze byt zaloha konzistentni NIKDY, a to plati pro nasprosto vsechny databaze, nejen mysql.
Od poskytovatele sluzeb bych pak ocekaval, ze da k dizpozici svym zakaznikum prislusne nastroje, pripadne jim to za nejaky $$$ nakonfiguruje.
To ze mysql neni zrovna uzasny nastroj je sice fakt, ale konzistentne se zalohovat da - i bez replik a zastavovani.
:D
Oni to tam fakt maji ...
"Garantovaná dostupnost Hardwarových prostředků činí 100 % měsíčně,"
"V případě vzniku škody na straně Uživatele v souvislosti s odpovědností Poskytovatele za vady Služeb BBO si smluvní strany dohodly s ohledem na podmínky Smlouvy omezení náhrady této případné škody vzniklé Uživateli tak, že celková náhrada škody je omezena výší 10.000,- Kč (slovy: deset tisíc korun českých) včetně ušlého zisku."
Pokud je mi znamo, zodpovednosti za zpusobene skody se nelze zrict, a to ani mezi pravnickymi osobami. Tudiz toto ujednani ted asi projde nejakym tim soudnim rozhodnutim ... ;D.
Pokud provozovatel virtualu tvrdi, ze zalohuje, tak je odpovednost na nem. On ma vedet, jak co zalohovat, on ma zakaznika informovat a vybavit ho prislusnym klientem/nakonfigurovat mu to. A osobne bych si klidne od zakose nechal podepsat, ze vi jak probiha zalohovani, a ze pokud nema prislusnyho klienta spravne nastavenyho, tak ze backup bude nekonzistentni.
Mimochodem, vmware umi snapnout i RAMku ... takze se srv muze klidne vratit vcetne toho.
Ovsem toto vse jsou jen nasledky ... daleko vetsiho pruseru - neschopnosti zajistit provoz zaloznim HW. Mam tu 3x HW na vmware ... kdyz se ted zvednu, a libovolnej z nich vyrvu ze site ... tak si nikdo niceho nevsimne, protoze vse co na nem bezi se obratem presune na zbyvajici dva.
Toto se rozhodne jako bezna zalohovaci strategie nepouziva ... naprosto bezny pozadavek na libovolne zalohovani = konzistentni zalohovani.
Mimochodem, sem zvedav, co bude delat uzivatel takovyhle "sluzby" trebas s docem, ktery se zrovna v tu chvili ukladal ... a snap obsahuje 1/2 souboru ...
Součástí specifikace služby je jistě i popis zálohování. To, že si ho lidi pořádně nepřečtou, stačí jim zahlídnout slůvko záloha a dál to už moc neřeší je jejich blbost :-) Pokud někde napíší, že záloha je snapshot virtuálního disku, je pro odborníka zřejmé, co od toho můžu očekávat.
Provozovatel otevřeně informuje o tom, jak zálohuje:
"Cloud BIG BLUE ONE využívá technologii 3PAR remote-copy k vytváření geograficky oddělené zálohy dat. Data jsou tedy replikována do fyzicky vzdálené lokality, a tak je zcela eliminována možnost jejich ztráty. Tyto lokality jsou propojeny rychlostí 2 x 8Gbps pro aplikaci Disaster Recovery.
Na diskovém poli se vytvoří bitová kopie a replikují se pouze změny, takže samotný proces replikace nijak neomezuje zákaznické aplikace. Tzv. snapshot (kopie) se tvoří každých 60 minut."
To, že někteří taky-adminové nedokáží vyhodnotit, co to znamená není chyba provozovatele.
Že máte tři wmware servery je fajn - ale pokud vám vypnou z nějakého důvodu všechny, tak si toho taky asi někdo všimne :-) A i když ty tři servery schoří, obnova malého řešení bude z principu poněkud rychlejší...
Pokud se snap dělá v momentě, kdy je zapsaná jen polovina souboru na disk, tak s tím sebelepší strategie nic nenadělá. Snapshot je pouze obraz informací v nějaký konkrétní čas. Ovlivnit chování aplikace na virtuálním serveru tak, aby zapsala veškerá data z pozice provozovatele chcete prosím jak?
Ze je nekdo vestec jako ty a z pouzityho SW usuzuje ze jde o nekonzistetni zalohy ... to teda lol.
Vis, nekteri narozdil od tebe zalohovani pomoci snapovani disku a prenosu rozdilovych dat zcela bezne pouzivaji ... a kupodivu maji zcela bezne zcela konzistetni zalohy nejen databazi, ale i vsech FS, ktere to umi. A dokonce to umi daleko castejs nez toto velke "reseni".
To je sice strašně fajn, ale to samo o sobě nestačí. I když budu mít kompletní snapshot virtuálního stroje, pořád mám problém například se síťovýma věcma. Navázané spojení tam do druhého dne vydržet nemusí, stejně tak může dojít k nekonzistenci už jen díky tomu, že ten snapshot není nikdy běžící pro všecko zaráz. Víme prd, jaké aplikace tam komu běží - nejde na vše koukat jako na triviální LAMP all-in-one servery. Ale závěry děláme :-)
Tady s vama naprosto nemuzu souhlasit databaze se pouzivaji prave proto ze tohle samozrejme ZVLADA. Existuje neco cemu se rika transakcni log a libovolna transakce se do tohoto logu pise a okamzite zapisuje na disk (pokud je db dobre nastavena samozrejme lze tento log drzet i v ramce ale to musi udelat DBA a je to na jeho zodpovednost pak ziskame vetsi propustnost za cenu moznosti ztraty dat)
dokud transakce neni potvrzena v transakcnim logu tak je to to same jako by se nestala. Tzn DB je schopna se obnovit do konzistentniho stavu. To ovsem za predpokladu ze se udelal SNAPSHOT filesystemu, pokud se zaloha delal prostym kopirovanim souboru tak to tak samozrejme neni jelikoz zatimco sme skopirovali transakcni log tak se jinde mohli zmenit data na pozadi
Vrele doporucuju vyzkouset v praxi ... a teprv pak o tom nekam neco psat. Pravdepodobnost, ze databaze neco takoveho vydejcha je tak nekde kolem 50% ... takze nic moc. Ostane, viz vejs, trebas cache FS = system (i databaze) vidi data zapsana => do transakcniho logu klidne potvrdi., ale data ve skutecnosti zapsana nejsou ... jsou jen v cache.
Dtto, kazdy jeden disk ma vlastni cache. Dalsi cache muze mit radic a i kdyz ma baterku, tak ta je mu jaksi khownu, kdyz vyhori ptotoze do nej nachcala voda.
Udelat bezpecny zapis dat na disk neni vubec jednoduche, a je to etremne narocne na vykon - je totiz nutne odstavit veskere cachovaci mechanismy, coz snizuje vykon klidne o nekolik radu. Takze se to defakto nepouziva, a spoleha se na jine zajisteni - UPS a pod.
A samo, pokud chci udelat snap, delam snap konzistetni => potrebuju dat systemu/databazi vedet, ze ten snap chci udelat. Dela se to naprosto bezne. Umi to kazdej blbej zalohovaci soft za par tisicove ...
Tuna je dolezite rozumiet technologii ktoru pouzivate, od toho sa odvija vsetko.
Casablanca podla ich vyjadrenia robila snapshot celeho diskove pola ktory odlievali do ineho datacentra. Tento snapshot ale skoro vzdy sposobi rozbitu databazu (akukolvek) pokial je tato databaza aktivne vyuzivana.
Databaza si vela dat a transakcii cachuje do ramky, zaroven pri zapise ak nieje tak nastavena cachuje data este filesystem cache. To znamena, ze sa moze udiat velmi vela zmien nez sa nieco prejavi realne na datovom ulozisku a teda v tych zalohach tie data niesu aj ked sa spravil snapshot v dobe, kedy tam tie data zapisane boli.
Databazy sa musia zalohovat vzdy este navyse inak, ako samotny filesystem. Je potreba zabezpecit konzistenciu dat z databaze a to vyzaduje aktivne kroky pred zapocatim samotnej zalohy.
Chapem sice ze vacsina ludi toto nevie, ale hold neznalost ma svoje uskalia a je nutne aby ludia vedeli na com ich data bezia, co vyzaduju a aktivne sa o to zaujimali. Inak vam samozrejme nepomoze akykolvek poskytovatel.
Podle dat, ktera po obnove chybela jsme odhadli zalohu nekolik hodin pred padem. Ale jde o ty naborene MySQL tabulky.. a jestli jejich zaloha probiha na urovni filesystemu, jak se pise v prispevku nize.. tak se ani neodvazuju rikat o obnovu konkretnich tabulek.. Hodim tam vlastni zalohu ze soboty at to uz konecne jede.. a stehuju..
tak snad nemaji jen tu jednu posledni - preci musi mit predeslou - dokud nevim jestli zaloha probehla ok, tak preci nemazu tu predeslou - i kdyz tady uz je mozny cokoli
aniz bych chtel slovickarit - zaloha je to, z ceho dokazu system a data obnovit, pokud mam nejakou hromadu dat ze ktere to obnovit nejde, pak nemam zalohu, tak to proste je
Zalohovani SQL databazi snapshotama je pri spravnym nasazeni zcela bezpecny a je ale technicky resitelny. MS Windows podporuji WSS a vetsina SQL databazi ma WSS API, takze hypervizor ma moznost SQL serveru oznamit ze se provadi snapshot. Stejne tak v Linuxu je podpora pro guest-fsfreeze. Spis je otazka jestli to meli v BigBlueOne spravne naimplementovany.
Je uplne jedno kolik zaloh maji, to je principielni technologicke omezeni. MySQL nedokaze udelat bez zastaveni spolehlive pouzitelnu zalohu. A protoze zakaznici takove zastaveni tezce nesou, tak delame zalohy vzdy z replik databazi. Jenze pak se musi resit zalohy na "aplikacni" urovni, tohle zadny poskytovatel virtualnich serveru bez pristupu dovnitr virtualu vyresit nemuze.