Vlákno názorů k článku GitLab měl pět zálohovacích mechanismů, nefungoval ani jeden od Antibackup - Neviem co sa vlastne riesi pri zalohovani par...
-
Antibackup (neregistrovaný)
Neviem co sa vlastne riesi pri zalohovani par smiesnych (300GB) dat ako bolo v clanku(aj keby to bolo 300TB tak su to uplne v pohode data). Nielen ze v pripade dobre postavenej infrastruktury zalohovat explicitne nepotrebujete lebo samotne udaje mate x nasobne replikovane vratane metadat a vyuzivate ci uz active-passive(realtime repl) alebo active-active clustre pri tychto udajoch vratane rozdielnych geolokacii(legislativna potreba napriklad) alebo pri niektorych objemovch(alebo velocity problemovych udajov) udajov ani nie je realna moznost klasickeho zalohovania.
Proste si spocitate risky, operacne straty, technicku liability a pod... a moze vam uplne normalne z toho vyjst ze zalohovanie udajov a trapenie sa napriklad s HSM je nezmysel a hudba minulosti.
Principom modernych pristupov je ze standardna problematika zalohovania a obnovy nema ani nastat kym nenarazite(pri poziadavkach) na naozaj specialny pripad(napr extremne retencne doby spojene s poziadavkov na stabilitu ulozneho media).
A to sa netyka len klasickych udajov ako si ich predstavuje vacsina ludi ale samozrejme aj sposobu realizacie sluzieb a exekucnych environmentov na infrastrukture. Klasicke trapenia s povodnymi postupmi by mali byt uz najme v legacy aplikaciach kde z hladiska ich staroby nie je ina moznost. -
j (neregistrovaný)
"... pripade dobre postavenej infrastruktury zalohovat explicitne nepotrebujete ..."
jo, to urcite ... ty zjevne vubec nemas paru, proc se zalohuje ... co myslis se ty mamlase stane, kdyz nekdo posle do databaze v 10 clusterech ... delete * ? Nj, zazrak, smazou se vsechny data ... vsude ...
-
Ivan (neregistrovaný)
S rostoucim objemem dat se zacina "klasicke" zalohovani prezivat. Ani 10Gbit nedokaze prenest tak velke objemy.
Napr. pri zapisove rychlosti 280MB/sec obnovite max 1TB dat za hodinu. 300TB dat byste obnovoval 300 hodin. Takze dnes nezbyva nic jineho nez nejaka forma online replikace na zalozni system s podporou snapshotu(flaskbacku). Zaroven ale casto muzete narazit na to, ze nechcete obnovit cely system, ale pouze malou cast (soubor, tabulku). A i v tomple pripade potrebujete ziskat neco konzistentniho a to uz nejde bez podpory aplikace. -
rich (neregistrovaný)
"Ani 10Gbit nedokaze prenest tak velke objemy.
Napr. pri zapisove rychlosti 280MB/sec obnovite max 1TB dat za hodinu. 300TB dat byste obnovoval 300 hodin"
JJ, neni nad to si prizpusobit fakta :-DJak dlouho tedy bude trvat zaloha/obnova 300TB databaze, pokud mohu zapisovat/cist soucasne treba na/z 10 pasek LTO7 soucasne?
-
j (neregistrovaný)
Zaloha je zaloha, je uplne jedno jak je technicky realizovana. Jsou to data na oddelenym zeleze ke kterymu provozni system nema vubec pristup. Jinak to neni zaloha.
Pricemz se zadny obnovovani nekona, protoze pokud by primarni zelezo nebo data na nem chciply takovym zpusobem, ze by bylo treba pouzit "fullbackup", tak se jednoduse provoz spusti prave z toho zalozniho zeleza primo.
Coz sem mimo jiny i osobne realizoval ... je to primitivni, a provoz lze obnovit v radu jednotek minut.
Co se tyce dat samotnych, kazda svepravna databaze ma api, ktery umozni pozastavit zapis a udelat konzistentni snap. A kdyz na to prijde, da se ukazat i na zcela konkretni transakci.
Pokud se chce ziskat jen cast dat, tak se uplne stejne primitivne backup (konkretni snap) pripoji (klidne i RW, protoze zmeny sou jen docasny) a opet si tam muze admin nebo klidne i user vytahat to, co potrebuje. Opet, nic se nikam neobnovuje.
Pricemz prave proto se nepouzivaj pasky, protoze pasky je treba obnovovat vzdy, coz je khovnu kdyz to trva hodiny nebo i dny. Pasky se pouzivaj tak maximalne na archivaci ale ne jako backup.
-
Filip JirsákStříbrný podporovatelNeviem co sa vlastne riesi pri zalohovani par smiesnych (300GB) dat
Řeší se to, že pokud nejde o opravdu velké objemy dat, není problém v kapacitě, ale v tom, zda zálohování funguje správně (tedy mimo jiné automaticky) a ověřuje se (opět automaticky), že je možné udělat kompletní obnovu.Nielen ze v pripade dobre postavenej infrastruktury zalohovat explicitne nepotrebujete lebo samotne udaje mate x nasobne replikovane vratane metadat a
Právě že potřebujete, jak ukazuje mimo jiné tento případ. Když dáte příkaz ke smazání dat, ta data se smažou ve všech replikách (pokud vám replikace funguje správně). Replikování chrání proti chybám hardwaru, nikoli proti chybám lidí (ať už chyba v software nebo chybný příkaz). -
Petr M (neregistrovaný)
Což ovšem neřeší takový detail, že se v CRONu o půlnoci spustí skript s chybou když o osmi ráno z logu zjistíš, že je průšvih, tak je to 16x zreplikovaný (se zpožděním 30 minut).
A jaká prodleva je optimální? Minute? za tu nedoběhne delší operace s víc datama. Hodinu? Tam může být při poruše nezrcadlenýho HDD klidně 50 faktur, nahlášených s jejich číslem na FÚ...
-
No, jak psal nekdo vyse, pokud si to muze system dovolit, tak uchovavat nejakym systemem copy-on-write data do stari alespon jednoho dne. V terminologii postgresu to muze znamenat den replikacnich logu a mit to zamerne o den zpozdene. Pak to prehrat jen do konkretniho okamziku. Ale v praxi jsem nic takoveho nevidel.
-
Petr M (neregistrovaný)
Proč zálohování? Protože
- lidská chyba - příkaz rm maže i repliky.
- ransomware - když už něco zašifruje, odstraním červa, obnovím zálohu a jede se dál.
- chyba konfigurace nebo sw - nechtěně se přepíše, co nemělo. Snímek systému z doby před přepisem, vytáhnu konkrétní soubory nebo data a jede se dál (ťuk ťuk na dřevo, tři týdny jsem to nepotřeboval).Jde o to, aby ukládání dat nemělo jedno slabý místo, který zničí roky práce. To je v případě zrcadlení, replikace, RAIDu a podobné srandy příkaz, který něco pohnojí...
