Administrace komentářů

Delam snapshoty a ty zalohuju pomoci borgbackup.

Mam na to script a dodrzuju nejaka pravidla a tim se to cele ridi.

Ma to tu vyhodu, ze se automaticky zalohuje vse co se tam vytvori a spada to do tech pravidel. Prenasi se jen rozdily (stejnym zpusobem jako rsync) a v zaloze jsou ulozene pouze rozdily a ne cele virtualy pokazde znovu a znovu, takze s brutalni usporou muzu udrzovat mnoho stavu do minulosti a nezere mi to misto v zaloze.

Dulezite je, ze obnova je extremne jednoducha a bud jen pripojim celou adresarovou strukturu zalohy z prislusneho okamziku zalohy (je to pohodlne, ale ne prilis rychle, takze pro co nejrychlejsi obnovu nejakeho moc velkeho fajlu to neni to uplne to nejlepsi), nebo si vytahnu jen jeden file (jinym zpusobem a dostatecne rychle).

Pravidla jsem si stanovil takova, ze pokud nazev lvm volume zavina na vm_ tak se automaticky zalohuje. Takze virtualkam davam disky s nazvy vm_neco nebo independent_neco pokud se zalohovat nemaji (zalohuju treba jejich vnitrky jen jako data). Podstatny je tedy jen ten, ktery se jmenuje vm_neco, ale abych vedel, ze lvm volume patri virtualce, tak ty ostatni nazyvam podle vyse uvedene konvence. Dalsim pravidlem je, ze zalohovane disky vzdy ukladam do jedineho fajlu, protoze nemuzu zarucit konzistenci virtualky, kdyz se udela snapshot jednoho z disku v jeden cas a nejaky jiny disk v jiny cas. Vetsinou to nemusi vadit, ale z te hromady virtualek kazda patri nekomu jinemu a ja nemzu zarucit, ze to nekomu nebude vadit. Zatim jsem nenarazil na to, ze by to mohlo nejak vadit, protoze s velikosti lvm volume muzu kdykoliv hybat, takze namisto toho, aby disk c: a disk d: byly samostatne disky, tak jsou to proste jen partysny.

Script si tedy vytvori snapshot a diskove operace bezi s nejnizsi prioritou, takze nijak nebrani behu systemu a virtualek, ktere vzdy maji prednost pred naroky zalohovaciho procesu. Dela se postupne jeden lvm volume za druhym. Po siti se prenasi jen rozdily oproti predchozimu stavu a vse je dost rychle, takze pohodlne zalohuju i velmi velke disky o velikost stovek giga na vzdalene servery pres net a klidne i po pomalejsich linkach a jeste k tomu nemusi mit zalohovacny server ostrou adresu a ani zalohovac nemusi mit ostrou adresu a spoji se klidne i jen tehdy, kdyz se proste jakymkoliv zpusobem jen "vidi" do netu (jsou klidne za natama) a pritom vse se krasne stiha i nekolikkrat denne. Drive jsem nejprve musel resit, ze kdyz ukladam komprimovane zalohy, tak musim mit jistotu, ze u jakkoliv velkych serveru (z hlediska velikosti dat) se musi cely proces stihnout alespon do 24 hodin. Po prechodu na tento finalni zpusob zalohovani to klidne stiham i mnohokrat za den, pokud chci!

Script si hlida spoustu veci a sam se aktualizuje a sam se spousti dle zadanych pravidel a sam odesila informace na report server a sam si hlida, ze bezi jen v jedine instanci a vytvari logy tak, ze se kdykoliv muzu pripojit na bezici proces v rezimu monitor. Report server obsahuje tabulku zaloh, kde vidim jednotlive backup servery a k nim pripojene backupovane servery a jejich data. Pozna se, kdyz je to virtualka, nebo kdyz jsou to jen data (adresarova struktura treba z vnitrku virtualky). Automaticky se oznacuji smazane disky, takze jejich udaje o poctu zaloh v konkretni datumy vidim, kdyz chci, ale nesviti mi tam cervena pole v celkovem vypisu proto, ze nebyla provedena zaloha z poslednich dnu (kdyz byl disk odstranen a tedy se nemuze zalohovat). Automaticky se vymazavaji stare zalohy dle nastavenych pravidel, aby cely proces mohl bezet v nekonecnem automatickem cyklu a pritom abych mel vsechny zalohy (vsechny ulozene stavy) z poslednich dnu a pak do minulosti jeden ulozeny stav z kazdeho tydne pak to cele nekolik mesicu dozadu. Kdykoliv pridam novy server, tak se automaticky zobrazi na report serveru. Muzu udelat jednoduchy filtr a zobrazovat jen nektere virtualy pro nejakou skupinu virtualu, patrici jen nejakemu subjektu. Zaroven mam pohled, ktery zobrazuje jen problemove zaznamy, kdyz chybi zaloha z predchoziho dne, tak abych to omrknul a zjistil duvod.

...a spousta dalsich veci, ale i tak jsem asi zabehnul daleko za tema. Podstatne je, ze jsem po dlouha leta uz vyzkousel kdeco a nakonec se mi z daleka nejvic osvedcilo zalohovat pomoci borgbackup a jsem spokojeny a pochrochtavam si blahem po celou tu dobu, co to takto pouzivam! Da se ricit, ze muj zalohovaci ekosystem tim konecne dosahnul verze 1.0 - tedy dela vse to co potrebuju a dela to tak jak potrebuju a v nasledujicich letech to muzu uz jen vylepsovat a ladit a pokud by tam pribylo neco zasadne noveho, tak si fakt neumim predstavit ze co za bonbonek by to mohlo byt, ale cela leta jsem vedel, ze co potebuju a co mi chybi a i kdyz jsem uz mel temer uplne vsechno, tak mi chybela prave ta deduplikace komprimovanych zaloh! A kdyz jsem laboroval s deduplikaci, tak to vzdy melo nejake zasadni mouchy, nebo pretezke vykonove naroky, ale pak prisel borgbackup a ten deduplikaci dela nadhernym zpusobem! Spolehlive a velmi rychle! Nepotrebuje temer zadny vykon stroje, takze muzu ukladat komprimovane a deduplikovane a velmi rozsahle zalohy a jeste k tomu i sifrovane a to cele nekdy i na nejakem pocitaci z odpadkace - neco co se neda pouzit uz ani na desktop pro sekretarku! Jo a strasne moc dulezite je taky to, ze borgbackup uklada v zaloze data jen jako normalni soubory! To znamena, ze kdykoliv muzu repository premistit bez nejmensich problemu na jiny zalohovac, takze mi to dava velikou flexibilitu. Nektere z drivejsich reseni mely sice ruzne zasadni vyhody a socialni jistoty (i kdyz ty taky tak nejak ne uplne...), ale nevyhody treba v tom, ze neprovadely deduplikaci na urovni dat, ale jen na urovni souboru (2x stejny soubor lezel v zaloze jen 1x, ale kazdy den byl jakykoliv virtual vzdy jinym souborem i kdyz mel nekolik stovek giga a zmenil se v tom jen bajtik, takze v takovem pripade samozrejme zadna deduplikace neprichazela v uvahu zatimco s borgbackup je to dokonale a na urovni bloku) a delalo se to pomoci hardlinku a ty jsem nedokazal presouvat ze serveru na server a nenasel jsem v tomto smeru zpusob jak se to naucit. Nebo ruzne deduplikacni fs vyzadovaly ohromne vykony, nebo zase ohromne mnozstvi ramky (borgbackup nema naroky temer zadne!) a stavalo se mi, ze obcas jsem nekde neco neohlidal a cely fs se rozbil - to se mi s borgbackupem nedeje a doufam, ze jsem to nezakriknul, ale provozuju to takhle uz nejakou tu dobu a obsluhuje to spousty terabajtu.

Dalsi zasadne dulezitou veci je, ze data se mohou ukladat a kdyz se cokoliv nepovede, tak data na zalohovaci sice pro ucely deduplikace zustanou k dispozici, ale borgbackup takovou zalohu nepovazuje za provedenou - treba nevyjde kontrolni soucet, nebo cokoliv - ne ze by se to stavalo. Ale chci tim rict to, ze kdyz uz dokazu vylistovat (tedy na report serveru overit konkretni zalohu ke konkretnimu datumu, nebo jejich pocet k tomuto datumu), tak mam absolutni jistotu, ze to jsou zalohy uplne a v poradku! Kdyz zaznam o zaloze eistuje, tak to je zazalohovane spravne a spolehlive! Takze se na ten udaj muzu spolehnout. Minimalne je to se spolehlivosti o nekolik radu jinde, nez tomu bylo v predchozich zpusobech zalohovani (musi se take zohlednit i ty pripady, kdy pred samotnou zalohou se musi spoustet nejake pripravne scripty - treba dump databaze), protoze jeden z resenych ukolu je spolehlivost a zarucitelnost zalohy i v pripade, ze se na to nemuzu nejak podrobne divat v tom mnozstvi zalohovanych serveru napric ruznymi lokacemi. Takze ted jsem z daleka nejbliz k tomu, ze kdyz se zaloha nepovede - jakkoliv dulezita, nebo nedulezita, tak s absolutnim minimem pozornosti na danou vec (a s minimem casu, ktery bych tomu musel venovat) se to opravdu vcas dozvim a nestane se, ze by mi nejaky zapadly server nekde v zapadle galaxii bezel treba tejden bez zaloh jen proto, ze jsem se na nej celej tejden nepodival.