Vlákno názorů k článku GitLab měl pět zálohovacích mechanismů, nefungoval ani jeden od Ondra Satai Nekola - Je trapne to opakovat, ale asi je to...
-
Ondra Satai NekolaZlatý podporovatelJe trapne to opakovat, ale asi je to potreba: je vic nez vhodne si dat periodicky ukol zkontrolovat zalohy. A v ramci kontrol se hodi jednou za cas udelat i cvicnou obnovu (coz je trebas v domacich podminkach dost opruz, ale na druhou stranu v cloudu by to mela byt trivialita).
-
Jak já říkám, tohle je typická write-only záloha, kterou bohužel dělá nevědomky hodně lidí. Navíc se často setkávám s názorem, že mají RAID, takže nemusí zálohovat.
Rozumné knihovny automaticky pravidelně čtou zálohy z pásek, aby vyzkoušely, zda je záloha ještě čitelná. Pravda, neznamená to, že je použitelná (z hlediska logiky záloh a dat, konzistence apod.), ale vyloučí se alespoň selhání vlastního nosiče. -
Ondra Satai NekolaZlatý podporovatel
Ja to mam (pro domaci pouziti) ramcove od nejcastejsiho k nejmene:
- zkontrolovat, ze zalohy jsou neprazdne, maji nejakou rozumnou velikost a jsou tam soubory z posledni doby a ze zalohovaci job je "zeleny"
- borg i deja-dup maji kontrolu neporusenosti zaloh
- ta bolestiva cast - zkusit neco obnovit a srovnat obsah s tim, co bych cekal -
Ondra Satai NekolaZlatý podporovatel
(jinak samozrejme ideal je mit tohle take automatizovane, ale stejne tam asi nakonec bude nejaky moment, kdy se musi podivat lidske oko, at uz na data, na jejich hlidace, na hlidace hlidace...)
-
Izak (neregistrovaný)
LOL zadna knihovna data necte ;-)))
nektere pasky previji, ale jen WORM na dlouha leta, kvuli magneticke interferenci.
CRC kontrola je na nic, paska vadne zapise data, pak je zkontroluje se stejnou chybou a CRC sedi, staci vadny buffer, stalo se na DLT mechanikach dodovane so HP pa-riscu ... a nenadelas nic, data obnovis, ale jen co je chces dat do databaze, tak jsou nepouzitelna ....Jinymi slovi placas nesmysly o silech (knihovna zadnou logiku nema).
nejlepsi zalohy ma netapp, dela snapshoty a ty pak replikuje jinam, zaloha je tak 100%, zaloha na p0asky je OK, ale zdlohava, hracky jako TSM kde zalohujes datat jen jednou za zivot a pak foever increment5al je cesta do pekel, nebot po 5 letech neobnovis vse, nebot neco uz nepujde precist, nebo se omylem skartovalo, ackoliv se tomu TSM snazi zabranit media reclation, tedy ze stara data precte a zpise na jine pasky a ze uzdrzujes kazda datat napr. 2x a vicekrat ... jenze ne kazdy to dela ... kdyz mas kazdt tyden full, tak seice tahas data, ale 1. overujes integrity zivych dat 2 mas nekolik fullu, takze kdyz selze par souboru z cersve zalohy, je sance, ze budou aspon starsi. -
Inkrementalni zalohy jsou na kocku. Lepsi je mit dekrementalni zalohy (to umi tusim hracka zvana "rdiff-backup") - tedy mas posledni zalohu jako full backup, a k tomu mas rozdily do minulosti. Cim chces historictejsi data, tim vic s tim je prace. Posledni zalohu mas na tom disku primo jako soubory. Bohuzel to se to spatne implementuje s paskama. Na rotacnich diskach neni problem.
-
TUX zas tak moc neznám, ale od serveru W2008 výše funguje Server Backup tak, že provede snapshot disku, porovná se zálohovanou verzí a uloží jen bitové změny. Změna souboru na úrovni bajtů se projeví i v záloze na úrovni bajtů. Navíc se zpracovává disk jako jeden soubor, takže je optimální i přenos dat po síti - maximální rychlostí. Každý snímek disku se pak tváří jako kompletní záloha, lze tedy obnovit i disk k datu zpětně. Příklad: záloha serveru, 2 disky, 440 GB, čas 01h 20min, záloha na NAS.
P.S. Toto není reklama, jen by mě zajímalo, jestli lze na UXu dosáhnout stejného výsledku. -
Tohle je na moderních filesytémech trochu problém, protože se často změní spousta volného místa.
Takže i téměř nulová změna (projevující se jen změnou mtime na dočasném adresáři), se může projevit jako gigabajty v inkrementální záloze. Řešením je samozřejmě ten filesystém co se má zálohovat vůbec nepoužívat na dočasná data. To ale záleží na tom jak je napsaná aplikace, pro kterou jsou ta data určená. -
Adresare ano. Ale z duvodu atomicity operaci muze aplikace zacit zapisovat soubor do stejneho adresare a kdyz se rozhodne ze je hotovy a spravny, tak pak ho prejmenuje na spravne jmeno, cimz efektivne vymaze predchozi verzi. To je velmi uzitecna vec, ale muze to znamenat problem, pokud by se stihnul mezi zalohami ten soubor vymenit nekolikrat. Nicmene to je jiz hodne specificky scenar, ke kteremu vetsinou nedochazi.
-
j (neregistrovaný)
Zaplatis to? To sem treba takhle prisel za majitelem firmy a rek mu, ze je treba 1/2M na zalohovani* ... rek mi ze sem se zblaznil ... tak nezalohuje (to co se dela se za zalohovani povazovat neda ani s obema ocima v kyblu), ja sem zcela vpohode, jen chladim sampicko ... to az to chcipne abych mel cim to oslavit.
*tzn je teba nejen prostor kam zalohovat, s dostatecnouo historii a dost casto**, ale taky prostor, kam ty zalohy obnovit a kde otestovat ze sou pouzitelny.
**dost casto pocitam maximalne 15 minut, dyl si zadna normalni firma nemuze dovolit, to uz je moc velka ztrata dat, idealni je spis cdp.
-
bramburek (neregistrovaný)
Ja s tebou souhlasim, ze maly firmy maj proste problem se zalohama a defakto mas pravdu, ze je problem data vubec nekam zazalohovat natoz nekam obnovit.
Kdyz pominu ty problemy s tim, ze nechtej koupit dalsich 10 disku, ze si muzou dovolit jenom 5 disku ..... Jednu z nejlepsich "strategii" na obnovovani dat co jsem slysel je ve smyslu: "Kdo ma dneska cas a prostredky testovat obnovovani zaloh? No treba vasi vyvojari, davejte jim databaze a zalohy k obnove jako testovaci prostredi, nezatizite produkci, budete tam mit cerstva data a vite, ze to funguje".
Takze obnovovat zalohy, resp. je testovat muze skoro kazdy, protoze urcite nejaky ten testovaci server nebo nejake to misto najdete a kdyz sefovi reknete, ze to mate 2v1 tak si muzete nechat jeste pridat ;)
Pokud by byl problem, ze data jsou "tajna" tak se zacni shanet po novym zamestnani, protoze jestli ti na meetingu nereknou, ze se pokusi sami najit nejakou rozumnou cestu (post-test-recovery anonymizace dat napr.) nema to smysl s nima vubec resit. "Just let it burn".
-
j (neregistrovaný)
Jenze ono to velice casto neni o tom co si muzou dovolit. Ono to je o tom, ze majitel si radsi koupi dalsi audi nebo volvo nebo ... za 2, 3, 4M ... ale 1/2M na zalohovani neda. Stejne tak mu nedela problem rozfofrovat 10, 20, 30M za marketing, o kterym ani netusi, jestli je vubec k necemu atd atd.
Nehlede na to, ze kdyz firma provozuje IT infrastrukturu na kterou nema, tak proste driv nebo pozdejs prestane existovat. Jen otazka casu.
Pricemz dneska je to tak, ze z kazdy stokoruny hodnoty firmy delaj 80 korun data. Nejaky zbozi? Haly? Stroje? To vsechno pripadne calne pojistovna a "lusknutim prstu" se to da koupit.
Takovy testovani jaky popisujes je prokocku, protoze se 100% jistotou az budes tu zalohu potrebovat, tak zrovna ta kterou budes potrebovat nebude pouzitelna.
Ale lidi sou nepoucitelny, zcela bez ohledu na rozsah ...
Chcipne disk? Vykutas mu z toho data a reknes at si koupi dalsi na zalohovani. Myslis ze to udela? Zapomen, za mesic prijde s dalsim chciplym diskem. A samo "nutne" ty data potrebuje.
-
j (neregistrovaný)
Myslis ze 1/2M ve firme ktera operuje v radu miliard je moc? ... Samo ze nebudu resit zalohovani za 1/2M ve firme, kde je majitel zaroven sekretarka a uklizecka v jednom. Teda pokud to neni ten jeden z miliardy kterej v ty jednomuzeny firme dela miliardy obratu. I kdyz ... u nas je takovych vlastne hromada ... vcera zalozil firmu a zejtra bude delat za tu miliardu pro stat ...
-
Ondra Satai NekolaZlatý podporovatel
Tohle se da dotahnout jeste dal a stare servery proste pri deploymentu novych zahazovat a zalohu take obnovovat na fungl nove... ;)
Ale jak pisu - v domacich podmikach je to tezsi nez kdyz ma clovek cloud nebo alespon farmu.
-
Petr M (neregistrovaný)
Doma to řeším tím, že se všechno důležitý v noci mirroruje NAS<->NTB a NAS<->Desktop. Hot data jsou na třech místech (není potřeba zálohovat 2x za hodinu, ztráta 24h je přijatelná) a 1x týdně spustím Unison mezi NTB a desktopem. Když nenajde rozdíl, píchnu do desktopu externí disk, mkdir datum, rsync, rm -r nejstarsi_zaloha a nazdar. Všechno jde tak nějak při běžné "práci" na desktopu, protože Linux zvládne multitasking a prokjekty jsou extra v GITu, tak se jich zálohy fotek nedotknou.
Ale to je hlavně o tom, jak moc si člověk váží dat...
-
Ondra Satai NekolaZlatý podporovatel
Zalohovani doma IMO neni tak tezke. Spis potom to zkusebni obnovovani dat (proste nemam dva stejne notebooky, dve stejne worstations, dva stejne tablety...)
-
j (neregistrovaný)
Doma predevsim nemusis resit, ze potrebujes zalohu z pred dvou minut ... a s nejakou ztratou dat se smiris (vetsinou). Navic si prevazne aspon +- pamatujes, co si od ty posledni zalohy delal, takze vis, co kde je treba udela znova.
Doma taky neprovozujes vsemozne provazany a propojeny systemy ruznych dodavatelu, kde musis resit to, aby zalohy tech jednotlivych systemu byly konzistentni vuci sobe.
-
Trident (neregistrovaný)
Odborne se tomu rika disaster recovery test. DR testy se deji na vsech urovnich od vybaveni datacentera, pres HW az po obnovu dat pro aplikace. A to posledni je co se tyka githubu.
Jaky neuveritelny amaterismus. Praxe,praxe,dlouhodoba praxe v IT infrastrukture. To je to co tem lidem chybelo. Jinak by verifikaci zaloh delali aspon na jedne urovni.
Protoze kazdy z nas IT dedku na zacatku sve kariery uz minimalne jednou poznal situaci, kdy data v zaloze nebyla pouzitelna. V lepsim pripade pred katastrofou, v horsim pripade po ni.V zakladu staci udelat verifikaci zaloh a jednou za cas DR test. Ono se totiz muze stat ze i pri prubeznem zalohovani dochazi k tomu ze nektera data se proste neodzalohuji. Zvlaste pomerne spatne diagnostikovatelne byvaji ruzne komplexni "lan free backup" zalohovaci mechanismy.
