Dotaz: Zálohování celého serveru

[jan.rok]

Pro zálohování celého serveru (fyzický server s HW RAID1 a RAID5, RHEL 8.x) jsem dlouhodobě používal VEEAM Agent for Linux FREE, kdy se zálohoval server jako celek a pak se dál dělaly rozdílové zálohy. Vše bylo uloženo na NAS jako SMB share (kromě toho zálohuju data a nastavení i jinak, ale to sem teď nepatří). Řešení bylo funkční a fungovalo dobře i při zpětné obnově.

Jenže po aktualizaci RHEL na 8.4, kde je používáno jádro 5.8 (aktualizace byla nutná pro běh ERP), přestal VEEAM fungovat (tato kombinace VEEAM + jádro není zatím podporovaná ze strany VEEAM), musím tedy VEEAM opustit.

Mohl by mi, prosím, někdo doporučit jiný sw, který by dokázal zazálohovat celý server za chodu? Nerad bych se této dodatečné zálohy vzdával. Varianty jako dd, Clonezilla apod. mi nedávají možnost udělat zálohu za běhu.

Díky za rady. JR

Odpovědi

[AraxoN]

Používať staršie jadro (v rámci RHEL 8.4) a počkať kým bude podpora VEEAM aj pre jadro 5.8?

[jan.rok]

To právě asi nepůjde, protože dodavatel ERP doporučil právě 5.8. ERP bude mít asi v tomhle případě bohužel přednost. Je to něco kvůli Informixu. Resp. neodvážím se použít jiné jádro, než doporučuje placená podpora, ačkoliv si myslím, že by to nevadilo.

[MP]

Co treba borg a podobne typy? Na docasny beh by to mohlo stacit.

[majales]

Zkoušel jsem kombinaci rear a Borg. Je to funkční, ale musí se to vyladit. Výsledek je recovery iso ze kterého se nabootuje a obnoví celý server z Borgu.

[Jendа]

Já dělám jednoduše rsync / (pro historii je v cíli btrfs a dělají se snapshoty). Ale pokud tam nemáš LVM/btrfs/něco jiného co umí snapshoty, tak to nebude konzistentní, pokud se konzistence nedá dosáhnout na aplikační úrovni (např. provozuješ aplikace kde jsou soubory v pohodě a databáze se vždy před zálohou dumpne do souboru).

[Heron]

Nebo uvede do stavu slučitelného s rsync (SELECT pg_start_backup('label');).

Ale snapshot fs je nejlepší nápad.

[Peter Golis]

Dokáže už snapshot FS uviesť databázové transakcie do konzistentného stavu, tak ako databázový backup? Len sa pýtam, aj keď neviem či mu ten Informix (o ktorom je otázka) beží nad PostgreSQL (ktorému patrí funkcia pg_start_backup).

[Heron]

Dokáže už snapshot FS uviesť databázové transakcie do konzistentného stavu, tak ako databázový backup?

To umí od počátku.

Není úkolem FS informovat DB, ale slušné DB se dokáží vyrovnat se sestřelením (SIGKILL), výpadkem ele apod. Po startu jsou konzistentní ve stavu poslední potvrzené transakce. FS snapshoty nejsou pochopitelně tak brutální jako výpadek ele, ale o ničem nijak DB neinformují.

Snapshoty na zálohování a klonování DB serverů používám už mnoho let (12+let), právě s postgresem a nikdy žádný problém (ani jej nelze očekávat, pokud chce DB splnit ACID, tak musí zachovat konzistenci i durabilitu).

[j]

Ale kdeze, to neumi zadnej snap fs.

Ve skutecnosti mas 3 urovne konzistence.

1) konzistence na urovni FS = soubor je citelny, a nikde ho kus nechybi nebo neprebejva. Presne a POUZE toto, umi zajistit snap.

2) konzistence na urovni databaze = tabulky jsou citelny, a nikde kus nechybi nebo neprebejva

3) konzistence datova = konzistenni je datovej model = doklad ma hlavicku i polozky, a nenastane situace, kdy by v zaloze byly treba polozky ale ne hlavicka.

Abys docilil konzistence na urovni 2), MUSIS bezpodminecne nejak dotlacit databazi k tomu, aby dokoncila transakce, a teprve PAK muzes udelat snap.

To ze vetsina databazi to vetsinou nejak prezije je jen nahoda, to neni konzistentni zalohovani. Naprosto bezne ti totiz databaze ty posledni zmeny proste zahodi, protoze zjisti, ze jsou nekonzistentni. Vetsinou to nijak zvlast nevadi, ale je to ztrata dat, a prichazi zcela VZDY, pokud nezalohujes konzistentne.

Konzistenci na urovni 3) musi zajistit tvurce, prave tim, ze spravne pouziva transakce. Pokud je pouziva blbe nebo vubec, pak to presne podle toho vypada.

Jinak receno, to co delas naprosto PRESNE odpovida tomu, ze server natvrdo vytrhnes z elektriky, a pak cekas, co bude, az ho zas zapnes. Presne takhle vypadaji tvoje "zalohy".

---

Dete s tim guuglem dopice!

[Heron]

Čemu přesně nerozumíš na větě:

Po startu jsou konzistentní ve stavu poslední potvrzené transakce.

?

1) konzistence na urovni FS = soubor je citelny, a nikde ho kus nechybi nebo neprebejva. Presne a POUZE toto, umi zajistit snap.

Tohle ti zajistí více věcí, třeba řádně volaný sync fs, flush cache na disky apod. Snap ti především zajistí to nejpodstatnější, že snímek proběhne pro všechny soubory ve stejném čase a tedy nehrozí, že nějaký soubor bude novější, protože se změnil v průběhu klasického kopírování, které probíhá nějaký čas a každý soubor tak obsahuje změny z jiného času.

Nejdůležitější vlastností atomického snapshotu, že celý FS zaznamená v jeden okamžik.

Naprosto bezne ti totiz databaze ty posledni zmeny proste zahodi, protoze zjisti, ze jsou nekonzistentni. Vetsinou to nijak zvlast nevadi, ale je to ztrata dat, a prichazi zcela VZDY, pokud nezalohujes konzistentne.

Nejedná se o žádnou ztrátu dat. Na DB se commituje neustále, většinu produkčních db není možné odstavit z provozu (a vlastně by bylo dost divné odstavovat službu jen kvůli záloze). Takže buď uděláš pg_dump, který kupodivu bude taky obsahovat pouze potvrzené transakce v době jeho spouštění, nebo uděláš snap FS s databází. Výsledek bude úplně stejný, jen ve druhém případě získáš přímo kopii db serveru. Ale obsah db bude shodný.

Konzistenci na urovni 3) musi zajistit tvurce, prave tim, ze spravne pouziva transakce. Pokud je pouziva blbe nebo vubec, pak to presne podle toho vypada.

No jasně, ale tohle nesouvisí vůbec s fs ani s db. Pokud někdo commituje do db změny, které způsobí, že z hlediska jeho business modelu jsou ta data nekonzistentní, tak před tím ho nic nezachrání. Tj pro tuto diskusi irelevantní bod. Transakce slouží pro atomickou transformaci dat z jednoho konzistentního stavu do jiného konzistentního stavu.

Jinak receno, to co delas naprosto PRESNE odpovida tomu, ze server natvrdo vytrhnes z elektriky, a pak cekas, co bude, az ho zas zapnes.

To není tak zcela pravda. Po výpadku je samotný fs v nekonzistentním stavu a je potřeba pustit fsck (automaticky při mountu) zatímco v případě snapshotu je ten fs v pořádku. Ale na obsah db to nemá příliš vliv, data db budou ve stavu poslední potvrzené transakce. Takže správná.

[j]

Cemu presne nerozumis na tom, ze to co pises je kravina a takhle to nefunguje? Snap ti zajisti POUZE a PRESNE to, co sem psal === budou konzistentni ty soubory. V nich muze byt naprosto libovolny bordel.

KAZDA normalni databaze, pouzivat system log -> data.

Kazda normalni databaze (myslq mezi ne nepatri, proto se neda zalohovat), naladuje transakci NEJDRIV do logu a teprve PAK do dat. A KAZDA normalni databaze UMI dokoncit bezici transakce, zapsat je do dat, a presne v tenhle okamzik az do odvolani ZASTAVI zapis do dat, a zapisuje POUZE do logu. A PRESNE v tenhle okazik muzes udelat snap. Kdyz je hotovo, reknes databazi ze je hotovo a tim ji vratis do beznyho rezimu. Kazda normalni na to totiz ma primo API a tim padem i "vi", ze probehla zaloha.

Nekdy bezi databaze v rezimu, kdy se prave presne az do kompletni zalohy uchovava v logu vse, co se udalo od posledni zalohy a pri pripadny obnove lze tudiz ukazat i na zcela konkretni transakci a rict ze se to ma obnovit prave az k ni.

A pokud to presne takhle nedelas, prijdes o data, jak trivilane snadny. Prijdes o ne v rozahu tech prave bezicich transakci, ktery nejsou kompletne zapsany a tudiz ziskas nekonzistentni databazi, protoze do tech souboru se ty transakce taky nezapisou lusknutim prstu, takze to co se tam prave zapisuje, presne to se pri obnoveni ty databaze (pokud to umi, ne kazda to prezije) zahodi. A samozrejme presne takhle muzes tu databazi dostat i do stavu, kdy proste chcipne, a tvoje takzvana "zaloha" bude naprosto khovnu, protoze ji vubec nepripojis.

BTW: A ne, ZADNA normalni databaze nepotvrzuje transakci az po zapisu na disk, protoze to, jestli se vubec neco na disk zapsalo ani nemuze vedet, a navic by tim padem byla zcela nepouzitelne pomala. Stejne tak ti zadnej normalni disk, nepotvrdi to, ze data jsou na plotne, ale pouze to, ze je ma v cache. A presne stejne se chova kazdy diskovy pole. A kupodivu presne proto, se vse pripojuje na UPSky, radice maji baterky atd atd.

---

Dete s tim guuglem dopice!

[Heron]

KAZDA normalni databaze, pouzivat system log -> data.

Ano, a vrátí potvrzení o provedeném commitu tehdy, pokud jsou data v logu. Tedy na fs, který lze snapshotovat.

A KAZDA normalni databaze UMI dokoncit bezici transakce, zapsat je do dat, a presne v tenhle okamzik az do odvolani ZASTAVI zapis do dat, a zapisuje POUZE do logu.

Ano, a tohle dělá ten zmiňovaný pg_start_backup v případě, že je potřeba kopírovat base soubory, tedy to, co ty nazýváš data, běžnými kopírovacími nástroji.

A PRESNE v tenhle okazik muzes udelat snap.

Nikoliv, snap můžeš pořídit kdykoliv. V tento okamžik je možné použít běžné kopírovací nástroje, protože db je ve stavu, kdy nemění base soubory.

Nekdy bezi databaze v rezimu, kdy se prave presne az do kompletni zalohy uchovava v logu vse, co se udalo od posledni zalohy a pri pripadny obnove lze tudiz ukazat i na zcela konkretni transakci a rict ze se to ma obnovit prave az k ni.

PG umožňuje odlévat wal logy jinam a na základě starší base backup a uchovaných wal logů potom obnovit db k číslu konkrétní transakce. Psal jsem o tom zde, a existují i prográmky, které to nastavení ulehčí (asi jak pro koho), a psal jsem o tom zde. Prosím povšimněte si data vydání článků před tím, než mi budete psát, že existují i mnohem lepší možnosti.

A pokud to presne takhle nedelas, prijdes o data, jak trivilane snadny.

Nepřijdeš, protože db si ukládá wal logy se všemi potvrzenými transakcemi a po např. výpadku proudu vyleje tyhle wal logy do base souborů. Data zůstanou ve stavu poslední potvrzené transakce.

Prijdes o ne v rozahu tech prave bezicich transakci, ktery nejsou kompletne zapsany a tudiz ziskas nekonzistentni databazi, protoze do tech souboru se ty transakce taky nezapisou lusknutim prstu, takze to co se tam prave zapisuje, presne to se pri obnoveni ty databaze (pokud to umi, ne kazda to prezije) zahodi.

Nepřijdeš, protože ta data jsou stále v logu. Z logu zmizí až po té, co jsou base soubory řádně upraveny. Tebou navrhovaný log, který by se mazal ještě před tím, než jsou data zapsána do base souborů, by byl dost k ničemu. Ten log je tam právě od toho, aby se do nej zapisovali změny a ty šly potom zapsat do base souborů.

A ne, ZADNA normalni databaze nepotvrzuje transakci az po zapisu na disk, protoze to, jestli se vubec neco na disk zapsalo ani nemuze vedet, a navic by tim padem byla zcela nepouzitelne pomala.

Každá acid databáze potvrzuje transkaci až po zápisu na disk a právě proto je tak pomalá. wal logy se používají z důvodů, že úprava base souborů je pomalejší, protože jejich struktura je stavěná zejména na rychlé vyhledávání, takže se změny nejdříve logují do linerární sekvence logů, kam stačí jen rychle appendovat a flushnout. Až následně se jejich obsah (který je ale v běžném běhu db v paměti, takže se již nečtou z disku), hromadně vyleje do base souborů. Na tohle ale už klient nemusí čekat.

Stejne tak ti zadnej normalni disk, nepotvrdi to, ze data jsou na plotne, ale pouze to, ze je ma v cache.

Write cache se u disků vypíná. Jinak hrozí rozsypání nejen DB, ale i celého fs. Právě na to, že některé disky vracejí potvrzení zápisu jen po nalití do write cache, se přišlo během vývoje fs typu btrfs nebo zfs. Tyto fs potřebují mít spoleh (zejména v multidevice konfiguraci), že data, která mají být zapsána, skutečně zapsána jsou. Tímto se tedy přišlo na vadný HW.

[Jendа]

Jinak receno, to co delas naprosto PRESNE odpovida tomu, ze server natvrdo vytrhnes z elektriky, a pak cekas, co bude, az ho zas zapnes. Presne takhle vypadaji tvoje "zalohy".

Ano, přesně tak to dělám, a myslím si, že je to v pořádku. Aplikace by se snad měla umět vypořádat s náhlým ukončením (výpadek elektřiny, pád operačního systému), ne?

[j]

Jasne, takze ocekavas, ze kdyz prave ladujes 100GB dat z ramky na disk, takze se po odpojeni elektriny ty data na ten disk jeste zapisou .... zajimavej pristup.

---

Dete s tim guuglem dopice!

[Jendа]

Pokud má nějaké dotazy či připomínky někdo další než j, rád si o nich popovídám.

[Peter Golis]

Takýmto hazardom prídete minimálne o transakcie ktoré boli potvrdené, ale ešte sa z RAM nedostali na disk. Ale chápem že to je pri spiacich DB serveroch minimáne riziko.

Ten konzistentný štart (ACID) je len o žurnále ktorý zahodí takto stratené transakcie.

No neviem, ja som pričuchol ku databázam niekedy okolo roku 97, a zálohovaním som sa priamo živil len 15 rokov. Takže obdivujem vašu prax, odvahu, a postoj ku zvereným dátam.

PS: Mladý pán, naozaj podľa vás bude v Informixe fungovať tá vaša rada s zálohovacou funkciou s PostgreSQL? To by som si pozrel. Viete urobiť aspoň fotku obrazovky, alebo chápete rozdiel medzi Informixom a PostgreSQL?

[Heron]

Takýmto hazardom prídete minimálne o transakcie ktoré boli potvrdené, ale ešte sa z RAM nedostali na disk. Ale chápem že to je pri spiacich DB serveroch minimáne riziko.

Pokud to admin o svém databázovém produktu ví, tak jistě nebude používat diskové snapshoty. DB, se kterými pracuji já (tzn primárně postgresql), potvrzuje transakce až po té, co jsou zapsány na disku. A docela by mě zajímal seznam db produktů (sql, relační, acid), které potvrzují klientům transakce jen na základě přijetí dat do paměti. Toto automaticky nesplňuje durabilitu.

No neviem, ja som pričuchol ku databázam niekedy okolo roku 97, a zálohovaním som sa priamo živil len 15 rokov. Takže obdivujem vašu prax, odvahu, a postoj ku zvereným dátam.

Já jsem jenom 12 let provozoval tisíce služeb a několik desítek db o objemu několik TB v režimu licence/akreditace dle zákona v certifikovaném prostředí. Bez výpadku, bez jediného incidentu, bez jediné ztráty dat způsobeným selháním serverů nebo záloh.

naozaj podľa vás bude v Informixe fungovať tá vaša rada s zálohovacou funkciou s PostgreSQL

Já jsem o Informixu nenapsal ani slovo a vůbec jsem se k němu nevyjadřoval.

[Peter Golis]

Pokud to admin o svém databázovém produktu ví, tak jistě nebude používat diskové snapshoty.

Ale snapshot fs je nejlepší nápad.

Mám rád ľudí s vysokou dávkou sebareflexie.

Bez výpadku, bez jediného incidentu, bez jediné ztráty dat způsobeným selháním serverů nebo záloh.

V tom prípade ste dieťa šťasteny. Pozdravujte mamičku, asi sa o vás príkladne stará.

Já jsem o Informixu nenapsal ani slovo a vůbec jsem se k němu nevyjadřoval.

Túto vetu nerozporujem, ale dávam do pozofnosti fakt že sa jedná o otázku viazanú na Informix. Takže odpoveď s radou na štart PostgreSQL backupu je viac ako bezcenná.

[Heron]

Ulevilo se vám?

Túto vetu nerozporujem, ale dávam do pozofnosti fakt že sa jedná o otázku viazanú na Informix. Takže odpoveď s radou na štart PostgreSQL backupu je viac ako bezcenná.

Jistě jste si stačil všimnout, že zdejší diskuse mají stromovou strukturu a že jsem nereagoval na tazatele, který navíc ve svém dotazu informix nespecifikuje, ale že reaguju na komentář od Jendy (který sám uvádí na zálohovaném serveru použití snapshotů) a doplnil jsem jej v tom, že některé db produkty lze uvést do stavu vhodného i pro použití kopírovacích nástrojů a pro příklad jsem uvedl příkaz z PGSQL.

Ale váš zájem o tuto diskusi je evidentně zcela jiný. Je to škoda, protože jste místo osobních výpadů mohl uvést db produkty, které mají jiné vlastnosti a uvést jejich specifika a náležitosti třeba k zálohování.

[Peter Golis]

Aha, takže keď vás niekto upozornil že píšete odveci a riskujete tak nielen vám zverené dáta, tak to beriete ako osobný útok. Ďakujem, dávam si vás radšej na blocklist aby som vám znova nestúpil na otlak.

O tom že Jenda na ktorého ste reagoval písal na rozdiel od vás k veci, a že zadávateľ témy dodatočne špecifikoval použitú databázu sa už nemusíme baviť. Bolo by to hádzanie hrachu na stenu.

[jan.rok]

Problém konzistentní DB jsem neřešil: před začátkem zálohování jse všechno zastavil a pak zase spustil. VEEAM se s běžícím Informixem vyrovnat neumí.

Samozřejmě dump do souboru je taky dobrá pojistka.

[Peter Golis]

Jáj, offline backup. Ten je niekedy výhodnejší, keďže pri správnom poradí vypnutia služieb a synchronizácii do snapshotu zaručí konzistenciu jak DB, tak ekosystému aplikácie ktorá využíva danú DB.

Ovšem za cenu výpadku služby, čo je nie vždy žiadúce. To ale nie je tento prípad.

[Jendа]

Tak v tom případě rsync -HXS --numeric-ids -avzhPe ssh --exclude /proc --exclude /sys --exclude /run --exclude /tmp --exclude /dev root@stroj:/ /mnt/backup a hotovo, ne?

[Jendа]

A pro příště si tam dej LVM nebo btrfs nebo jiný způsob, jak udělat snapshot za běhu, protože se jako fakt může stát, že po tobě někdo bude chtít systém, který se každou noc na půl hodiny nevypne . (a když už jsme u toho, tak se vykašli na HW RAID)

[Peter Golis]

Veeam mal v sebe žurnálovanie na spodnej úrovni blokovej vrstvy už keď chlapi dali výpoveď vo VMware a založili si vlastnú firmu. Takže tá pol hodina je nadhodnotená.

I keď neviem či to zamontovali aj do zadarmovej edície, nepoužívam ten produkt.

[jan.rok]

Server jsem zdědil.

NAME                           MAJ:MIN RM    SIZE RO TYPE MOUNTPOINT
sda                              8:0    0  558.9G  0 disk
└─sda1                           8:1    0  558.9G  0 part
  ├─rhel--raid1-max_maxp_spool 253:9    0      8G  0 lvm  /max/maxp/spool
  ├─rhel--raid1-IDSLOGS        253:10   0     32G  0 lvm  /IDSLOGS
  └─rhel--raid1-data1          253:11   0  518.9G  0 lvm  /data1
sdb                              8:16   0    1.7T  0 disk
├─sdb1                           8:17   0 1023.8M  0 part /boot/efi
├─sdb2                           8:18   0      2G  0 part /boot
├─sdb3                           8:19   0    1.6T  0 part
│ ├─rhel--raid5-root           253:0    0     32G  0 lvm  /
│ ├─rhel--raid5-swap           253:1    0     16G  0 lvm  [SWAP]
│ ├─rhel--raid5-home           253:2    0      2G  0 lvm  /home
│ ├─rhel--raid5-var            253:3    0     12G  0 lvm  /var
│ ├─rhel--raid5-tmp            253:4    0      4G  0 lvm  /tmp
│ ├─rhel--raid5-max            253:5    0     16G  0 lvm  /max
│ ├─rhel--raid5-max_maxp_homes 253:6    0     12G  0 lvm  /max/maxp/homes
│ ├─rhel--raid5-IDSDATA        253:7    0    120G  0 lvm  /IDSDATA
│ └─rhel--raid5-data2          253:8    0    1.4T  0 lvm  /data2
└─sdb4                           8:20   0   54.5G  0 part
  └─rhel--raid5-max_maxp_homes 253:6    0     12G  0 lvm  /max/maxp/homes

rsync vyzkouším

[Jendа]

No super, tak to (pokud máš v PV trochu volného místa, nebo si ho dokážeš udělat) můžeš zálohovat skutečně za běhu (pokud nevadí, že snapshoty jednotlivých LV nebudou konzistentní vůči sobě - e.g. /IDSDATA bude konzistentní, /data2 taky, ale navzájem ne - nevím samozřejmě co kde máš nainstalované a jestli to vadí). Uděláš snapshot (lvcreate -s), namountuješ ho (raději readonly) a rsyncneš.

[Josef Kufner]

... a pak ten snapshot smažeš.

[j]

Veeam (ale ne ten zadarmo) ma pro ruzny databaze primo pluginy (za dalsi $$$). Ale ta funcionalita je teda zalostna. V principu by to melo delat presne to, co Heronovi vysvetluju vejs = vyuzije to API databaze a vytvori to konzistetni zalohu. Coz je teda v pripade veeamu ciste teorie, protoze mnohem pravdepodobnejs ti to sejme celej server. Kuprikladu na M$ SQL to prepne SQLko do rezimu jakysi replikace (to by vubec delat nemelo) a pak uz ho to z nej nikdy nevyhodi. A protoze to nebyl schopnej vyresit ani (placenej) support, tak byl celej veeam v tomhle pripade poslan doprdele.

Paradne to fungovalo s falconstorem, tam ty databaze normalne zalogovaly backup a na jejich provozu si to vubec nezaznamenal. Jen je to ponekud narocny na $$$ (platis licenci na kazdej stroj co chces zalohovat a extra samo na kazdou databazi, platis licenci za kazdy GB ktery chces zalohovat ... ) ;D.

---

Dete s tim guuglem dopice!

[jan.rok]

Tohle nemůžu potvrdit ani vyvrátit. Ale setkal jsem se s obnovou fyzického serveru zálohovaného VEEAM, kde byl i MS SQL, a obnova proběhla normálně. Zálohování tehdy probíhalo tuším v noci, kdy byl i MS SQL stále v plné práci. Šlo o obnovu na jiný fyzický server (stejné konfigurace), starý odešel po zkratu na elektroinstalaci i s UPSkou.

[Peter Golis]

Pokiaľ to MS SQL bolo na disku kde malo VSS writery a Veeam ich aj použil, tak to bolo v konzistentnom stave. Vytvorenie VSS snapshotu na DB disku povie MS SQL DB že bude zálohovaná. Teda ju prepne buď do módu backupu, alebo ju na chvíľu vypne (závisí či má aktívne transakčné logy).

Ale to nie je z pochopiteľného dôvodu podporované na Linuxe.

[j]

Ehm ... ne. Precti si dokumentaci, ani sami soudruzi v M$ tohle nepovazujou za bezpecnej zpusob zalohovani. Mas tam primo napsany, ze nijak negarantujou, ze takova zaloha bude konzistentni.

Opet stejne jako u btrfs, vss ti jen zaridi, ze bude konzistentni FS, nikoli ta databaze. Navic abys tohle vubec moh pouzivat aniz bys tu databazi sejmul, je podminkou, ze logy jsou na jinym disku (jiny partysne) nez data.

Jak sem psal vejs, veeam ma pro ucely konzistentniho zalohovani databazi pluginy.

Jinak vss je stejne "spolehlivy" jako vse od M$, takze ...

BTW: M$ SQL ma transakcni logy zcela vzdy. Jen se da vybrat, jestli databaze bude v rezimu simple, bulk nebo full. Rozdily spocivaji prave v nakladani s transakcnim logem a moznostma pripadny obnovy.

[Peter Golis]

Ďakujem za ponuku, ale tú dokumentáciu som čítal už pred rokmi. Živil som sa multiplatformným zálohovaním a vecami s tým spojenými. Ono by to bolo konzistentné keby sa VSS snapshot vytvoril naraz pre všetky DB disky.

A preto rozumný SW použije API pre DB, cez ktoré vykoná zálohu ktorú si pošle na svoj kanál. A to nielen pre MS SQL, ale aj napríklad pre Oracle DB bežiace vo Win.

[sigma]

To je fajn, taky to podobně dělám. Ale pokud se bavíme o zálohování "celého fyzického serveru", mám stejně pořád problém. Resp. já ne, ale pokud bych to chtěl předat někomu méně znalému, kdo by měl být schopen udělat obnovu na nový HW, tak musím zazálohovat a umět spolehlivě (tj. ne ručně) obnovit:

- partition layout všech disků - mdraid - lvm - vytvoření filesystémů se správnými parametry - nahrát ty správné adresáře ze zálohy na ty správné filesystémy

Můj typický server obsahuje všechny tyto vrstvy. Obvykle mám uložené poznámky jak jsem to instaloval, případně rovnou skript. Ale chtěl bych to umět nějak vytáhnout z živého systému pro pozdější (polo)automatickou obnovu. Protože v průběhu provozu toho serveru se třeba disky přidávají, a do instalační dokumentace se to třeba zapomene doplnit.

Samozřejmě se to komplikuje ještě víc, pokud je HW pro obnovu trochu jiný.

Pro začátek by asi stačil skript, který tyhle všechny informace vytáhne a uloží, a bude to součást zálohy. Aby se při ručním obnovení bylo kam podívat, jak to doopravdy bylo nastavené. Používá někdo něco takového?

[Josef Kufner]

Já obnovu řeším minimální instalací stejného systému a rsyncem zpět ze zálohy přes ten minimální systém. Instalátor pořeší oddíly a bootloader, rsync ten zbytek. Ale používám to na notebook s jedním diskem o víceméně defaultním rozdělení.

S příchodem cloudu se tento problém řeší opačně: Napíše se skript, který sestaví server (kontejner) s požadovanou službou. Živý systém je pak něco, co se občas prostě zahodí a sestaví znovu. Aktualizace nejsou, je nové sestavení. Tento přístup má docela zajímavé vlastnosti, ale aby to skutečně zazářilo, je potřeba tomu dopřát dostatek infrastruktury a automatizace.

[Jendа]

Můj typický server obsahuje všechny tyto vrstvy. Obvykle mám uložené poznámky jak jsem to instaloval, případně rovnou skript. Ale chtěl bych to umět nějak vytáhnout z živého systému pro pozdější (polo)automatickou obnovu. Protože v průběhu provozu toho serveru se třeba disky přidávají, a do instalační dokumentace se to třeba zapomene doplnit.

A ten nový server, na který se to bude obnovovat, bude mít konfiguraci disků jinou… Lepší je to obnovit ja kse hodí a pak upravit fstab (a crypttab pokud je to šifrované). Všechno ostatní (LVM, MD a příslušné nastavení GRUBu) se minimálně na Debianu detekuje automaticky při update-initramfs a update-grub.

[Josef Kufner]

Už pár let používám rsync po ssh a BTRFS snapshoty a předtím jsem používal mnoho let rsync --link-dest (tj. deduplikace pomocí hardlinků). Je to velmi jednoduché a spolehlivé. Jen je potřeba si napsat vlastní zálohovací skript a šoupnout ho do cronu.

[pavele]

Na CentOS 7 jsem používal modul kernelu hcp od r1soft, něco je tady:

https://the-d2.com/how-to-install-r1soft-agent-on-centos-8/

Umí to snapshot na ext4 (měl jsem RAID1) - vytvoří přípojný bod, kam připojí snapshot. Ten jsem zazálohoval pomocí rsnapshot a snapshot zase odpojil.

[bigBRAMBOR]

ono je pro RHEL 8.4 jádro 5.8? Myslel jsem ze 4.18 je pro 8 a tu budou šudlat celou dobu. Oracle do toho vzdycky cpal novejsi jádra.

[jan.rok]

Chyba hned v úvodu: samozřejmě v RHEL 8.4 není jádro 5.8. Popletl jsem to: správně mělo být, že VEEAM zatím nepodporuje RHEL 8.4 anebo něco s jádrem 5.8. Omlouvám se. Ale na podstatě dotazu to nic nemění.