Zálohování stále se měnících velkých dat

[darebacik]

Ako je zname, tak slovensky kataster mal udajne hackersky utok typu ransomware. Ak by mali v poriadku zalohy, tak zrejme do niekolkych hodin by to mali nahodene. Po utoku je uz tyzden a stale im to nefunguje.
Zatial nie je za to nikto zodpovedny a predpokladam, ze vinu hodia na opoziciu ako obvikle.

Zaujmaju ma skor technikalie ako sa zalohuje  v takychto spolocnostiach, kde sa udaje v databazach menia takmer neustale.
Uvadza sa, ze vzdy musia byt zalohy aspon na 3 miestach. Predpokladam, ze lokalne, dalej na nejakom cloude a na offline mediach.

Vezmime si napr. banky, kde sa vykonava denne 100 000-ce transakcii. To snad ani nejde zalohovat na nejake offline media. Nedajboze by banku postihol ransomware, tak to by bola asi katastrofa a krach banky, keby boli bez zaloh.

Ak sa robia zalohy offline kazdu hodinu, alebo kazdy den, tak tomu samozrejme rozumiem, ale v pripade napadnutia hackermi musi byt aj ta posledna transakcia na offline medii, inak bude stratena.

[Reklama]

[Michal Šmucr]

Samozřejmě banka (resp. jakýkoliv subjekt) má více kategorií dat a u každé by pak měla být odpovídající strategie zálohování - včetně RTO (kolik času trvá, než se to obnoví) a RPO (jak stará data ještě můžeš ztratit, aby tě to neohrozilo, např. prezentace z marketingu stačí ze zálohy jeden den zpátky, některá data potřebuješ z poslední hodiny, a jinde je to nula).
Tomu jak to má daný subjekt naplánované tak, aby případná havárie nebo útok neohrozila jeho fungování se obvykle říká BCP, Business Continuity Plan, kde by to mělo být vcelku detailně popsané co a jak dělat včetně třeba i školení obsluhy atp.

Na data v vysoce dostupných transakčních systémech v podstatě nelze použít nic jiného než nějakou formu synchronní replikace (tzn. transakce se nedokončí dokud to není zapsané ve dvou či více systémech) ideálně v součinnosti s CDP (continous data protection) - https://en.wikipedia.org/wiki/Continuous_data_protection kdy se ještě jinam ukládají data včetně kompletního logu všech operací/transakcí a s možností případného návratu zpět (což je nutné v případě nějaké logické chyby, smazání atp).

[Zopper]

K tomu asi nemám, co dodat, pěkně shrnuté.

Ako je zname, tak slovensky kataster mal udajne hackersky utok typu ransomware. Ak by mali v poriadku zalohy, tak zrejme do niekolkych hodin by to mali nahodene.

I pokud mají kompletní zálohy, tak obnovení může být tady na hodně dlouho:

• Ze všeho nejdřív je potřeba zabránit potvorákovi v šíření. Což ale obrovsky zpomalí jakékoliv další kroky s napadenými systémy, protože všechno je vypnuté.
• Pak musíš zjistit, jak se potvorák dostal dovnitř, vykopnout ho ven a zajistit, že se nevrátí vzápětí tím stejným oknem, kterým vlezl předtím.
• Pokud máš dost zdrojů (lidi, stroje, licence, peníze), můžeš startovat paralelní infrastrukturu a chystat ji ze záloh v oddělené lokaci/síti, zatímco napadená síť je pořád dole. Pokud nemáš, musíš počkat na vyčištění napadených strojů.
• Studená instalace a start komplikovaného systému může být práce na dny i pokud ti u toho sedí tým lidí 24 hodin denně na směny a jednou podle kuchařky krok za krokem bez improvizace. Jestli není testovaný recovery plán, a tohle se dělá za pochodu, přičemž lidi, co kdysi něco zavedli už nejsou kolem, a nikdo neví, jaké má co závislosti... Hodně štěstí, uvidíme se za měsíc.
• A v tomhle případě je možná potřeba fyzicky obejít všechny klientské stroje v kancelářích úředníků, což přidává další hromadu práce a času. J

[jjrsk]

Sak RSD taky prisli o vsechny data vcetne zaloh a zodpovedny za to neni nikdo ....

Jinak dela se to jak tu bylo zmineno tak, ze mas treba dve primarni storage, ktery se mezi sebou replikujou. To ti resi ten prvni level (vcetne pripadne umreni storage). Typicky samo budou v jinych lokalitach, takze by te nemela ohrozit ani voda v casablance ... teda pokud si to delas sam, a neveris jim.

Takovej ten prvni level backupu pak muze byt primo na primarni storage v podobe snapshotu. Takze pokud narazis na nejaky rekneme soft problem, muzes to resit rovnou tak, aniz bys muse nejaka data odnekud presunovat.

Zalohovani jako takovy pak samozrejme probiha na nejaky dalsi storage, ktery bezej na jinych systemech, a typicky proste posilas stream diffu. Jedinej zasadnejsi rozdil proti primarnimu storage je ten, ze zaloha defakto generuje vicemene linearni zapis. Tady pochopitelne nema smysl drzet nejakou silenou historii jednoduse proto, ze den stara data muzou byt uz nepouzitelne stara.

Z tyhle zalohy se pak v nejakych intervalech odsypavaji data jeste do archivu, kde drzis nejakou historii.

V kazdym pripade to funguje zcela automaticky a nikdo nic nikam nenosi. Jednoduse proto, ze jakejkoli lidskej faktor = nebude to fungovat.

V kazdym pripade si musis uvedomit, ze cim vic dat mas, tim vetsi problem znamena obnova backupu. Ona totiz zadna konektivita neni dostatecne nekonecna.

[lazywriter]

Vezmime si napr. banky, kde sa vykonava denne 100 000-ce transakcii. To snad ani nejde zalohovat na nejake offline media. Nedajboze by banku postihol ransomware, tak to by bola asi katastrofa a krach banky, keby boli bez zaloh.

Zrovna u bank je objem celkem triviální. Transakce je pár čísel (kdy, od koho, komu, kolik ..). Pochopitelně se musí řešit integrita těch dat atd., ale objem v dnešní době nestojí za zmínku. I ty počty (i kdyby byly o několik řádů jinde) jsou relativně malé (a to i v případě několikaleté historie). Kdejaká malá reklamní síť, monitoring zákaznických zařízení, datový sklad apod. musí řešit větší objemy. Proto mají pokročilejší zálohování mechanismy (přírůstkové, rozdílové zálohování, virtuální fullbackup ad.)

[Reklama]

[Ivan Brezina]

Velke databaze jako Oracle, SQL Server anebo Postgre maji transakcni logy ktere se taky zalohuji. Diky tomu je pozny PITR (point in time recovery). Databazi je mozne obnovit k libovolnemu bodu v historii.

Bankovni aplikace maji vlastni "ucetnictvi". Jako za na jedne strane je "ma dati" "dal" (nostro a vostro). Pokud by doslo ke zmene dat v jedne bankovni aplikaci tak by vznikla dikrepance s hodnotami v jine aplikaci anebo s hodnotami z vypisu z uctu i jine banky.

[honzako]

Nebudu popisovat principy zálohování, těch je všude plno. Stačí si dohledat Veeam.
Nicméně banky kdysi zálohovaly na WORM média "Write Once, Read Many", dnes existují i SD karty.

Jinak jsem si jist že banky využívají služeb AWS a produkt S3, či podobné.
Největší nebezpečí zcizení dat je totiž ve vlastních zainteresovaných zaměstnancích, než v cizích datacentrech kde jsou data zašifrovaná.

[czmiho]

sa udaje v databazach menia takmer neustale.

Ty systémy se navrhují tak, aby se data nikdy neměnila a nemazala. Pořád jen přibývají nové transakce. Storno platby nic nemaže - je to nová transakce. Změna adresy klienta nic nemění, je to nová transakce. To zálohování velmi usnadňuje. Aktuální stav můžeš mít někde nacachovaný, ale zálohovat ho nemusíš.

Mimochodem s tím množstvím dat v bankách to není tak hrozné. Velké retaily jako Kaufland třeba jich mají řádově více (celosvětově Walmart a Amazon) . O visa/mastercard nemluvě.

Pokud se bavíme o netransakčních datech, tak samozřejmě YT - jediné czechcloudovo reakční video je větší, než denní datový objem transakcí celé banky ;-)

[jjrsk]

Velke databaze jako Oracle, SQL Server anebo Postgre maji transakcni logy ktere se taky zalohuji. Diky tomu je pozny PITR (point in time recovery). Databazi je mozne obnovit k libovolnemu bodu v historii.

Ne tak uplne, ty si muzes vybrat casovy okamzik mezi transakcemi. A to samo o sobe ale nemusi stacit. Protoze zdaleka ne kazda aplikace transakce pouzivat umi. Tudiz sice muzes mit z pohledu databaze konzisteetni data, ktera ale nebudou konzistentni z pohledu aplikace.

Pricemz je treba si uvedomit i to B. Pokud proste obnovis backup, tak je casova narocnost dana vicemene ciste objemem tech dat. Pokud si zacnes hrat s transakcema, tak ten stroj nedela nic jineho, nez ze na ta data aplikuje kazdou jednu transakci az do vybraneho okamziku. A to pochopitelne obnasi i pripadne veskere vypocty atd atd.

[jjrsk]

Aktuální stav můžeš mít někde nacachovaný, ale zálohovat ho nemusíš.

Viz vejs, kdybys to delal prave takhle, tak ti obnoveni aktualnich dat bude trvat mesice ... ty mesice pobezi aplikovani veskery ty historie.