Dotaz: zálohování KVM VM umístěných na LVM (RAW)

[PetrK.]

Dobrý den.
Prosím, jak zálohujete KVM virtuální stroje (Windows, Linux), které jsou umístěna na LVM ?
Jedná se mi o to, jak nejlépe vyřešit zálohování z pohledu hypervizoru (fullbackup + increment)

Děkuji za rady,
Petr

Odpovědi

[Max]

Myslím si, že nejlepší na tohle asi je nepoužívat LVM a používat qcow2. LVM podle mně nemá skoro žádný přínos a spíše spoustu nevýhod.
Zdar Max

[pavele]

Jak mi pomůže qcow2 při krachu filesystému na virtuálním stroji?

[Max]

Nechápu souvislost. Jak ti v takovém případě pomůže LVM?
Zdar Max

[k3dAR]

qcow2 ma v sobe snapshoty, pak ho + snapshots xml pro danej virtual zopirujes jinam, twdy incremental jsou v nem, full mas bokem...

[pavele]

Akorát musím pokaždé kopírovat celý virtuál, pokud používám interní snapdhoty.

Jdou provést interní snapshoty pouze pro systémový disk s qcow2, pokud je součástí virtuálu další virtuální disk ve formátu raw, u kterého nechci snapshot?

[Max]

Stále nechápu důvod používání rawu, nebo dokonce kombinace qcow2 a rawu. Výkon ti nezlepší, podpora třetích stran jde hlavně do qcow2. Operace se snapshoty u LVM jsou šíleně pomalý atd. Uniká my smysl tvých argumentací (jako třeba kombinace toho qcow2 + raw).
raw bych ještě pochopil u nějakých speciálních app, které nepotřebuješ nijak extra zálohovat na úrovni VM a jejich HA řešíš na aplikační úrovni, jako např. provoz nějakých velkých db v režimu active/standby apod. Víc příkladů mně už moc nenapadá.
Zdar Max

[trekker.dk]

Výkon ti nezlepší

Fakt Vám nevěřím, že filesystém nad filesystémem nad blokovým zařízením je rychlejší než filesystém nad blokovým zařízením.

Operace se snapshoty u LVM jsou šíleně pomalý

Rychlost snapshotů u LVM je problém v případě, když člověk není ochoten investovat pár tisíc do dvou SSD na metadata. S těmi je to docela v pohodě.

[Max]

Důvěra opravdu není to, co je na místě. Udělej si nějaké testy a sám uvidíš, jaký je rozdíl. Nebo pokud na to nemáš čas, tak si nějaké testy pogoogli.
Zdar Max
PS: proč myslíš, že má qcow2 podporu různých modů cachování? Opravdu né proto, aby byla v režimu off

[alkoholik]

S tim, ze QCOW2 nikdy nemuze dosahnout vykonu RAW ma proste pravdu.
Podporu ruznych cachovani nema QCOW2, ale cela blokova vrstva.

[trekker.dk]

Dobře, tak se tomu podíváme na zoubek. Nejdřív raw - přímý zápis na blokové zařízení

• aplikace zapíše do souboru, jádro hosta data uloží do RAM
• jádro hosta se rozhodne data zapsat, filesystém určí bloky na disku, kam
• jádro hosta je zapíše na virtuální disk
• zapsaná data přebere hypervizor a zapíše na odpovídající bloky fyzického disku

Teď QCOW - když "né" off, tak writeback, ok?

• aplikace zapíše do souboru, jádro hosta data uloží do RAM
• jádro hosta se rozhodne data zapsat, filesystém určí bloky na disku, kam
• jádro hosta je zapíše na virtuální disk
• zapsaná data přebere hypervizor a zapíše je do qcow souboru
• jádro hostitele zapsaná data uloží do RAM
• jádro hostitele se rozhodne data zapsat, filesystém určí bloky na disku, kam
• jádro hostitele zapíše na odpovídající bloky fyzického disku

Ten druhý případ má všechny kroky toho prvního a ještě něco navíc. Selský rozum říká, že nejlepší možný případ bude, že to bude stejně rychlé jako raw. Navíc je tu ještě možnost, že se host rozhodne, že chce data vypsat na disk (flush). V tom prvním případě jeho hypervizor vyvolá zápis svých data a počká na dokončení, ostatních hostů se to netýká. Naopak u většiny filesystémů - aspoň pokud si dobře pamatuju jeden článek, který jsem před nějakou dobu četl - je zápis dat jednoho souboru považován za příliš složitou věc na to udělat to spolehlivě, takže se to řeší tak, že při zapsání dat jednoho souboru na disk se prostě zapíšou všechna data všech souborů. Tj. i to, co je ve writeback cache qcow souborů jiných virtuálů.

Jo a mimo jiné, všimněte si, že zapisovaná data máte ve dvou cachích - v hostovi i v hostiteli.

Takže jestli tvrdíte, že qcow je rychlejší, tak mě napadají dvě možnosti:

(1) raw ovladač v Qemu je doprasený a to, co jádro hosta ukládá jako pečlivě složené větší bloky, zase rozloží na větší počet I/O operací. To bych považoval za bug toho ovladače, ne přednost qcow

(2) qcow fixluje a dělá to, co je popsáno v dokumentaci - "By default, the cache.writeback=on mode is used. It will report data writes as completed as soon as the data is present in the host page cache." Z toho mi vyplývá, že zápis je hlášen jako dokončený ještě předtím, než jsou data skutečně na disku, a v případě pádu hostitelského OS dojde ke ztrátě dat. Z tohohle - https://wiki.qemu.org/Features/Qcow2DataIntegrity - poslední modifikace říjen 2016 - mi přijde, že tomu tak skutečně je. V takovém případě bych si ovšem dovolil zpochybnit příčetnost každého, kdo něco takového používá v produkci.

[Max]

Já tvrdím, že performance impact u qcow2 je relativně zanedbatelný a v některých věcech nepostřehnutelný a dost záleží, jaký máš storage. Oficiálně se udává asi 5%, myslím.
Ale LVM ti nezaručí kontrolu integrity dat, což je s narůstajícím objemem dat problém. Navíc se člověk připravuje o fce, které qcow2 nabízí a o podporu app třetích stran.
Prostě pokud něco stavím na krev bez limitů, tak to není dobře a pokud někde rezervy mám, tak nevidím důvod používat LVM.
A ano, při writeback=on můžeš při výpadku proudu přijít o data. Např. v proxmoxu je myslím by default off.
Zdar Max

[trekker.dk]

Já tvrdím, že performance impact u qcow2 je relativně zanedbatelný a v některých věcech nepostřehnutelný...

Ok, to beru.

pokud někde rezervy mám, tak nevidím důvod používat LVM.

Třeba když nepotřebuju funkce, které nabízí qcow2, ani podporu app třetích stran

[Max]

Všude možně mám tuto zkušenost : "co platí dnes, nemusí zítra".
Zdar Max

[j]

Resis ptakoviny, dam ti klidne konkretni priklad, EMC (jestli neznas, dohledej si, ted uz je to Dell), co myslis ze pouzivaji jejich diskovy pole? Vazne myslis, ze pracujes s fyzickym HW? Starou backoru. Ve skutecnosti uz ani RAID neni klasickej "HW raid", ale vse se to chova jako virtualni SW uloziste.

A takova opravdu lowend varianta toho uloziste ti da stovky tisic IOps a GB/s. Jiste, z ciste HW bys mozna dostal o par IOps a par bytu navrch, ale prisel bys o tolik funcionality, ze leda blazen by to resil. Jednou z nich jsou prave pohodovy rychly snapshoty, druhou libovolny rozsirovani pole o libovolnej pocet (a rychlost/velikost) disku.

[pavele]

Na qcow2 mám systém, virtuál je je poměrně malý, na raw discích mám data (virtuální disky jsou velké) a ty zálohuji přes rsnapshot.

Proto by mi stačilo provádět interní snapshoty pouze na systémovém disku

Snapshoty na datových discích jsou mi k ničemu.

Jde tedy provádět v tomto případě interní snapshot pouze systémového disku?

[k3dAR]

nezkousel sem, ale pokud se nepletu, tim ze snapshoty se ukladaji primo do prirazeneho/prirazenych qcow2, tak snapshot raw se delat nikam nebude...

[pavele]

Interní snapshot s kombinací disků qcow2 a raw mi skončí chybou - nevytvoří se.

Nenašel jsem žádný parametr, který by vynechal určité disky z tvorby interního snapshotu.

[k3dAR]

mas pravdu, overil sem u sebe a je to tak, rychle hledani min aslo ze by to melo jit s parametrem --disk-only a pripravenym xml, ale nedari se mi, tak dam jen ten link kdybys chtel patrat...

[Jendа]

Používám tři způsoby podle jednoduchosti a požadované konzistence:

• Jednoduše rsyncnu / běžícího virtuálu na btrfs pole a udělám snapshot. Pokud ve virtuálu je databáze, tak ji před tím dumpnu do souboru. Toto pořád může způsobit nějaké nekonzistence u některých aplikací, ale v praxi je to často „good enough“.
• Udělám LVM snapshot, namountuju ho bokem (hint: kpartx) a provedu ten rsync z něj.
• Udělám LVM snapshot a zkopíruju ho pomocí bscp. Blbé je že u ext4 ten diff typicky obsahuje úplně zbytečně žurnál.

[trekker.dk]

Pokud ve virtuálu je databáze, tak ji před tím dumpnu do souboru

U databází, které to podporují, tohle jde ještě vylepšit tak, že se DB serveru řekne, aby data na filesystému uvedl do stavu, kdy půjdou zazálohovat (např. u Postgresu pg_start_backup()). Pak není potřeba nic dumpovat a zálohu jde zkopírovat ze snapshotu rsyncem.

[j]

U databazi se to dela typicky tak, ze mas logy na jinym disku nez data, a po dobu vyrabeni backupu (ktera tim padem muze byt prakticky libovolne dlouha) se do dat nic nezapisuje. Logy pak muzes odzalohovat taky, ale tam zas bude backup rychlej, protoze tam nic moc nebude.

Potiz je v tom, ze pokud je tvurce aplikace blbec, je ti i tohle hovnajz platny, protoze mas sice databazi jako takovou konzistentni, ale v ni klidne muzou byt nekonzistetni data (spousta tupcu ti zapise napriklad polozky v jiny transakci nez hlavicku - respektive co to je a k cemu transakce, vubec netusej).

[CandySan]

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.

[PetrK.]

Dobrý den a děkuji všem za příspěvky, které se tu přes víkend nahromadily.
Nic méně, pořád nemám jasno v tom, jak to "správně" řešit.

Pokud bych stavěl od základu, tak bych měl k dispozici 1x 1TB SSD + 1x 4TB HDD.
Systémový disk zpravidla dělím na 512MB /boot + 4G swap + 60GB na /
Zbytek nechávám pro LVM.
Datový disk je jedna velká LVM oblast.

Souborový systém je zpravidla vždy ext4.

Pokud bych tedy stavěl takto na zelené louce, jak by jste to postavili vy, resp. jaké máte zkušenosti ?
Podmínkou jsou full-backupy + incrementy. Retence mi zatím stačí 2x "@weekly on sun" pro full backup a 14x @daily pro increment.
VM není možné po dobu zálohy vypnout (Windows + SQL + AD DC...a další MS radosti).

Díky za info,
Petr

[trekker.dk]

Odpovědi, jak to řešit "správně", se asi nedočkáte - správně je to, co vám vyhovuje a co funguje. Téměř určitě se tu neobjeví nikdo, kdo by vám řekl o úžasném nástroji X, který zazálohuje všechno, co potřebujete. Leda byste měl spoustu peněz navíc, komerční zálohovací blackboxy existují a ten, kdo je vyrábí, si samozřejmě nechá dobře zaplatit za to, že veškerou práci udělal za vás.

Několik možných způsobů, jak zálohovat, tady padlo (např. v #7) - a je dost pravděpodobné, že pokud máte jenom trochu různorodé prostředí, budete muset kombinovat - zálohovací metoda vhodná pro soubory a adresáře například nebude vhodná pro zálohování SQL databází. Doporučuju taky projít dokumentaci toho software, jehož data chcete zálohovat - je dost pravděpodobné, že tam kapitola o zálohování bude

[CandySan]

Chtelo by to raid - staci SW raid (mdadm) a tedy mit alespon 2 ty disky. Neco ukousnout na system (davam obvykle 8 GB) a zbytek uz bude jen prostor pro LVM svazky. Pokud potrebuju i ssd, tak to je druha VG sestavena ze ssd. Ale budiz! I bez RAIDU to treba jde.

Jednotlive virtualky sestavaji z jednotlivych LV.

Pak pouzit borgbackup a udelat si scriptik (klidne ti muzu dat moje kompletni reseni a odpichnes se od toho - ale ja si tam resim vsechny oblasti plus ukladani samostatnych adresaru a nejen virtualek a nemusi te zajimat tohle vsechno) a udelas snapshot za behu virtualky a ten primo sosas tim borgbackupem do zalohy - klidne vzdalene nekam pres net (ten borgbackup je neskutecne vykonny i na totalnim srotu a pomalem netu). A bez nutnosti ukladat si lokalne kopii snapshotu do souboru - proste primo do zalohy.

Po siti se pak prenasi vzdy jen incrementy a ty jsou v zaloze vzdy sestavene do celku a vzdy tvori fullbackup. Priklad: mam 300GB velky LV patrici nejake virtualce. Od posledni zalohy se zmenilo treba jen 5MB. Po siti tedy odjede jen 5MB. Vylistuju si dostupne zalohy a v tomto prikladu mam 2 zalohy k dispozici. Obe obsahuji file o velikosti 300GB a kazdy z nich je stav z nejake doby, kdy byl vytvoren snapshot. V zaloze je tedy 600GB dat, predstavujicich 2 stavy z ruzne doby. Odmyslime si tu transparentni komprimaci a odmyslime si, ze probehla deduplikace i v ramci jednoho fajlu pri prvni zaloze (napr. prazdna mista v tom raw disku) a tak mame v zaloze na zalohovaci zabranych maximalne 300GB + tech 5MB. Ve skutecnosti to bude spis treba jen 50GB.

Pokazde, kdyz delame novou zalohu, tak to zasadne vzdy je jen increment od posledniho stavu (to resi borgbackup transparentne - ostatne jako vsechno), ale pripojim-li zalohu, tak tam vidim ve forme adresaru, ktere odpovidaji casum zaloh, vzdy jen cele fajly - jakoby fullbackupy.

Pozor! V pripade tohoto zpusobu zalohovani (tedy pouziti borgbackupu) je NEMOZNE nemit zalohu v RAIDU, protoze uloziste musi byt odolne proti bedarum na disku! Protoze becko v deduplikovanem ulozisti pak samozrejme muze a nejspis musi zasahnout vsechny zalohy, ale to se snadno resi prave raidem, ktery tedy je podminkou pres kterou nejede vlak. Mit raid i na zalohovanem virtualu je vsak rovnez velmi rozumne, pokud tam ma byt neco, co nesnese vypadky a pritom ten raid stoji jen ten jeden disk navic.

[Jendа]

Neco ukousnout na system (davam obvykle 8 GB) a zbytek uz bude jen prostor pro LVM svazky.

Osobně dávám systém též na LVM, minimálně v Debianu je to již mnoho let plně automatické a bezproblémové. Když dělám nějakou zásadnější změnu (typicky přechod na novou major verzi distribuce), tak udělám snapshot, a když se něco podělá (což se naštěstí stává málokdy), tak to bez stresu vrátím a můžu problém vyřešit.

(protip (Debian): dělejte to v pořadí změna sources.list, apt-get update, apt-get -dy dist-upgrade, snapshot, apt-get dist-upgrade. Díky tomu nebudete mít ve snapshotu zbytečně všechny stažené balíčky, což trochu pomůže rychlosti třeba na pomalém rotačním RAID6)

Po siti se pak prenasi vzdy jen incrementy a ty jsou v zaloze vzdy sestavene do celku a vzdy tvori fullbackup. Priklad: mam 300GB velky LV patrici nejake virtualce. Od posledni zalohy se zmenilo treba jen 5MB. Po siti tedy odjede jen 5MB.

Počkej, tohle mi nefunguje (nepoužívám tedy Borg, ale již zmíněný skriptík v Pythonu, který by měl ale dělat v zásadě totéž, jen bez hezkých věcí okolo). Teda jestli to chápu dobře, ty bereš diffy toho blokového zařízení. A mně to na ext4 vždycky přenese minimálně 150-300 MB (víceméně podle velikosti filesystému), i když se skoro nic nezměnilo. Podezřívám, že za to může žurnál, který se furt přepisuje jako kruhový log.

[xxl]

Osobně dávám systém též na LVM, minimálně v Debianu ... Když dělám nějakou zásadnější změnu ..., tak udělám snapshot,

To dělám taky.

(protip (Debian): dělejte to v pořadí změna sources.list, apt-get update, apt-get -dy dist-upgrade, snapshot, apt-get dist-upgrade.

Z toho tak nějak chápu, že ten snapshot děláš za běhu. Je to tak? To ale nemůže být konzistentní, ne? Já ho v takovém případě vytvářím při rebootu, před namontováním root volume.

[Jendа]

Z toho tak nějak chápu, že ten snapshot děláš za běhu. Je to tak? To ale nemůže být konzistentní, ne?

Je to ve stejném stavu jako kdyby se ten systém natvrdo vypnul, a to se prostě děje a musí to vydržet.

[xxl]

To jo, ale já to radši v tomto případě nepokouším.

[Max]

My jedeme 24/7, vše musí nonstop běžet. Reboot některých VM trvá třeba 30min. Je nemyslitelné, aby každá záloha obnášela reboot.
Já používám ESXi a Veeam, ale principy jsou stejné. Veeam využívá vmware agenta ve VM. Jenomže to freezne VM a není to doporučováno. Místo toho je doporučováno dát Veeamu hesla do VM, aby on udělal flush všeho a zajistil konzistenci.
Každopádně zálohuji Veeamem jak "konzistentně", tak bez agenta, bez ničeho / nekonzistentně a vždy vše přežilo a je jedno, zda se jednalo o db, nebo něco jiného.
A na podobný problém člověk narazí u replikace storage v režimu active/pasive. Jak zajistíš, že data na druhém storage budou konzistentní? Opět, my máme třeba NetApp a Veeam umí řídit podobné replikace, Veeam tedy umí na všech VM vynutit flush a provést konzistentní repliku. Problém je, že když při záloze je vždy VM nějakou dobu nedostupná (pár sekund), tak při replikaci např. každých 10min to nebude asi vypadat úplně ok. Navíc tento druh replikace zase neumožňuje rychlý start VM ze záložního pole (=nastavení záložního pole jako primárního), takže se nakonec stejně používá replikace přímo na úrovni storage a ničím se neřídí. VM nevypadnou ani na sekundu, ale samozřejmě budou ve stavu jako by vypadl proud. Teď povyšuji verzi ESXi na všech hypervisorech a docela by mně zajímalo, zda se to zlepší, nebo je na takové fce potřeba mít hoodně velký výkonový rezervy, aby se ta doba odstávky (freeznutí VM) minimalizovala na nepostřehnutelnou hodnotu.
Zdar Max

[Max]

Jinak ještě dodám, že u kritických systémů řeším failover/ha na aplikační úrovni. Tj. mám dvě VM, jednu v primární lokalitě, druhou v sekundární a replikuji data v rámci služeb ve VM. To je ale z pohledu licencí drahá sranda (většina věcí vyžaduje být zalicencovaná na obou stranách).
Takto tedy řeším reverzní nginx cluster, dns servery, ntp servery, db servery, AD servery. Vše se přepne automaticky, kromě db, tam to řeším manuálně (šlo by automaticky, ale nějaký problém na síti a mohl by to zavařit, takže pro jistotu).
Zdar Max

[Jendа]

Je nemyslitelné, aby každá záloha obnášela reboot.

Tak ještě se dá použít

fsfreeze halts any new access to the filesystem and creates a stable image on disk. fsfreeze is intended to be used with hardware RAID devices that support the creation of snapshots.

Akorát když si člověk nedá pozor, snadno se dostane do stavu, kdy už nejde unfreeze

[trekker.dk]

Filesystém by měl před snapshotem jít zmrazit do konzistentního stavu - myslim, že ta utilita se jmenuje fifreeze

[trekker.dk]

A teď koukám, že jsem měl nejdřív dočíst vlákno

[CandySan]

Potvrzuju, ze se tim delaji diffy primo toho blokoveho zarizeni! A deje se to oproti datum, ktera jsou ulozena klidne napric netem.

Tech 5MB jsem strelil od boku a velikosti pod tech zminenych 300MB jsou pod moji rozlisovaci schopnost, takze bez dalsiho testovani pripoustim, ze muze byt pravda, ze se muze prenest vice kvuli nejakemu dusledku, nebo nejake rezii. Nevim o tom a nikdy jsem si neceho takoveho nemusel vsimnout, takze toto nepotvrzuju, ale ani nevyvracim a urcite si to v budoucnu otestuju a dopidim se pravdy i v tomto ohledu.

Pokud to myslis tak, ze uvnitr toho blokoveho zarizeni je ext4 a ze dne na den tam vzdy dojde ke zmenam v rozsahu 150 az 300 MB, tak to treba mozne je taky..? Ext4 nikde nepouzivam a i kdyby, tak jsem tomu pozornost doposud nevenoval, takze do teto odbocky v diskusi se nemuzu zapojit s hodnotnymi informacemi. Podstatne je, ze se skutecne prenasi jen diffy oproti predchozi verzi obsahu toho blokoveho zarizeni (vlastne ani to neni pravda - hledaji se shodne bloky v celem ulozisti a je uplne jedno zda to je z verze predchozi, nebo nejake stare, nebo i z jineho fajlu - proste deduplikace!). Nejakou zanedbatelnou rezii samozrejme muze zbastit fakt, ze obsah je rozrezan na bloky a porovnavaji se ty bloky s protejskem, takze z toho plynou nejake drobne dusledky. O dalsi rezii nevim, ale nejaka komunikace samozrejme musi probihat i nad ramec ulozenych dat, ale to by rovnez melo byt dostatecne zanedbatelne.

Podstatne je, ze uvnitr virtualu se dat meni pomerne malo. Vetsina jich lezi ladem a nedeje se s nimi nic. Je tedy cilem tato data neprenaset znovu a neukladat je na disk v zaloze pokazde znovu, ale usetrit je jak pri prenosu, tak i v ulozisti, tak usetrit cas straveny samotnym prenoisem a zaroven mit vzdy z kazdeho okamziku zalohy cele data, ktera se jen zkopiruji a nemusi se rucne sestavovat, protoze v pripade krize (nutnost obnoveni dat) je zasadne dulezite, aby proces byl dostatecne jednoduchy, protoze v takovem pripade je potreba celou mentalni energii venovat vsemu ostatnimu a ne plytvat prostredky jeste na zbytecnou slozitost obnovy samotnych dat. Zvlaste pokud je prostredi ruznorode (proto venuju velike usili sjednocovani vseho co je jen mozne) a tech srveru je nejakym zpusobem mnoho.