Názory k článku GitLab měl pět zálohovacích mechanismů, nefungoval ani jeden

"Jedním příkazem tak služba přišla o 300 GB uživatelských dat."
" Výsledkem je smazaná produkční databáze (ne uživatelská data), ke které neexistuje snadno dostupná a dostatečně čerstvá záloha."

Tak jsou uživatelský data v čmoudu, nebo ne?

LOL zadna knihovna data necte ;-)))
nektere pasky previji, ale jen WORM na dlouha leta, kvuli magneticke interferenci.
CRC kontrola je na nic, paska vadne zapise data, pak je zkontroluje se stejnou chybou a CRC sedi, staci vadny buffer, stalo se na DLT mechanikach dodovane so HP pa-riscu ... a nenadelas nic, data obnovis, ale jen co je chces dat do databaze, tak jsou nepouzitelna ....

Jinymi slovi placas nesmysly o silech (knihovna zadnou logiku nema).
nejlepsi zalohy ma netapp, dela snapshoty a ty pak replikuje jinam, zaloha je tak 100%, zaloha na p0asky je OK, ale zdlohava, hracky jako TSM kde zalohujes datat jen jednou za zivot a pak foever increment5al je cesta do pekel, nebot po 5 letech neobnovis vse, nebot neco uz nepujde precist, nebo se omylem skartovalo, ackoliv se tomu TSM snazi zabranit media reclation, tedy ze stara data precte a zpise na jine pasky a ze uzdrzujes kazda datat napr. 2x a vicekrat ... jenze ne kazdy to dela ... kdyz mas kazdt tyden full, tak seice tahas data, ale 1. overujes integrity zivych dat 2 mas nekolik fullu, takze kdyz selze par souboru z cersve zalohy, je sance, ze budou aspon starsi.

Je a neni ... sezere to nejspis docela dost vykonu. Mineno predevsim tech disku. Takze pak se velmi snadno muzes dostat do situace, ze na takovehle backup potrebujes nasobne vykonejsi pole nez na samotnej provoz.

Zaplatis to? To sem treba takhle prisel za majitelem firmy a rek mu, ze je treba 1/2M na zalohovani* ... rek mi ze sem se zblaznil ... tak nezalohuje (to co se dela se za zalohovani povazovat neda ani s obema ocima v kyblu), ja sem zcela vpohode, jen chladim sampicko ... to az to chcipne abych mel cim to oslavit.

*tzn je teba nejen prostor kam zalohovat, s dostatecnouo historii a dost casto**, ale taky prostor, kam ty zalohy obnovit a kde otestovat ze sou pouzitelny.

**dost casto pocitam maximalne 15 minut, dyl si zadna normalni firma nemuze dovolit, to uz je moc velka ztrata dat, idealni je spis cdp.

> az to chcipne
tak ta vyhodia lebo si nezalohoval

To tezko, protoze narozdil od tebe delam to, co mam ve smlouve. A soucasti ty smlouvy je, ze mam upozornit na pripadny rizika, coz sem presne udelal a protoze narozdil od tebe nejsem debil, muzu to i kdykoli dolozit.

emailovou komunikací, která nebude zálohovaná :-)

Pokud to vychází z premisy že nejsi debil, tak silně pochybuji.

Tak tohle bych si nechal podepsat od sefa a uredne overit :D pac te jinak priprvnim problemu nakope do zadku.

Ja s tebou souhlasim, ze maly firmy maj proste problem se zalohama a defakto mas pravdu, ze je problem data vubec nekam zazalohovat natoz nekam obnovit.

Kdyz pominu ty problemy s tim, ze nechtej koupit dalsich 10 disku, ze si muzou dovolit jenom 5 disku ..... Jednu z nejlepsich "strategii" na obnovovani dat co jsem slysel je ve smyslu: "Kdo ma dneska cas a prostredky testovat obnovovani zaloh? No treba vasi vyvojari, davejte jim databaze a zalohy k obnove jako testovaci prostredi, nezatizite produkci, budete tam mit cerstva data a vite, ze to funguje".

Takze obnovovat zalohy, resp. je testovat muze skoro kazdy, protoze urcite nejaky ten testovaci server nebo nejake to misto najdete a kdyz sefovi reknete, ze to mate 2v1 tak si muzete nechat jeste pridat ;)

Pokud by byl problem, ze data jsou "tajna" tak se zacni shanet po novym zamestnani, protoze jestli ti na meetingu nereknou, ze se pokusi sami najit nejakou rozumnou cestu (post-test-recovery anonymizace dat napr.) nema to smysl s nima vubec resit. "Just let it burn".

Jenze ono to velice casto neni o tom co si muzou dovolit. Ono to je o tom, ze majitel si radsi koupi dalsi audi nebo volvo nebo ... za 2, 3, 4M ... ale 1/2M na zalohovani neda. Stejne tak mu nedela problem rozfofrovat 10, 20, 30M za marketing, o kterym ani netusi, jestli je vubec k necemu atd atd.

Nehlede na to, ze kdyz firma provozuje IT infrastrukturu na kterou nema, tak proste driv nebo pozdejs prestane existovat. Jen otazka casu.

Pricemz dneska je to tak, ze z kazdy stokoruny hodnoty firmy delaj 80 korun data. Nejaky zbozi? Haly? Stroje? To vsechno pripadne calne pojistovna a "lusknutim prstu" se to da koupit.

Takovy testovani jaky popisujes je prokocku, protoze se 100% jistotou az budes tu zalohu potrebovat, tak zrovna ta kterou budes potrebovat nebude pouzitelna.

Ale lidi sou nepoucitelny, zcela bez ohledu na rozsah ...

Chcipne disk? Vykutas mu z toho data a reknes at si koupi dalsi na zalohovani. Myslis ze to udela? Zapomen, za mesic prijde s dalsim chciplym diskem. A samo "nutne" ty data potrebuje.

Asi podle firmy. Protoze prijit za nekym ze chces 500 000kc na zalohovani je dost divne. Na malu firmu je to moc a velka ma vytvoreny postupy a strategii pro zalohu a obnovu dat. To neni jako ze nemaji nic, daji pul mega a najedno use zalohuje .... .

Doma to řeším tím, že se všechno důležitý v noci mirroruje NAS<->NTB a NAS<->Desktop. Hot data jsou na třech místech (není potřeba zálohovat 2x za hodinu, ztráta 24h je přijatelná) a 1x týdně spustím Unison mezi NTB a desktopem. Když nenajde rozdíl, píchnu do desktopu externí disk, mkdir datum, rsync, rm -r nejstarsi_zaloha a nazdar. Všechno jde tak nějak při běžné "práci" na desktopu, protože Linux zvládne multitasking a prokjekty jsou extra v GITu, tak se jich zálohy fotek nedotknou.

Ale to je hlavně o tom, jak moc si člověk váží dat...

Doma predevsim nemusis resit, ze potrebujes zalohu z pred dvou minut ... a s nejakou ztratou dat se smiris (vetsinou). Navic si prevazne aspon +- pamatujes, co si od ty posledni zalohy delal, takze vis, co kde je treba udela znova.

Doma taky neprovozujes vsemozne provazany a propojeny systemy ruznych dodavatelu, kde musis resit to, aby zalohy tech jednotlivych systemu byly konzistentni vuci sobe.

Odborne se tomu rika disaster recovery test. DR testy se deji na vsech urovnich od vybaveni datacentera, pres HW az po obnovu dat pro aplikace. A to posledni je co se tyka githubu.
Jaky neuveritelny amaterismus. Praxe,praxe,dlou­hodoba praxe v IT infrastrukture. To je to co tem lidem chybelo. Jinak by verifikaci zaloh delali aspon na jedne urovni.
Protoze kazdy z nas IT dedku na zacatku sve kariery uz minimalne jednou poznal situaci, kdy data v zaloze nebyla pouzitelna. V lepsim pripade pred katastrofou, v horsim pripade po ni.

V zakladu staci udelat verifikaci zaloh a jednou za cas DR test. Ono se totiz muze stat ze i pri prubeznem zalohovani dochazi k tomu ze nektera data se proste neodzalohuji. Zvlaste pomerne spatne diagnostikovatelne byvaji ruzne komplexni "lan free backup" zalohovaci mechanismy.

GitLab používá Ceph už teď a právě kvůli němu řeší migraci z Azure.

Nevím jak jim ceph pomůže proti nechtěnému smazání dat a starému snapshotu

Dá jim nástroje, aby se něčemu podobnému vyhnuli nebo když dojde k něčemu dalšímu, aby to šlo rychleji obnovit.

Zjavne nepresli celu cestu k osvieteniu.

http://www.taobackup.com/index.html

Tohle je nepříjemné a dokážu si představit, jak se teď cítí. Sice jsme si nikdy nevymazali data, ale taky jsme měli problémy se zálohováním, kdy jsme při pokusu o obnovu dat zjistili, že zálohy jsou prázdné a nebo se nedělaly. Většinou to dopadlo dobře, pomohla třeba náhoda, ale pak jsme narazili na situaci, kdy se nám data obnovit nepodařilo. Zákazník si je smazal a my je neměli. A tak jsme to nakonec vyřešili následovně:

* Nestandardní systémy odmítáme zálohovat - custom VPSka
* Infrastruktura je v Ansiblu
* Hodně věcí máme už v Dockeru, takže řešíme opravdu jen data
* Zálohy děláme do Btrfs, kde se po záloze dělá snapshot, tzn. že kopírování dat je jen rsync a historie se drží bez duplikování dat
* Zálohy jsou monitorovány, když nějakej command vrátí něco jiného než nula, hned o tom víme, navíc se posílá ping do monitoringu a když se nepošle, tak o tom taky víme
* Skripty jsou hodně jednoduché, 50 řádek na data a 70 řádek na databáze
* Zálohy jsou kompletních serverů včetně systému + SQL dumpy

Popsaný proces odzálohuje 20 serverů roztroušených po Evropě s celkovým objemem 1.5 TB dat za 5 hodin.

Nemáme nějak moc dat ani nejsme velká firma a stejně nejsme schopni použít k zálohování Glacier nebo C14. Nedokážu si představit, že budeme někam i jednou týdně posílat 1.5 TB dat. I při plné rychlosti gigabitu je to na ~4 hodiny a to ani nemáme na všech serverech takto silné připojené do zahraničí.

Držim palce chlapcům z GitLabu a snad se jim to podaří nějak přežít. Zálohovat není sranda, chyby jsou minimálně nepříjemné a často jsou schované a navíc uživatelé to berou za absolutní samozřejmost a tím pádem sami nezálohují i když to ta služba umožňuje a třeba i doporučuje.

Koli % tech dat se za tyden zmeni? 1? 2? To uz sou jiny cisla na posilani nekam po evrope ... kdyz se posila zaloha po netu, tak se samo v kazdym pricetnym systemu posila prave jen ten rozdil.

Tim netvrdim, ze hromada vsemoznych dodavatelu "reseni" ... nedodava systemy zcela nepricetny. Trebas takovej veam se neda pouzivat ani lokalne.

Byl to jen příklad toho, že zálohování není vůbec snadný aspekt správy čehokoli v IT a že i zjevné nástroje mají mouchy, které nejsou na první pohled vidět.

Ale ja nikde netvrdil ze to je easy ... naopak, prevazne plati, ze zadarmo ani kure nehrabe, a pokud chce nekdo zalohovat, tak holt musi vysolit nejaky ty papirky na drevo. A treba zrovna takovy zalohovani do jiny lokality nedela skorem nikdo ...

Hlavne je treba brat v potaz, ze neexistuje zadnej zalohovaci ubersystem, kterej by neco delal sam ... natoz dobre. Jenze to chce malo kdo slyset ...

Jde o to jaka jsou rizika vztazena ke ztrate dat. Na zaklade toho se udela kalkulace a navrhne se reseni. Nekdy je lepsi i zadnou zalohu nedelat, protoze obrat dat je takovy ze je nekdy levnejsi je nabrat znova. Prikladem budiz napriklad CERN a nebo burzovni statisticka data z forexu. O nejake milony se prijde. Ale zalohovaci reseni vs ztraty ma znacne nevyhodny pomer. Nehlede na to ze nektere veci muze kryt pojistka.

Meli jsme zakose co kvuli drahym cmoudovym zaloham presli na vlastni reseni. Coz zahrnovalo pronajem casti dalsiho datacentra, pronajem barvicek na vlakne za mesto a porizeni nechutne draheho reseni od te firmy co tu ma v Brne svoji chudou pobocku.

BTW: To je zvlastni ze kdyz nekdo neco chce tak se musi zaplatit ze? Vetsina ceskych knedlikovych IT s neexistujicim profesionalnim rizenim musi vzdycky na to prijit po nekolika vyhozenych zamestnancich (kteri maji pravdu) a ztratach dat. Vlastne po tech 25ti letech se nic nezmenilo. Stale jsou cesi barbari z vychodu a jejich prace v IT je neprofesionalni. Ne kvuli znalostem. Ale kvuli chybejicim schopnym IT manazerum. Jak rad nedelam pro cechy...

... "to se nestane" ... odpoved sefa firmy na pozadavek sestavit scenar toho, co se bude dit, kdyz se neco podela. Rizenim osudu tyden pred tim, nez se podelalo.

Jinak receno, taky bych chtel videt firmu, kde to funguje. Ale mame tu prece firmy, ktery (teda podle svych vlastnic slov) garantuji 100% ... a maji ten geograficky cluster ... teda ... dokud nepraskne jedna vodovodni trubka.

V "normalnych firmach" (nech uz to znamena cokolvek) sa spravi analyza rizik a z toho vyplynu poziadavky na zalohovanie. Vsetko ma sebe nejaku reziu a ta musi byt v nejakom realistickom pomere k tomu, ako dana vec ohrozuje kontinuitu biznisu.

Neviem ako casto sa ma zalohovat a ako casto sa maju testovat zalohy v "normalnej firme", rovnako netusim ake ma byt RTO a RPO. Tak ako neviem, ci mam mat v normalnej firme dvere na kluc alebo nieco sofistikovanejsie, ci mam mat na vstupe iba recepcnu v pracovnej dobe alebo 24h ostrahu v celom objekte.

"v normalni" tedy vetsinovy firme, se zadna analyza delat nebude, protoze by to stalo penize a sef prece prohlasil, ze zadny riziko neexistuje.

Je to tak rok, mozna dva ??? co tu lechce radily ty sifrovaci krasavci ... a znamej rikal, ze behem hodiny odbavoval kolem 30 hovoru na tema jestli umi ziskat zpatky ty data ... zalohy nemel nikdo znich samo. Ne soukromy osoby, vsechno firmy. A samo ze prej vystupy typu ze prisli o 10 let prace a pod. Rikal jim, ze jediny co muzou zkusit je zaplatit, ze mozna je tvurce hodnej a data jim za ty prachy vazne i desifruje.

V ty "normalni" firme se totiz zeptas, jaky maj naklady na hodinu/den vypadku, a cumej na tebe jak na martana.

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(le­gislativna 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.

"... 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 ...

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(flas­kbacku). 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.

"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 :-D

Jak dlouho tedy bude trvat zaloha/obnova 300TB databaze, pokud mohu zapisovat/cist soucasne treba na/z 10 pasek LTO7 soucasne?

LTO7 cte 180MB/sec, takze teoreticky muzete cist 1800MB/sec, kdo to ale zvladne zapsat na jeden disk? Pri vetsich objemech se vyplati pouzit replikaci a snapshoty(popr. flashback). Samorzrejme se zalohy se porad hodi, ale pro opravdu rychlou obnovu se bohuzel uz nehodi.

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.

To chce klid, sice vo tom ví úplný hovno, ale zato managorskej zmrdospeak má nacvičenej na výbornou. Popsal tři odstavce, informační hodnota nula, ale vypadá to hrozně "odborně".

Nektere replikacni metody umi zpozdenou replikaci.

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Ú...

Rek bych, ze pokud budes resit replikaci, a podobny ptakoviny, tak to nebude 50 ale spis tak 5 000 faktur.

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í...

Ako viacery príšu, že vás nič nezachráni pred forcnutím rekurzívneho rm to predsa je snaď tak iba v jednoduchých prípadoch.
Napriek všeobecnému názoru, proti INDIVIDUALNEJ narazovej ludskej chybe administrátora sa chrániť dá .
Chcem vidiet ako by hociktorý z administrátorov zmazal svojimi prostriedkami geolokované paralelné centrá kde nemá naprosto ziadny prístup. Co moze je vyvolat security incident najvyssieho stupna na odstavení data pumps/rt connectors alebo performance incident ked zrazu zacnu near realtime KPI sledovania vyskakovat ze serving requestov na data je smerovani do inych ako primary centra a pod... Samozrejme zjednodušujem ale jednoduchemu rm -rf davam v data zabezpecenom systeme(netvrdim ze je to lacne :) ) tak par sekund kym sa na to dojde a zacne obnova. Potom je uz len otazka v ramci operacneho incidentu co nas to stalo napriklad za nahly narast spotreby pasma pri prenose udajov a pod...

A co sa týka replík tak predpoklad ze zmazanie v jednom systéme automaticky znamená zmazanie "replik" na dalsich systemoch tak to sa asi bavime len o trivialnych scenaroch replikacie kde prebieha "raw" synchronizacia.

Vela systemov v regulatornych podmienkach ma napriklad data riadene v auditovanych immutable stores v sulade s retencnymi podmienkami ci uz zakonnymi alebo zmluvnymi.

V pripade GitLab ma skorej zaraza ten bordel v organizacii ze sa nenasiel zjavne nikto kto by sa takejto otazke venoval a drzal pod palcom riesenie/procesy. Odpustit startupom sa da dost ale pri platenej cloudovej sluze to zbytocne podkopava doveru zakaznika k forme sluzby ako takej a nielen voci GitHub a to je zle.

Gratuluji, další tři odstavce bezcennejch exkrementů s informační hodnotou nula, plus jako bonbónek povzdech "jooo, kdyby si na to najali experta jako jsem já, tak se jim to nemohlo nikdy stát" - asi v naději, že potřebují zvýšit stupeň zazmrdování firmy a tak zvednou telefon a budou žhavit horkou linku do Horních Uher, aby jim tam poradili. :-D

P.S. GitLab != GitHub, experte. :P

P.S. GitLab != GitHub, experte. :P

Ty este vacsi experte . Prave kvoli takymto u nas pouzivame GitLab v on premise mode.
Goodluck ku komentarom it ludi z prostredia kde maju pristup ku vsetkemu s max pravami , s fyzickym pristupom a su radi ak im da majitel firmy peniaze aspon na DvD media ako riasenie zalohy(a "obnovy").

"žhavit horkou linku do Horních Uher" Zelam ti vela stastia ked za nieco podobne ako v ich sluzbe dostanes od regulatorneho uradu vysoku pokutu za data incident alebo nebodaj percenta z marze za nedodrzanie postupov pri narabani s udajmi.

Ty este vacsi experte . Prave kvoli takymto u nas pouzivame GitLab v on premise mode.

Samozřejmě nezálohovaný, protože záloha je zbytečná, dyť máme replikaci. Aneb "Naco záloha? Já mám RAID."

:-)))

Klídek, nehádej se s ním. To je jeden z těch, co mu k přežití stačí titul MBA, kýbl medu na mazání šéfovi kolem huby a kýbl slimáčího slizu, aby se dokázal vyplazit z průšvihu.

Diskutovat nemá cenu, energii je u takových volů lepší využít na aktivní mirroring jeho skutečných "zásluh" nadřízeným.

predchádzajúcim krčmovým rečiam sa nevyjadrujem

"sa nenašiel zjavne nikto kto by sa takejto otázke venoval a držal pod palcom riešenie/procesy"

určite sa všetci zhodneme, že nech už si vyberieme akúkoľvek cestu,nie je to len otázka technológie (replikácia/zá­lohovanie). Toto nie je projekt jedného človeka, ale celého teamu. T.j. personálna otázka, či ten človek bol sám a nebol prepracovaný, otázka peňazí, otázka architektúry, či tie dáta nosili na USB z vedľajšej kancelárie, alebo mali optickú sieť,...
keď nevieme nič o danej situácii, ťažko debatovať o tom, čo mohli a nemohli. Dá sa len konštatovať, aké sú trendy vo svete a že ten človek si to asi nedá do životopisu.

Vtip nazáver:
- Mám novú prácu.
- Akú?
- Robím admina v NBÚ.
- A koľko ti platia?
- Zatiaľ nič, oni o tom ešte nevedia.