[Frissítve] Szerverhiba miatt leállt a Prohardver lapcsalád, a helyreállítás folyamatban

Internet, Közösségi média

Két napja - úgy néz ki, hogy hardverhiba miatt - leálltak a Prohardver IT portál szolgáltatásai:

A Facebook postok szerint a visszaállítás folyamatban van, de adatvesztés nem kizárható. Reméljük a legjobbakat, mi szurkolunk, hogy sikerüljön! A Prohardver a magyar internet IT oldalainak egy veterán, meghatározó szereplője, ilyenből pedig már kevés van! Kár lenne érte!

( gyuri23 | 2025. 07. 24., cs – 09:18 )

Remélem ha végeznek a helyreállítással, leírják, hogy pontosan mi történt és tanulunk belőle.

Elolvastam amit írnak és ha jól értem, az egész lapcsalád egyetlen gépen futott. Ez nekem elég fura, mert manapság egy HA cluster nem csillagászati összeg, de nem ismerjük egyelőre a részleteket.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Nem is az a legnagyobb probléma, mert miért ne futhatna egy hardveren, ha van megfelelő és lepróbált disaster recovery terv? Egy virtualizáció vagy konténerizáció esetén a HW majdnem mindegy mi alatta, tenni alá egy másikat meghibásodás esetén nem nagy probléma. Megbízható mentés legyen ilyen esetben, lehetőleg olyan, ami biztosítja, hogy egy gombnyomásra megy vissza minden, ha kell. Ez nem rocket science, hanem 15 éves tech. 

Ha jól értem, itt az ilyen mentés megléte a legnagyobb probléma. 

trey @ gépház

Ezt így gondolom én is. Ráadásul egy használt szervert tartaléknak egy átlagos fizetésű IT-s is meg tud venni, legfeljebb nem lesz olyan gyors, mint az éles.

Egy informatikai lapcsaládnál ez egy kicsit kínos.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Szerverhardverben én még nem találkoztam olyannal, hogy CPU-t cseréltek volna,

Hogy ne lenne? Pl. az Itris-nek van ilyen szolgáltatása itthon, én is igénybe veszem. Ha akarod, egész szerver hidegtartalékot kitesznek neked a telephelyre + mérnöki szolgáltatást mellé 7/24/365-ben akár 2 órás reakcióidővel, 6 órán belüli garantált elhárítással Győrben (tehát Budapestről nézve az ország másik végében). Ráadásul nem is horror összegért.

Egyébként, 5 hónapja csináltam pont ilyen, már annyira olcsó lett a Xeon Gold, hogy érdemes volt meglépni a cseréjét Silver-ről. Megspóroltam vele 3 új szervert és szaré'-hugyé' adták:
 

trey @ gépház

Lehet, én más körökben mozgok

Az biztos :)

elavult a régi, hogy semmi értelme bővíteni.

Hogyne lenne, ott vannak a számok. Dupla CPU teljesítmény fillérekért. 3 új szerver árának töredékéért. A gép így még éveket kiszolgálja az igényeket. Csak CPU-ban volt gyenge, azon meg lehetett segíteni. 

trey @ gépház

Meg annyit hozzátennék, hogy amilyen körökben én mozogtam, amikor még volt vashoz közöm, ott a CPU-t óriási discounttal kaptuk a brand szerverben. Listaárhoz képest közel féláron voltak a Xeon-ok, _ha_ a választott nagy brand gyártótól rendeltük a komplett szervert egyben. Nyilván ehhez kellett egy többéves partneri szerződés a brand szerver gyártóval, nem akármelyik utcáról beszédült ügyfélnek adtak ilyen árengedményeket.

Utólag ezért pénzügyileg sem volt opció a CPU upgrade, mert akkor már nem tudtunk volna ilyen engedményt kapni. Nyilván az aktuális brand partnerünk abban volt érdekelt, hogy szervert adjon el, ezért hajlandó volt az Intellel kötött legjobb egyedi szerződésének megfelelő árazással továbbadni felénk a processzort. Ha csak CPU-t akartunk volna venni, már sokkal vastagabban fogott a ceruza.

És akkor persze még lehetne beszélni a szerver support időszakáról, ami nyilván nem hosszabbodik meg a CPU upgrade-től és az esetek többségében a support lejárta volt az ok amiért cserélni kellett. (A mi csoportunk dev szerverparkja sokáig ilyen support vége miatt leselejtezésből megmentett vasakból állt.)

Régóta vágyok én, az androidok mezonkincsére már!

Ez attól függ h adott generációnak a tetejét veszed-e meg. Ha igen akkor az upgrade egyben generációváltást is jelent azaz kb teljes csere.

Ha nem a tetejét veszed meg akkor simán indokolt lehet (10 évvel később pláne) egy cpu csere (konkrétan gombokért).

Én is gondolkoztam nemrégen ilyenben, de egyelőre elhalasztottam és valszeg mire sorra kerül a dolog addigra generációváltás is lesz - hogy fogyasztást is tudjak csökkenteni.

zászló, zászló, szív

Én kétszer láttam. Az egyik kb. 20 éve volt, valamilyen IBM Xseries toronyban, de ott sem hitte el a support, hogy ez megtörténhet, nem is hoztak CPU-t, csak alaplapot, aztán fordulniuk kellett egyet pluszban. A másik 5-6 éve volt, egy Dell pengében, ott nem lepődtek meg, hoztak CPU-t, és kicserélték egyből.

Nyilván egy gyártói hw support több ilyet lát, de üzemeltetés területen dolgozva, azért kijelenthetjük szerintem, hogy nagyon ritkán jön szembe. Nem tudom hány cpu fordulhatott meg a "kezem alatt", de 2000db fölé tenném, és ezen szerverek életciklusa is jellemzően 5 év volt (néha jóval több), de 25 év alatt 2db ilyen esetet láttam csak.

Szerk.: lehet, hogy félreértettem, én nem bővítésre gondoltam, hanem cpu-hiba miatti cserére.

Nem jellemző a CPU hiba, de kizárni se lehet. Egy biztos, ilyen esetre fel lehet készülni. Nem kell CPU-t polcon tartani, nem kopó-fogyó diszk ez, de egy garanciahosszabbítást nyújtó szolgáltatóval lehet szerződni a cseréjére. 

BTW: szerintem itt sem a CPU szarta össze magát. 

trey @ gépház

Szerintem se. Sokkal valószínűbb hogy az erősebb processzort az esetleg instabilabb háttér már nem tudta kiszolgálni. Tipikus táp probléma...
De az minden amatörizmus legalja, hogy egy instabil eszközt hasraütéssel/próbálgatással diagnosztizálok, aztán elkezdem rajta a helyreállítást.
Az első lépés, hogy a gyanús hardvert beb@asszuk a sarokba, és elővesszük a tartalékot. Már ha nincs standby ugye. Gyász ez a történet.

Azt állítják, hogy a processzor hibája okozta a rendszer korrupcióját.
Ha jól értem a folyamatos backupok is a sérült adatbázisról készültek.

Egy ilyen rendszernél a backup megoldás mennyire agnosztikus/specifikus?
A backupot végző szervíz tudja, hogy adatbázist backupol?
Észleli a backup kezelésekor, hogy az adatbázis hibás?
Ha az adatbázis formálisan rendben van, de maga az adat korrupt azt hogyan veszed észre backupoláskor?
Milyen módszerrel lehet ezt detektálni?
Hogyan tud ezen a virtualizáció segíteni?

Szokás tesztelni a backupokat?

Beágyazott rendszerben láttam olyat, hogy a processzor utasításait a futó rendszerben ellenőrizzük, hogy még mindig jól működik-e a processzor. Ilyen van szerver oprendszerekben?

Software is like sex, it's better with a penguin. :D (r)(tm)(c) آكوش

Nem vagyok adatbázis specialista abba lehet, hogy részben kijavítanak.

A mentésben nincs szentírás, kismillióféle képen meg lehet oldani. Sql-t illik vagy a saját eszközével, vagy speciális agent-el menteni. Ezt a mentés lehet utána fájl szinten elrakni. Ez nem kötelező, ha a VM-et mented, a mentés általában csinál egy snapshoot-ot a gépről és azt menti el. Na itt a fene tudja éppen mi történik az adatbázisban, lehet belőle gond, de ez általában max egy tranzakció, mert a db lekezeli ezt.
A db saját mentése észere tudja venni, ha gond van, feltéve ha van checksum, ami nem feltétlen alapértelmezett.
Elvileg van olyan csillagállás, hogy korrupt adatbázis mentesz, de egy normális mentő eszközben akárhogy konfigurálható a retention policy. Nem szokás egy két mentés megtartani, hanem pl, az utolsó 7 nap, utána fél évig heti 1, utána meg havi 1, meg 5 évig évente is. Egy ilyesmi konfigból szinte biztosan vissza lehet nyerni valamit, de extrém lenne, hogy hetekig nem derül ki a korrupció.

Egy jó backup szoftver beállított időnként ellenőrzi a mentéseit. Egy jó DRP esetén rendszeresek a visszaállítási tesztek.

A virtualizálás (ilyen esetben) elsősorban a disaster recovery-ben segít, mert úgy szokás beállítani, hogy a guest gép nem is tudja, hogy mentik és semmilyen módon nem éri el a mentést. Ez egy kibertámadás esetén (is) lehet nagy segítség, de ennek ellenére illik még offsite mentés is csinálni, lehetőleg pull módon. Egy virtualizál gép mentése nem hardver függő, ha a host elszáll, elszaladsz a boltba és akármit vehetsz, azon is tuti menni fog.

Ehhez jön extrának a cow filesystem, ahol nem lehet fájl korrupció (pontosabban lehet, csak azonnal kiderül). Ilyen pl a ZFS de már van jó pár alternatívája.

Szóval egy súlyos adatvesztés erősen emberi hiba. 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Na itt a fene tudja éppen mi történik az adatbázisban, lehet belőle gond, de ez általában max egy tranzakció, mert a db lekezeli ezt.

Ha app-aware módon mented, az MS SQL szerver tudja, hogy menteni fogják, megoldja. Ha MySQL, PostGre stb. akkor meg legparasztabb megoldásként futtatsz egy mentés előtti szkriptet, ami leállítja szabályosan az SQL szervert a mentés idejére, mondjuk hajnali 3 óra 17 perckor. Ez még mindig jobb, mint egy hetet állni és pingvinezni. 

Lehet mentés előtt még SQL-t dumpolni FS-re és akkor azt menteni, de ekkora DB-k esetén a dumpolás már több óra is lehet és részlegesen megfoghatja az oldalkiszolgálást. A diszk sebessége lesz a kérdőjel. 

Lehet pl dump-ot közvetlenül ssh-n keresztül átküldeni másik gépre és akkor az offsite is meg van oldva. 

Ezek a legócskább mentési módok. Lehet nyilván ezt szofisztikálni.

trey @ gépház

Postgres: legparasztabban pg_dump-ot rátolod.

Én restic-el mentek, pg_dump megy bele stdoutról, simán csinál belőle inkrementális mentést.

Ez nem feltétlenül transaction safe, pre-backup scripttel lehet finomítani.
 

zászló, zászló, szív

Hát ez az, sufni tuning megoldásokkal is egész korrekt megoldásokat össze lehet tákolni, nem lehet azt mondani, hogy nem volt rá keret. 

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ha app-aware módon mented, az MS SQL szerver tudja, hogy menteni fogják, megoldja. Ha MySQL, PostGre stb. akkor meg legparasztabb megoldásként futtatsz egy mentés előtti szkriptet, ami leállítja szabályosan az SQL szervert a mentés idejére, mondjuk hajnali 3 óra 17 perckor.

Szinte mindegyik használt DB engine tud app-aware módon mentést támogatni, MySQL és PgSQL esetén is van erre lehetőség, fel kell csapni manual és megolvasni.

TLDR, MySQL/MariaDB esetén:

1, BACKUP STAGE START; BACKUP STAGE FLUSH; BACKUP STAGE BLOCK_COMMIT;

2, filesystem snapshot

3, BACKUP STAGE END;

4, snapshot mentése.

TLDR, PgSQL esetén:

1, SELECT pg_backup_start(label => 'label', fast => false);

2, filesystem snapshot

3, SELECT * FROM pg_backup_stop(wait_for_archive => true);

4, snapshot mentése.

https://iotguru.cloud

Egyetértek, hogy egy súlyos adatvesztés szinte mindig emberi mulasztás eredménye. Ráadásul, ha valóban CPU-hibáról van szó, egy teljes sémamentésnél már jó eséllyel ki kellett volna buknia a problémának. Őszintén szólva eddig nem nagyon hallottam olyan adatbázisról, ami hosszú ideig működne CPU-hibával, miközben sorra gyártja a hibás backupokat, majd egyszer csak végleg megadja magát - ez nagyon ritka és extrém szcenárió lenne. 

Egy ilyen rendszernél a backup megoldás mennyire agnosztikus/specifikus?

Alapvetően nem jó ha túlzottan specifikus egy mentés, de az sem jó ha túlzottan általános megoldást használsz. A legjobb ha olyan megoldást választasz, amihez értesz, vagy a logikáját magadévá tudod tenni.

A backupot végző szervíz tudja, hogy adatbázist backupol?

Muszáj neki. Ez általában úgy szokott működni, hogy a mentés kezdésekor, a memóriában tárolt adatokat kiíratja diskre az RDBMS motorral a mentést végző agent. Ha ez megvan végzi el a mentést. SQL dumpot készít (ez a rosszabb megoldás, nagyobb adatbázisoknál), vagy az adatbázishoz tartozó fileokat menti el (ehhez viszont kell binary logot is készíteni, ami tartalmaz minden adatbázis változást, amire azért van szükség, hogy amíg fut a mentés és közben történnek változások, ne vesszenek el).

Észleli a backup kezelésekor, hogy az adatbázis hibás?

Na ez egy komplex kérdés. Egy felől ez függ a backup megvalósítástól. A legtöbb nagy nevű rendszer végez egy checksum alapú ellenőrzést, de ez nem jelenti azt, hogy el tudná dönteni a mentő eszköz, hogy logikailag a DB teljes-e. Ezt úgy szokás kezelni, hogy a mentés végén (full backupkor mindenképpen) visszaállítási tesztet végzünk és összehasonlítjuk ezeket a fileokat az eredetiekkel. Ha eltérés van a backup software jelez, az ember meg ellenőrzi, hogy elfogadható-e az előállt mentés. Ezen túlmenően időnként végzünk olyan mentés visszatöltési tesztet, amikor elvégezzük a visszaállítást mentésből és megnézzük, hogy az alkalmazás működik-e a visszaállított mentéssel. (Most azt fedje jótékony félhomály, hogy ezt hogy tesztejük. Ha ezt kifejteném, még holnap is írnám ezt...)

Ha az adatbázis formálisan rendben van, de maga az adat korrupt azt hogyan veszed észre backupoláskor?

Mentéskor sehogy, visszaállítási tesztet kell végezni.

Milyen módszerrel lehet ezt detektálni?

Ez nagyban függ a szervezet nagyságától. (Mert mint fentebb írtam tesztelni kell.) A legjobb megoldás talán egy olyan entitás (mi?) lehet, amely képes ellenőrizni az adatbázist olyan módon, hogy a táblákban a szükséges számú sor található, maga az RDBMS egészségesnek találja a táblákat és az indexeket, illetve tud olyan lekérdezéseket futtatni, amelyek logikailag képesek megállapítani, hogy minden tárolt adat konzisztens a környezetében. Na ez nem kis munka és az alkalmazás (amely az adatbázist használja) fejlesztője nélkül ez kivitelezhetetlen.

Hogyan tud ezen a virtualizáció segíteni?

Sehogy. Pont ugyan azok a nehézségek, mintha közvetlenül a vason futna az alkalmazás és maga a mentés is.

Szokás tesztelni a backupokat?

Visszaállítási teszt nélkül nincs mentés, ha ezt nem implementálod, akkor csak tárhelyet pazarolsz.

Beágyazott rendszerben láttam olyat, hogy a processzor utasításait a futó rendszerben ellenőrizzük, hogy még mindig jól működik-e a processzor. Ilyen van szerver oprendszerekben?

Whichcraft! Elképzelhető de ezt a problémát nem így kell kezelni, hanem failoverrel és a futó alkalmazás monitorozásával.

----
올드보이

( kbalint v | 2025. 07. 24., cs – 09:23 )

Azé egy cloudflare dns átirányítás (ha már úgyis mindegy) + egy statikus nyitóoldal a "lapcsaládnak" azért beleférhetett volna recovery step 0-nak

~ubuntu, raspbian, os x~

Nekem az egyszeri fejlesztő jut mindig eszembe, akitől kérdeztem, hogy

- ...

- De mentésed ugye van?

- Persze, minek nézel te engem? :D - húzza ki magát büszkén.

- Hol?

- A D: meghajtón! 

- Ami ugyanannak a beszart diszknek a második partíciója volt? - 🤦‍♂️

- Hát őőőő ... 

🤷‍♂️

trey @ gépház

Nekem is volt ilyen, egy nagy tudásúnak mentem segíteni, egy ransomware letitkosította a NAS-on egy mezei share-en a dolgait.

- Hát a mentésből visszaállás lesz a legegyszerűbb. Van mentés?
- Persze.
- Hol?
- Hát RAID-be van.
- Az nem mentés.
- Dehogynem.
- Akkor válasz, hogy a fontos.doc.tikosítva fájlt az 1-es vagy a 2-es lemezről kéred, mert mindkettőn ugyan az van.
- Őőőő

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

( bennyh | 2025. 07. 24., cs – 10:54 )

Szerkesztve: 2025. 07. 24., cs – 10:57

Amúgy miért derogál nekik egy statikus oldalt kitenni, esetleg egy 4-6 órás helyzetjelentéssel frissíteni, ne keljen a facéra járkálni, ahol szintén nincs semmi?

Olyan, mintha fel is adták volna.

Vagy egy ember izzad most egy budai lakás hátsó szobájában, vagy hol van ezeknek a bázisuk, akinek erre sincs ideje? Én megértő vagyok, nekem is voltak rossz napjaim, de egy ilyen laptól nálamnál nagyobb profizmust vártam volna.

Én Bog helyében rájuk borítanám az asztalt, hogy vagy szolgáltatnak vagy lelép.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Értem én, hogy megdöglött, de egy statikus weblap közzététele új üres vason vagy VPS-en lassan általános iskolás feladat, de szakközepes tuti. Nem is beszélve, hogy van fillérekért két kattintásos weboldal készítő egyedi domain-ekhez.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

DigitalOcean-on az első 3 statikus weboldal létrehozható free APP-ként. Egy sima HTML fájl, benne egy pár sorral.
Csak mert én pl. most értesültem róla, hogy mi történt, eddig csak az tűnt fel, hogy a prohardveres linkek a google találati listájából nem töltenek be.
Magát a HTML-t amúgy a ChatGPT is össze tudja rakni, elég szóban elmondani neki, hogy miről szóljon. De szerintem abban is tud segíteni, hogyan kell publikálni. Ehhez már különösebb informatikai tudás sem szükséges.

Nagy Péter

Engem az lep meg, hogy azt írják, a DB szerver halt meg. Ez azt a hatást kelti, mint ha a DB szerver mellett lenne még egy másik szerver is, ami mondjuk kiszolgálta a weboldalt. 
Hogy ezen a szerveren miért nem tud futni egy olyan statikus oldal, ami nem használ adatbázist, és ki van rajta írva, hogy "Leállás van, részletek a facebookon", az nem teljesen világos. 
Még ha nem is ez volt az első gondolatuk, amikor már 24 órája állt az oldal, és vélhetően addigra már látták, hogy ez még legalább ennyi időn át állni is fog, akkor azért már nem az ördögtől való erre 10 percet áldozni.

Nagy Péter

Gondolom el vannak foglalva azzal, hogy web.archive.org-ból kiszedjék ami ott megmaradt és valami struktúrált formában összerakják! :D

Szerintem ha nem tudják megoldani a felettébb problémás feladatot amit maguknak csináltak akkor itt a PH vége. Minden szempontból elavult, lényegében a nosztalgia és a ott megragadt régi tagok tartották életben. Ha most újra kellene mindenkinek regisztrálnia, elvesztve az évtizedek alatt elért rangjaikat akkor itt game over van. 

Én türelmest voltam az első 24 órában, morcos a másodikban, de most így a harmadikba lépve ugyanezt mondom, mint te. Ilyen teljesítményt én is tudnék produkálni, mint ők :D Csak én bivalyröcsöge külsőn vagyok gizda, ők meg vezető szakportál.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

A "vezeto szakportal" jelzot erosen vitatom.  
Lasd az elmult par nap bullshitekkel teli vergodeset. Nyilvan az en szegenysegi bizonyitvanyom, de reszemrol be lehetne szantani az egeszet ugy ahogy van, sosem hasznaltam ezeket az oldalakat. Mobilarenat latogattam utoljara par cikk miatt, de akkor meg javaban nyomogombos mobiltelefonok voltak. 
 

I don't run often, but when I do, I run as administrator.

Szerintem ez a vezető szakportál cím (nem olyan de) hasonló mint a média-piackutatások. A Foxy-Maxy rádió hallgatottságban az első a 18 és 34 év közötti, szingli rövid szőke hajú és zöld szemű, kiskutyát tartó nők körében. 

Valaha talán valóban vezető magyar szakportál volt a PH. Azt is megkockáztatom, hogy az első időszakában a magyar internetezők jelentős része legalább heti szinten olvasta azért, mert az ős-hőskorban mindenki aki egyáltalán internetezett értett, vagy legalábbis próbált érteni az informatikához. 

Azóta annyira átalakult ez a terült, hogy már minden másként van. Vezető informatikai (sőt bármilyen) szakportál ma már nem létezik még angol nyelven sem. Talán sokáig a Stackoverflow  tartotta magát ilyesmi pozícióban, de az sem informatikai hanem programozói portál inkább. 

A különböző tematikus "asztaltársaságok" ma már Facebook csoportokat csinálnak, akiknek meg ciki a facebook is Discordon értekeznek egymással. Renitens alter-máskéntgondolkodóknak ott a Telegram. És még kismillió globalizálódott platform, amit ugyan senki sem olvas (nincs olyan, hogy rendszeresen olvasom A Facebookot) úgy egyben, de egy kis szeletét rendszeresen látogatja. 

Akinek valami technológiai problémája van ma már megkérdezi az AI-t, egyre kevésbé fog rosszabb választ kapni mintha valamilyen PH fórumban keresett volna megoldást és még a válaszra sem kell várnia fél napot. 

És valóban lehetne akár rossz szakportál is vezető, de a PH-ra ma már inkább vezető nosztalgia szakportál lenne megfelelő. A korai internetezők szubkultúrájában jelentős portál, azaz csak volt ha nem állítják helyre nagyon gyorsan, az idő pedig megy. 

ők meg vezető szakportál

Személyes vélemény (sarkos, elnézést a rajongóktól):
Hááát.....
Szakportál? Én inkább egy fórum köré épített portálnak tartottam mindig is. IT iránt érdeklődő, lelkes amatőrök gyűjtőhelyének + pár szakmabeli. Fűszerezve időnként IT hardver tesztekkel.
Vezető? A magyar piacon sose volt nehéz vezetőnek lenni versenytársak hiányában. Kis piac, kis foci.

A PH fő értéke az ott lévő fórum és közösség. Sok témában tök hasznos, segítőkész arcok. Nem sok van helyette. Szóval szerintem nem a nosztalgia tartja életben, hanem, hogy ténylegesen hasznos.

Ezért sem hiszem, hogy pl a mobilarena értelmesen tudna önállósodni. Mert klassz, hogy gyártják a tartalmat, de a nézettség szerintem a fórumozóból jön nagyrészt.

A fő ereje a fórum, de azokat, akik fizettek is, most vesztik el. A Mobilarénásoknak meg lépni kell, mert ha nincs oldaluk, akkor nem veszik komolyan a gyártók és nehéz lesz újraépíteni a kapcsolatokat a gyártókkal. A héten vagy lesz PH vagy lesz egy külön Mobilaréna, a PH meg már nem fog talpraállni, üzletileg. Máshogy meg nem lesz érdemes fenntartani. Én Bog helyében keresnék vagy egy másik üzemeltetőt vagy elkezdenék telefonálni egy-két konkurenciának, hogy ha a nevet nem is de a csapatot vinné. 

Ezt úgy írom, hogy nagyon fájna, ha megszűnne a PH, de ilyen tempóban meg fog szűnni.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Miért veszítenék el azokat akik fizettek? Ha újraindul akár egy plusz hét múlva és továbbra is az ami volt, akkor miért lenne most kevésbé jó előfizetni? A mobilarena sem hiszem, hogy felrúgna egy sok éves együttműködést, ha nincsenek más problémák is háttérben.

Meg a lényeg: én nem látom, hogy mi lenne az alternatívája, mint fórumnak. Tudsz hasonlót, ami jobb?

( Appl3 | 2025. 07. 24., cs – 14:16 )

Csak megjegyzem halkan, hogy az iT Café és GamePod.hu oldalak megszűntek nemrég önállóként viselkedni.

Sima almenüként éltek az elmúlt pát hétben/hónapban.

( bennyh | 2025. 07. 24., cs – 16:01 )

Van már...

...új fészbúk bejegyzés. 

Megtudhatjuk belőle, ami ránk tartozik:

Semmmit

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Van még ez a Media1 cikk: https://media1.hu/2025/07/23/hardverhiba-osszeomlas-prohardver/

Jelenleg az összeomlás következményeit mérik fel és próbálják helyreállítani az oldalt. Jelezték: szerencsére van biztonsági mentés az oldalról – csakhogy előbb kellene alá egy stabil hardver is, amire feltehetik.

Ha valóban van biztonsági mentés, akkor a helyükben már béreltem volna felhőben IaaS-t és legalább read-only módban elindítottam volna.  

24 órába ennek kényelmesen bele kellene férnie. 

Úgy egyébként COB szerver miért nem volt náluk? Annak a beszerzését ugyebár nem akkor kell megkezdeni amikor megdöglött a Prod. 

Na már a Media1-ben sem lehet megbízni! Hát köszi az infót.

Ezek szerint nem biztos, hogy bekamuzták azt, hogy van backup. Bár mind1 is! Nem is tudom mi lenne a cikibb egy Prohardver esetében? Ha van backup de 24 óra elteltével sem tudnak mit kezdeni vele? Vagy ha elfelejtettek backupot csinálni? 

( Sanya v | 2025. 07. 24., cs – 18:18 )

Szerkesztve: 2025. 07. 24., cs – 18:18

Frankó szerint a felhő a megoldás. Ő 200 dollárért, olyan 66.000 forintért bérel egy sokmagos, 160gb, sokterás háttertárat, nem kell már semmit otthon futtatni, simán elég lenne a ph-nak is 

Az megvan, amikor a google véletlenül törölte az ausztrál nyugdíjbiztosító teljes adatbázisát, a mentésekkel együtt, mert azt hitte nem fizettek? 

Nem így történt!

A hiba a Private Cloud szolgáltatás beállításakor keletkezett, amikor egy belső űrlapon egy mező üresen maradt. Ez azt eredményezte, hogy a szolgáltatást tesztidőszaknak tekintette a rendszer, és lejárat után automatikusan törölte.

https://www.techspot.com/news/103207-google-reveals-how-blank-parameter…

Az UniSupernek azonban voltak mentései külső, Google­től független szolgáltatónál, ezekből tudták visszaállítani a rendszereiket.

Frankó szerint a felhő a megoldás.

A PH problémára igen.

Ő 200 dollárért, olyan 66.000 forintért bérel egy sokmagos, 160gb, sokterás háttertárat, nem kell már semmit otthon futtatni, simán elég lenne a ph-nak is 

Nem én bérlem, én raktam össze.

Amúgy meg igen nagyrészt nem otthon futtatod a saját vasat se, hanem valami DC-ben vannak a gépeid. A különbség az, hogy te veszed meg, viszed be a vacsa-vacsa kezecskéiddel és ha elromlik, akkor te mész be és javítod a vacsa-vacsa kezdécskéiddel vagy szaré'-húgyé' vannak ott erre droidok és csak bérled a gépet, amiből van nekik tartalékban többnyire több száz ugyanolyan.

https://iotguru.cloud

Ittt nem azt mondod, hogy 66.000 forint egy ilyen gép? Mert 66.000-ért villany, klíma, internet, fizikai hozzáféréskorlátozás elég drága 

Nem egy gép, hanem 2x6 node, vagyis 12 gép, vegyesen VPS és bare metal. És 66 ezerért ebben benne van minden, a gépek bérleti díja, villany, klíma, internet, fizikai biztonság, javítás, satöbbi. Ennyi pénzért bérelsz ennyi erőforrást "felhőben", és a szolgáltató dolga, hogy ezek az erőforrások üzemben legyenek, beleértve a géphez tartozó OS image biztosítását is, amiben előre be van konfigurálva minden, ami a gépekben van. A te dolgod az OS-től kezdődik.

Hw hibától nem véd, mentés ugyanúgy kell.+ Ha hiba van autózhatok 500km-t.

Mentés benne van az árban, a HW hiba ellen pedig véd, mert azt többnyire automatikusan észreveszik és javítják vagy adnak egy új gépet "raktárról" szinte azonnal. Egy lépést nem kell menned sehova.

https://iotguru.cloud

de még mindig nem tudjuk, hogy a Ph elfutna-e benne ugyanolyan sebességgel, plusz mentés.

Mentés benne van, ha pedig a PH nem fut el 48 CPU, 160 GB RAM és 2400 GB storage felett, akkor menjen csődbe a gecibe, pár hasonló kaliberű site van-volt a kezeim között, ennek a töredékén elfutnak. 

amíg nem tudjuk a Ph paramétereit ez max egy nagyon bátor feltételezés.

Nincs ebben bátor feltételezés, egyszerű tapasztalat. Mondok példát, egy nem túl optimalizált Drupal képes 500 ezer page request per óra kiszolgálásra ~4 CPU/8GB/NVMe alapokon, a PH-nak saját bevallása szerint volt hétköznap 1,4 millió oldalletöltése, az is nagyrészt statikus oldallá konvertált tartalom volt.

https://iotguru.cloud

kételkedem. valami sántít 

 

vagy nagyot mondott és egy Ph méretű weboldal éppen csak karikázna rajta, de nem tudná kiszolgálni egy ekkora fórumot.

vagy nagyon balfékek a Ph-s srácok és évi 750.000-ből meglehet a szerverköltség, akkor a 170.000.000 milliós éves bevételt kis tulzással munkaerőre és nyereségre lehetne fordítani.

kételkedem. valami sántít 

Nem értesz hozzá, ennyi történt.

Ezt megnézed: https://www.hetzner.com/sb/, megrendelsz 3db 32 GB RAM 2x500 GB SSD (bare metal) gépet, az 12 CPU, 96GB RAM és 1500 GB storage, tartasz ~100 dollárnál. Ehhez hozzáveszel 4 darab CX32 VPS-t, 4 vCPU, 8GB RAM, 80 GB SSD, az eddig ~130 USD, 28 vCPU, 128 GB RAM és 1820 GB storage. Átmész a Scaleway-hez, veszel egy START-2-L Dedibox-ot (bare metal), ~155 USD körül járunk, van 34 vCPU, 160 GB memória és 2070 GB storage, és ugyanitt bedobsz még a kosárba 4 kis VPS-t darabját 10 dollárért és tartasz 36 vCPU, 176 GB RAM és ~2400 GB storage körül. Változtak az árak a gépek kicsit, de fogod a vacsa-vacsa kezecskéidet és megnézed ugyanezt a két említett cég weboldalán:

https://www.hetzner.com/sb/
https://www.hetzner.com/cloud/
https://www.scaleway.com/en/dedibox/start/
https://www.scaleway.com/en/cost-optimized-instances/

vagy nagyot mondott és egy Ph méretű weboldal éppen csak karikázna rajta, de nem tudná kiszolgálni egy ekkora fórumot.

PH méretű weboldal ennél lényegesen kisebb vason el kell tudjon futni.

vagy nagyon balfékek a Ph-s srácok és évi 750.000-ből meglehet a szerverköltség, akkor a 170.000.000 milliós éves bevételt kis tulzással munkaerőre és nyereségre lehetne fordítani.

Nézd, 72 órája állnak, saját bevallásuk szerint nem tudnak mentésből visszaállni és most tudtak kitenni 72 óra után egy statikus HTML-t, hogy állnak. Szerinted mennyire szakértők?

https://iotguru.cloud

Statles alkalmazásokra ez teljesen igaza amit irsz egy k8s el, de mondjuk én még méretben ennyire vegyes tagú postgresql clustert nem láttam, kétségeim is vannak afelöl, h mennyire lenne életképes. Plusz eleve 2 dc közt a latency nem tudom mennyire verne oda a pgsqlnek vagy mysqlnek, fogalmam sincs mivel futnak. Ettöl fügetlenül szerintem is egy hetzner ezerszer jobb irány lenne erre nekik.

Mongo meg a cassandra az tudom hogy bírja, de egészen meglepne ha a ph alatt ilyesmi lenne, annak ellenére hogy a forum meg hírportál részre több mint alkalmas lenne. Pgsql-nél szerintem járhatobb lenne 3-3 egyforma instance oldalanként és komplett cluster replica. Ahoz viszont nem jó ez az extrán vegyes felállás ebben a formában :D

amúgy van szarul működő megvalósítás postgres clusterre kubernetes alá - avagy Bitnami Postgres Chart https://github.com/bitnami/charts/tree/main/bitnami/postgresql
Koncepcionálisan rossz és sok panasz is érkezett rá hozzájuk. Könnyen brain splitbe kerül akár többszörösen is.

Viszont a CloudNativePG az jónak tűnik https://cloudnative-pg.io/
Lehet, mert azt olyanok állították össze, akik a kubernetest is fejlesztik. Az paraméterezhető, hogyan viselkedjenek a replikák. Ha terheléselosztásként a replikáról is megy olvasás, akkor számíthat, hogy kell-e mindig a legújabb adat vagy belefér kis késés. Egy fórumnál mondjuk talán nem vészes, ha némelyik user még épp nem látja, hogy egy másodperce írt már valaki választ. Csak ne ugráljon köztük, hogy mikor melyiket látja adott kliensnél.

A chartok lényegében paraméterezhető templatek, aki nagyon ért hozzá, maga is kialakíthatja jól, a postgres képes sokmindenre. A chart azért jó, mert megvan az alap, utóbbinál részletes dokumentáció is, így sokkal kevesebb hibalehetőség marad beüzemelésnél. Mondjuk az operátor megvalósítás az övék, abban van valsz főleg az ész implementálva.

Cloudnativepg nem csak jónak tünik, az is. Épitek rá prodban, 3 év alatt eddig nem volt vele különösebb gond leszamitva a beépített backup tooljukat. Viszont csak homogén clustereket támogat és clustert tudsz üzemeltetni active-passive replicaba masik site ra, ezért is írtam, hogy vannak kétségeim ezzel a nagyon vegyes fellással mert kell db nek 3-3 egyforma gép mindkét oldalon inkább szerinten. A többi része meg már mindegy min fut.

( Dolphy | 2025. 07. 25., p – 03:58 )

De miert nem volt mentes errol volt valami?

Homalyosan valaki utalt ra, hogy nagyon low budget ceg, baromi nagy volt a DB, le sem futtathato egy mentes elfogadhato ido alatt, stb., de ez nagyon santit nekem.

Voltak képek, is de nagyrészt szöveg volt a fórum, egy-két topic megsínylette volna, de a szöveget meg a hsz-ek közötti kapcsolatot csak le lehetett volna külön menteni gyakrabban. De ezek szerint valami vagy nagyon régi vagy nagyon sufni megoldás, amit nem bírnak helyreállítani.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Hát, szerintem mindegyik adatbázis motor tudja a "backup stage" jellegű működést, vagyis amikor a DDL műveletek blokkolásra kerülnek, a disk-re kimegy a flush minden lezárt tranzakcióról és a journal-ba kerülnek az újak, ez néhány másodperc kurva nagy DB esetén is, rámehet a snapshot a fájlrendszerre, majd a snapshot-ról mehet a mentés. Az eredménye az, hogy lesz egy konzisztens mentésed. Nyilván ehhez kell olyan fájlrendszer, ami tud snapshot és olyan DBA, aki ismeri ezt és olyan backup tool, ami tud snapshot kezelést.

Ez low budget is megoldható, akkor van baj, ha a hozzáértés is low budget.

https://iotguru.cloud

le sem futtathato egy mentes elfogadhato ido alatt, stb., de ez nagyon santit nekem.

Ha becsülnöm kéne, 1 TB virtuális gép napi mentése virtuális gép szinten CBT-vel (csak a változott blokkokat mentjük) percekben mérhető, ha egyszer megvolt a full mentés. Fizikai gépnél DB dumpolgatásokkal persze órák is lehetnek. Nem úgy kell menteni.

trey @ gépház

( ricsip v | 2025. 07. 25., p – 06:48 )

Szerkesztve: 2025. 07. 25., p – 07:06

Egy kedvenc mozzanatom természetesen itt is feltűnt. Nem csak itt ebben a konkrét esetben, hanem általában a hasonló szituációkban.

Ez a "kialvatlan zombiként dolgoznak 48-72 órája" ez az összes havária sztori kötelező kelléke. Valamiért minden kétségbeesetten kapkodó cégvezető azt hiszi (nemcsak-IT  problémánál), hogy úgy lesz a cége megint talpraállítva S.O.S, hogy emberek értelmetlenúl hajtva vannak 48-72 órán keresztül. Ahelyett h. meglenne a rendes 8 óra alvásuk, kipihenten, friss fejjel jönnek az új ötletek. Egy 48 óra alvás nélkül meg a DIR parancsot elrontja az ember (én biztosan). Voltam már pár ilyen szitu szereplője (nem okozója, hanem a Mr Wolf megoldóember): szar is volt, utáltam is, az ember őszintén mondjuk ki a háta közepére kívánja az egész helyzetet. Mikor vége és sikerül a megmentés, életre kell az összetákolt valami, megy a körbegratulálgatás, örömködés, meg a fogadkozás a főnök(ök) részéről h. na itt most mindenki faszán dolgozott, ha ennek teljesen vége, elmegyünk 1 jót sörözni, mind a vendégeim vagytok stb. Jóleső érzés rendberakni a szart, tudni h. értelmetlenül sok energia rápazarlásával sikerülhet. De az embernek azért őszintén szólva nem hiányzik ez havonta-3havonta megismételni. Az 5.-6. ilyen erőltetett menet után elgondolkozik: miért csinálom ezt még mindig? Főleg ha nem egy kivédhetetlen betörésről, ransomware támadásról, teljesen irreális lehalásról van szó. Hanem egy tudottan gyenge szar architektúra, sóherségből-spórolásból évek óta nem kezelt ismert gyengeség miatt hasal el a teljes rendszer.

Az ember fejében ott motoszkál, h. én itt csak 1 tűzoltómunkás vagyok, a cégtulaj keresi ezen a valag milliárdokat évente, persze h. itt járkál fel-s-alá idegben már 3. napja, mert a megélhetése múlik rajta itt és most. Kihúztam/tuk a seggét a szarosgödörből. Jár majd érte a buksisimi mindenkinek aki itt volt, lehet h. lesz 1-2 pizzaparty v. céges sörözés, de aztán minden megy tovább ugyanúgy. Én meg az 5.-6. ilyen után (nem feltétlenül ugyanannál a cégnél) már nem igazán igénylem ezt a cirkuszt. Tudom h. meg tudok oldani ilyen szituációt (meg tudom h. én a kialvatlanságot nem tudom elviselni, nem szégyen az ha 24 óra után nem bírom tovább és le kell feküdnöm, mert utána viszont megint használható vagyok). Nem egy apollo13-ról v. csernobilról beszélünk ahol az életed (többek élete) múlik rajta mennyit tudsz dolgozni alvás nélkül. De ezt leszámítva mire jó ez Nekem?

Teszemazt egy site reliability engineer munkakör egy nagy multinál erről szól? Hogy amikor beüt a gebasz (nem ha, hanem amikor), akkor ott szopik vele 24-48-72 órákat. Amikor meg nincs gebasz, akkor munkakörből fakadóan here-vere? De amikor nem ez a munkaköröd, csak beleesel a helyzetbe, az fáj.

Teszemazt egy site reliability engineer munkakör egy nagy multinál erről szól?

Nem. A SRE arról szól, hogy lehet mindezt automatizálni. Tehát egy jó SRE esetén a PH eset úgy zajlott volna le, hogy július 22-én, 11 óra 30 perckor jött volna egy warning, hogy az egyik node problémás, az orchestration ezért tolt rajta egy drain-evict-poweroff triót, átmozgatta az ott futó szolgáltatásokat máshova, behúzott helyette a hw pool-ból egy új gépet, felhúzta rá a korábbi állapotot, storage sync után betette, mint használható node. Mindez kb. service disruption nélkül.

Az SRE dolga az, hogy ez így történjen, amit leírtál, az nem az SRE munkakör, hanem annak az ellentéte vagy hiánya.

https://iotguru.cloud

Tegyük fel h. nem-kivédhető katasztrófa történt, amire nincs 3kattintásos azonnali forgatókönyves megoldás.

Az SRE lesz az aki hazaszól az asszonynak h. most 3-4 napig nem látsz babám, a gyereket most te hozod-viszed oviból, az esti program is lemondva a hét hátralevő részében (hétvégét is beleértve természetesen), nyaralni mentünk volna 2 nap múlva de az is sztornó?

Tegyük fel h. nem-kivédhető katasztrófa történt, amire nincs 3kattintásos azonnali forgatókönyves megoldás.

Mint például?

Alapvetően két opció van:

a, a rendszer önerőből, humán beavatkozás nélkül visszaáll üzemszerű állapotba,

b, el kell indítani a DR-t, a rendszer önerőből, humán beavatkozás nélkül visszaáll mentésből üzemszerű állapotba a DR alapján.

Az SRE lesz az aki hazaszól az asszonynak h. most 3-4 napig nem látsz babám, a gyereket most te hozod-viszed oviból, az esti program is lemondva a hét hátralevő részében (hétvégét is beleértve természetesen), nyaralni mentünk volna 2 nap múlva de az is sztornó?

Neked nagyon be van ez ragadva... igen, értem, 10-15 évvel ezelőtti üzemeltetési környezetben ragadtál és halvány fogalmad nincs arról, hogy jelenleg hogy szokás üzemeltetni magas rendelkezésre állású rendszereket.

Nincs "pet", "cattle" van. Nem gyógyítjuk a háziállatként tartott szervert, nincs mit nézni 3-4 napig. Leöljük, ha köhögött egyett, script felhúz nulláról újat helyette, adatok automatikusan mennek rá snapshot + a replication journal alapján és megy minden tovább. Nem megyünk be simogatni a szervert, nincs CLI toszogatás, nincs kattingatás, manual olvasgatás. Leöljük, indul a másik helyette. Ha az egész DC leállt, akkor a másik DC átveszi a melót, felskálázza magát. Ha a másik DC is megállt, akkor mentésből felhúznak script-et mindent egy harmadik DC-ben. Ha a mentés sincs, akkor meg már mindegy.

Erről szól az SRE munka, nem arról, hogy 3-4 napig szopnak, az a te világod, a te életed.

https://iotguru.cloud

Félre ne értsd, nem az én világom. Ha az lenne, már felakasztottam volna magam. Vagy a tulajt. Legutóbb 2020-2021-ben csináltam előző melóban 1 éjszakázós tűzoltást. Még előtte másik munkahelyen volt még 1-2 nagyobb.

De attól függetlenül 2025-ben is előfordulhat bárhol az a fajta szopás-faktor ami most a PH-nál van. Nagyobb a világ mint a te buborékod.

Az általad vizionált 3 kattintásos zéro emberi munka minden megy automatikusan szép mese, mégis megdöglik az Azure is minden évben 1-2 alkalommal. Van hogy napnál hosszabb időre is. Pedig azt aztán a mikroszoft viszi, azoknál senki nem ért jobban hozzá a bolygón ma 2025-ben, igaz?

Nem mindig csak az elefántcsonttorony világodban lehet a hiba. Ha felrobban az ország legnagyobb erőműve ami a fél szigetet ellátja árammal, akkor neked is sok dolgod lesz akármennyire is szeretnéd 3 kattintással letudni oszt menni haza sört inni. (ennél pont ott voltam Nicosia-ban, délelőtt lett volna találkozó a ciprusi Elmü IT-vezetőivel, nem meglepő módon hazaküldtek minket).

De attól függetlenül 2025-ben is előfordulhat bárhol az a fajta szopás-faktor ami most a PH-nál van.

Ahol SRE van? Ott nincs ilyen szopás.

Nagyobb a világ mint a te buborékod.

Hja, de szerintem ez rád is igaz, hogy van egy buborékod, egy szar világlátásod, ahol minden is szar és minden csak szar lehet. Én időnként már sajnállak, de aztán mindig rájövök, hogy neked ez a szar világ az, amire szükséged van és nulla effort van a részedről arra, hogy jobb körülményeid legyenek.

Az általad vizionált 3 kattintásos zéro emberi munka minden megy automatikusan szép mese, mégis megdöglik az Azure is minden évben 1-2 alkalommal. Van hogy napnál hosszabb időre is. Pedig azt aztán a mikroszoft viszi, azoknál senki nem ért jobban hozzá a bolygón ma 2025-ben, igaz?

Írtam én, hogy nem döglik meg? Nem. Azt írtam, hogy a megdöglés utáni helyreállítás automatikus. Igen, időbe telik, addig vagy degraded a szolgáltatás vagy áll, aztán meg helyreáll. De nem az van, hogy az SRE jár gépről gépre 72 órán át és gépeli be a parancsokat, hanem az SRE dolga az, hogy ezek az automatizmusok helyreállítsák a szolgáltatást, ha mégse áll helyre, akkor is automatizmust javít, nem gépeket.

Ha felrobban az ország legnagyobb erőműve ami a fél szigetet ellátja árammal, akkor neked is sok dolgod lesz akármennyire is szeretnéd 3 kattintással letudni oszt menni haza sört inni.

És akkor mi van? Másik DC másik régióban átveszi a feladatot. Sárga warning a monitoring rendszerben.

https://iotguru.cloud

Hja, de szerintem ez rád is igaz, hogy van egy buborékod, egy szar világlátásod, ahol minden is szar és minden csak szar lehet.

Hány magyar kkv-nél, és multinál fordultál meg mint alkalmazott az elmúlt 15 évben?

és nulla effort van a részedről arra, hogy jobb körülményeid legyenek --> nem adnak 1 eur-t sem laborra, 4 éve kéri 100+ ember, a 4. laborfelelős cserélődik (~évente nevez ki a cég újat, mindegyik leszarja a témát), munkavállaláóként ezen a helyen ennyit tud tenni az ember. Amint találok olyan állásajánlatot ahol ezt garantálják (és jobb lesz a munkahelyi morál mint itt), léptem.

És akkor mi van? Másik DC másik régióban átveszi a feladatot. Sárga warning a monitoring rendszerben. --> Hogy mi van? Az van h. a CTO a képedbe mondja h. nincs rá pénz, oldd meg 1 DC-ben, csá, zárd be magad mögött kifele az ajtót!

Hja, de szerintem ez rád is igaz, hogy van egy buborékod, egy szar világlátásod, ahol minden is szar és minden csak szar lehet.

Hol írtam, hogy minden szar? :D

Hány magyar kkv-nél, és multinál fordultál meg mint alkalmazott az elmúlt 15 évben?

Konkrétan ezek az ügyfeleim, ahol K8s és CI/CD bevezetéseket csinálok.

Hogy mi van? Az van h. a CTO a képedbe mondja h. nincs rá pénz, oldd meg 1 DC-ben, csá, zárd be magad mögött kifele az ajtót!

Miért akarna egy SRE ilyen körülmények között dolgozni, amikor n+1 fasza ajánlata van hetente? :D

https://iotguru.cloud

Ha nincs meg a munkavégzéshez szükséges feltétel, akkor nem lehet a munkát elvégezni. Az, hogy sokan szarból várat építenek, megvan itt a balkánon, de ahhoz is kell legalább valami szar, amiből lehet építkezni.

Fontos azt is érteni, hogy amikor kritika éri a beszart rendszert, nem feltétlen a személyt kritizálják, aki a szart puszta kezével próbálta egyben tartani éveken át "hősi" erővel. Hanem a céget, aminél ez így megy. A hősünk max balek és hamarabb viszi el agyvézrés, mint a nyugdíjkorhatár.

Igen, simán. Elég gyorsan fel szoktam mérni, hogy meddig ér a trágya a cégnél. Elmerülni meg nem akarok benne.
Amíg van egy barom, aki húzza a céget a gödörből - akár a saját egészsége, élete árán is -, addig nem fejlődik a cég, a tulajdonos.

A számok kedvéért: 30+ felmondás / szerződésbontás van a hátam mögött.

Hány magyar kkv-nél, és multinál fordultál meg mint alkalmazott az elmúlt 15 évben?

Konkrétan ezek az ügyfeleim, ahol K8s és CI/CD bevezetéseket csinálok.

A kérdés alapján a metódusodnak egy int értéket kellett volna visszaadnia. Ehelyett te visszaadtál egy objectet, amiről a még reflexióval sem lehet megmondani, hogy miféle adat-infó van benne. 

Várjál már, eddig olyan megoldásod volt, ami mindenre is jó, hogy a fizikai vasadat beviszed szolgáltatócéghez, felhőnek becézve, és az minden problémát megold, havi 66.000-ért.

Aham. Kivéve, hogy nem viszek fizikai vasat a szolgáltatócéghez, hanem ők adják a vasat is, rá az OS-t a vashoz konfigurálva, inclusive 7/24 ügyelet, monitoring, mentés és kvázi azonnali cseregarancia. És ez bizony igen sok problémát megold, ugye arról van szó, hogy van 2x6 node, 48 core, 160 GB memória, 2400 GB storage (már tükrözve! ennyi, raw ~4800 GB), és ez ~200 USD havonta, felhőben. Sehol nem írtam, hogy mindenre is jó, csak arra, hogy pont van egy ilyen projektem, jóval nagyobb terhelésre, mint amit a PH-ból kinézek.

Mit akarsz még hozzátenni?

https://iotguru.cloud

Csak egy apró kiegészítés: jó a szolgáltatói mentés, de a legtöbbször nem elegendő, legalábbis az adatbázishoz nem. 

Nem azért, mert legitimizálni akarom a saját bizniszem létjogosultságát, hanem mert egyszerűen kevés a napi 1x/4x vagy akár 24x mentés egy olyan rendszer mögött, amiben fontos tranzakciós adatok vannak.

Kis tervezésel és odafigyeléssel viszont lehet emelni a szintet, például csinálni egy DB replikációt, így a másodlagos adatbázist tetszőlegesen gyakran meg lehet állítani, és akár kidumpolni, akár valami CoW filerendszerben egy snapshotot gyártani hozzá - deduplikációval kombinálva még sok helyet sem igényel. Eleve a slave megléte ad egy plusz biztonságot, a logból lehet tetszőleges időpontra point-in-time recoveryt csinálni, másrészt lesznek gyakori konzisztens mentések - jó esetben másik helyszínen / másik szolgáltatónál.

Persze minden adatbázis más, de az elv hasonló, és mindegyiknél lehet olyan megoldást találni, ami mellett nyugodtan lehet aludni.

Persze, csak ha mar kimozdulunk on-prembol cloudba, akkor nem erdemes adatbazist uzemeltetni mezei VM-ekben, hanem ott a managed DB, amivel megsporolhato az, amit irtal. Raadasul Serverless esetben csak a hasznalatert fizetunk, ami akar olcsobb is lehet, mint folyamatosan jaratott VM-e(ke)rt fizetni. Az automatikus skalazasrol nem is beszelve.

> Tegyük fel h. nem-kivédhető katasztrófa történt, amire nincs 3kattintásos azonnali forgatókönyves megoldás.

Akkor DR plan felüt, a megoldás az "Adatközpont teljes elérhetetlensége/megsemmisülése" fejezet környékén keresendő. Azért ha rendesen meg van tervezve, 24 órának elégnek kellene lennie a legfontosabb funkciók visszaállítására tetszőlegesen kiválasztott felhőben.

szartak az egészbe, ótvar tróger szar munkát végeztek. a cikkek felületesek voltak és minél jobban arra mentek, hogy a lehető legnagyobb flame keletkezzen a fórumaikon. +1

azt kapták vissza amit adtak, e van. a kutyának se fog hiányozni. 

A fórum kapcsán azért vitatkoznék, ami néha itt megy, ahhoz képest a PH fórum egy apácazárda, de ez főképp a topicgazdáknak/moderátoroknak köszönhető. Aztán persze kivételek mindenhol vannak, gondolom neked is volt egy rossz élményed, és onnét jön az ellenszenv, de nagy általánosságban nézve szerintem teljesen kulturált légkör van (volt?) ott. Kivétel lehet a cikkekhez kapcsoldó comment szekció (mert azoknak nincs gazdája), de cikkeket tényleg kár ott olvasgatni, a kapcsolódó commenteket meg pláne.

Mivel törölni/rejteni szokták a tiltást kiváltó vitákat, így utólag sokszor nem is tudni. De valóban találkoztam én is olyan userekkel, akik értelmesnek tűntek, míg egyszer ki nem bannolták. Régebbi blogpostok vagy topicok közt lehet néha rácsodálkozni, hogy  a régebbi beszélgetők neve helyén már csak a placeholder van.

Aztán lehet valamilyen témában valakivel összevesztek. A moderációt könnyű megtéveszteni pszichológiai hadviseléssel. Ha valaki amúgy hazudozik, valamilyen idiótaságot terjeszt folyamatosan, az biztonságban van addig, amíg szépen mondja. Viszont előfordulhat, hogy valaki cifrábban válaszol, mert ezredjére nyomják a propagandát/baromságot a sokszor megcáfolt emberek és repül a ban érte. Nem is közvetlenül a poltopikra gondolok, mert az külön világ még azon belül is. Hanem akár elektromos autós, műholdas, más technikai témában is van ilyen - például Elon Musk cégeiről szóló híreknél mindig összeverődik a hisztérikus banda, bár ezen a róla szóló eltorzított zagyva "hírek", tudatos félrefordítások, baromságok átvétele sem segít. De ilyen a média, kell a szenzációt csinálni.

Előfordulnak témák, ahol a csőcselék tömegesen letámad valakit, mert a propaganda szerint gyűlölendő emberre / munkájára / termékére szórt ócsárlásnak ellent mond és esetleg tényekkel zavarja meg a hisztériát. Na akkor könnyű bant kapni, mert rombolja a közösséget vitatkozni velük. Ilyen témákban már inkább nem is vagyok nagyon aktív, max egy-egy kommentben megjegyzem már megint nem nézett utána a cikkíró, de rájuk hagyom buta gyűlölködést.

Talán úgy tudnám összefoglalni, hogy hazudni/manipulálni nem szabálytalan. A moderátorok pedig nem értenek a témákhoz sokszor, így nem tartalom, hanem érzelem alapján tiltják ki azt, akit sikerül kiborítani a manipulátoroknak.

Onnan nem, de más fajta helyről (444hsz disqusra épülő hirtelen hírportál) már tiltottak ki, mert valamelyik félreértett egy mondatot és az éppen vörös ködbe csapó zsigeri gyűlöltet miatt szórták a bannokat. Azóta is jókat örömködnek egymásnak, hogy hol vannak a kritikusok - mikor már mindet kitiltották :D

Hát ha cikkírót ekéznek, az megint egy más világ. A PH-n a cikkek alatti comment szekcióból fórum topic lesz automatikusan, ahova minden betévedő hülye böfög valamit, mert nem fórumozni megy, hanem cikket olvasni, majd trollkodni. Én a fórum részben a tematikus topciokban max olyat láttam, hogy töröltek vállalhatatlan commenteket, amikor nagyon durván elszaladt a ló valakivel (olyankor esetleg kapott 1-2 hét bant, de ahhoz tényleg vállalhatatlanul kellett viselkedni). Olyat viszont még nem tapasztaltam, hogy értelmes, nem kurvaanyázó commentelőt örökre bannoltak, csak azért mert csúnyát mondott valakire/valamire, amit a közösség vagy a ph üzemeltetés kedvel.

"csúnyát mondott valakire/valamire, amit a közösség vagy a ph üzemeltetés kedvel."

Nem erről van szó. Azt szabad általában, mert harmadik félről szól. Lehet szidni közszereplőket. Lehet tudományt tagadni (ha nem kovidról van szó). Sokmindent lehet, kevés kivétel van, amit saját meggyőződésből szankcionálnak.

Viszont valakit helyretenni kicsit, az már személyeskedésnek számít. És ha valakit "hivatalosan" figyelemeztetnek, az felkerül a profilra valami belső nyilvántartásba. És valsz van valami szabály, hogy hány után milyen büntetés jár. Mivel hülyékből végtelen számú jön, így aki kevésbé bírja a hülyéket, az idővel kipontozódhat. Ha nincs elévülési idő, akkor lehet pont azért hullanak a régi profilok.
Azt hiszem nekem még nincs náluk priuszom, legalábbis nem írt rám ilyen kapcsán moderátor, amit állítólag megtesznek figyelmeztetéskor. Viszont volt már, amikor pár hülyére reagálva csak adott moderátor jóindulatán múlott, mert akár adhatott volna is.

Dehogyis. Prohardver, Mobilarena, Gamepod mind igenyes, hianypotlo cikkeket es teszteket kozlo oldalak. Szivesen hallanek mas oldalakrol amik hasonlo vagy magasabb szinvonalt kepviseltek, en nem ismerek ilyet. A reklamozas is teljesen kulturalt volt, nem ment a kontent elvezhetosegenek rovasara.

Hardverapro is egy nagyon hasznos oldal, IT eszkozoket nagysagrendekkel hamarabb el lehet rajta adni mint Jofogason, Marketplace-en. Nem nagyon kell peldaul szurni az analfabeta, olcsojanos erdeklodoket.

Nekem kifejezetten hianyoznanak.

( bennyh | 2025. 07. 25., p – 09:52 )

Szerkesztve: 2025. 07. 25., p – 09:53

Kiraktak már egy bocsi.html-*t, de arra már nem voltak képesek, hogy minden domain alatt menjen https-el is...

Szomorú...

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

"Adatbázis szerverünk hardveres meghibásodása végül a rendszert könyvtár szintig magával rántotta, amit teljes erőbedobásunk mellett sem sikerült még helyreállítani."

Ez is milyen slendrián megfogalmazás, hogy "könyvtár szintig". Azt ki kellene nézniük a célközönségükből, hogy megértik a 
megsérült a fájlrendszer az adatbázisszerverünkön mondatot. 

( freeoli v | 2025. 07. 25., p – 10:08 )

Az a legszomorúbb, hogy pár éve már volt egy teljes összeomlásuk, kb ugyanígy, de akkor ha jól emlékszem a db szerver raid/ssd/hdd része halt meg. 

"nettó árbevétel (2024. évi adatok) 116 590 ezer Ft, adózott eredmény (2024. évi adatok) 2 millió Ft és 10 millió Ft között"

Azért egy ekkora cégnél a cég alapját adó infra ilyen szintű igénytelensége, hogy is mondjam, általános magyar vállalkozói hozzáállásbeli probléma. Ez kibaszott nagy szégyen és a magyar random kft-k iszonya mennyisége fut szemeten, lopott szoftveren, stb.

"Ez kibaszott nagy szégyen és a magyar random kft-k iszonya mennyisége fut szemeten, lopott szoftveren, stb."

Muter mar joideje nyugdijas, 73 eves. Be szokott segiteni munkaugyekben egy cegnek, aminel tobb mint 2 evtizede dolgozik/dolgozott.
Persze csakis HO-bol. 
L2TP/IPSEC vpn, rdp, nincs tulbonyolitva, persze MFA nincs.
Par hete raneztem a kepernyojere: RDP-vel fent volt egy win 2016 szerveren (ami ugye 2022 januarja ota EOL), jobb also sarokban viritott, hogy "Activate Windows, Go to settings to activate Windows". Anyu elmondasa alapjan evek ota ilyen. Gondolom csak rearmolgatjak 180 naponta, vagy valahogy patkolgatjak. 
Azt nem tudom milyen vas/infra van alatta, de a fentiekbol kiindulva azert vannak elkepzeleseim.
Es egy tobbmilliardos arbevetelu cegrol beszelunk.

I don't run often, but when I do, I run as administrator.

Windows-t kb. a 8-as óta / Server 2008 R2 óta nem kell aktiválni, és nem fog leállni. Kiírja a basztató szöveget loginkor meg a jobb alsó sarokba, ezen kívül kliens oprendszereken nem enged néhány dolgot (desktop wallpaper, meg színséma) állítgatni amíg nem aktiválod. Amúgy meg elfut ebben az állapotban 15 évekig.

Ezért láthatsz production szervert az aktiválós szöveggel futni 8-10 éve.

Szerintem ez 1 korrekt(ebb) hozzáállás a MS részéről, mint hogy állandóan leállogasson.

A trial más tészta, az valóban leáll 180 nappal az install lejárta után. Talán 1 v. 2 alkalommal meg lehet hosszabbítani 90 nappal, de utána végleg leáll. Illetve talán be lehet neki adni production key-t, de ebben nem vagyok biztos, windows verzió-függő. Talán volt belőle szopás is valamelyik kollégámnak 10+ éve, amikor projecten trial windows-t telepítettek, mert éppen nem jött meg a kulcs. Csak aztán időközben lejárt a trial, és nem tudták már életre kelteni sebtében megvett production kulccsal sem. Ott azt hiszem reinstall lett a vége.

( kassaiviktor | 2025. 07. 25., p – 11:58 )

nem is tudtam, hogy ezek az oldalak még léteznek. ebből kettőt ismertem, utoljára 10 éve látogattam meg őket.

nem fognak hiányozni

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

A kiépült közösség (leszámítva az istencsászárt játszó moderátorok és topik házigazdák) jó, sok hasznos dolgot megtalálsz ott, amit itt a hupon soha. Ha 10-15 év alatt 1x nem léptél be oda, nem tudsz róla valós véleményt alkotni.

Én sajnálnám ha végül bedőlnének.

( secretx v | 2025. 07. 25., p – 12:37 )

Ilyenkor az RTO & RPO meg a többi párbetűs hülyeség milyen hasznos is tudna lenni (ha lett volna).

Hell is empty and all the devils are here.
-- Wm. Shakespeare, "The Tempest"

( persicsb | 2025. 07. 25., p – 13:47 )

Eltelt újra egy nap, és még mindig semmi. Tudjuk, az onprem üzemeltetés az jobb. Látjuk.

Ha nem volt normális backup (vagy megette azt is a kriptovírus), akkor a "felhőben" levő rendszernél is pont ezt látnád. Ha meg lenne, akkor on-premise szerveren is menne már a cucc. Akár 30 perc alatt, de ha elindítom mentésből a virtuális gépet (Veeam és a többi simán tudja), akár 1 perc alatt is. 

Szóval, baromságokat beszélsz. Látjuk.

trey @ gépház

Sőt on-premise szervereken is lehet felhős technológiákat használni, mint OpenStack. A geodiszlokáció körülményesebb, de az is megoldható. 

Meg olyat is láttunk már, hogy leégett (egy nem A kategóriás) felhőszolgáltató ahol nemhogy geodiszlokáció nem volt, de ami egy épületen belül volt, arról még a backup is helyben volt.  

( Czo v | 2025. 07. 25., p – 15:25 )

Azta.... SIKERULT KIRAKNIUK egy statikus paget, hogy baj van. Kedd ota nezegetjuk a timeoutot, ma meg mar a connection refusedet. 

( Sixday v | 2025. 07. 25., p – 15:27 )

Ez az egész leállás egy nevetséges majomparádé bárkinek akinek van kicsit is komolyabb üzemeltetési tapasztalata.

Rackforest a megkereséstől számítva pár órán belül ad dedikált gépet, 20 Xeon fizikai magos gép hardware raid-del 75 nettó havonta, kell még bele plusz ram meg diszk és kész.

Alap linux meg a csomagok feláll rajta 1 órán belül, környezet bekonfigolva max még 1 óra (elvégre minden confignak a backupban kell lennie), a data backup mire lefut azt nem tudjuk, de hogy nem 2 nap az szinte biztos :)

Ha ennyi pénzt nem termel ki az a lapcsalád akkor meg nincs miről beszélni.

Ha nem volt backup és azért kókánykodnak az eredeti gép helyreállításával akkor meg megint nincs miről beszélni.

Ekkora leállást nem lehet kimagyarázni senkinek aki kicsit is ért ehhez, ez színtiszta garázspistike balfaszkodás.

Legalább ZFS-t használtak volna, ami ugyan backup nélkül régen elégtelen megoldás, de a semminél, illetve annál ami most van náluk az is sokkal jobb. Főleg ha az adatbázis flush-olva lett volna a snapshot készítése előtt. Legalább az utolsó snapshot előtti állapotot vissza tudnák állítani. 

( g3rg0 | 2025. 07. 25., p – 16:17 )

Nekem fogalmam sincs, ezért kérdezem, hogy nagyságrendileg mekkora éves költségvetése van egy ekkora "lapcsaládnak" infra üzemeltetésre? Csak mert azért normális mentéssel azért lehetne valamire jutni. 

( dyra | 2025. 07. 25., p – 16:59 )

Szerkesztve: 2025. 07. 25., p – 17:00

Saját webmotor, saját fejlesztés, zárt kód. Brutál elavult lehet. Ha valami három napja nem áll helyre, ott már komoly szerkezeti gondok vannak. Vagy nincs normális mentés, vagy ha van, nem tudják visszatölteni. A RIOS-hoz (így rémlik a webmotoruk neve) alig ért pár ember, lehet már olyan régi, hogy mai rendszereken meg se mozdul. Itt nemcsak technikai, hanem üzemeltetési és vezetési hibák is vannak – ennyi ideig nem áll le egy normálisan karbantartott rendszer.

Elnézést, nem olvastam végig a topikot, nem is követem, csak ez jutott eszembe a történetről. Volt egy olyan érzésem, hogy akár másnak is eszébe juthatott, ezért a rajz azonosítójával nyomtam egy keresést az oldalra, nem lett találat, így betettem a linket.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( tompos v | 2025. 07. 25., p – 23:10 )

Undorító, amit sokan itt művelnek. Vajon az okosok ilyenkor jobban érzik magukat, h megmondják, h elcseszte a PH? Azt gondolják, h a PH-sok maguktól nem tudják?

Korábban hallottam egy mondást: kétféle sysadmin van, akinek volt adatvesztése és akinek lesz. Kívánom mindenkinek a lelkiismerete szerint a legjobbakat.

 

Szakmai beszélgetés zajlik, nem kárörvendés. Az nyilvánvaló, hogy elcseszték, arról beszélgetünk, hogy vajon hogyan cseszték el. És arról, hogy manapság hogyan lehet ilyet elkerülni. Tanulni is lehet belőle. Ha adnak ki pontosabb hivatalos post mortem blogpostot, akkor majd még jobban kielemezzük. Nekem az a fura, hogy sokan érzelmi kérdést csinálnak belőle, amikor tényekről/műszaki megoldásokról van szó.

Különösen facebookon szált el nagyon már az érzelmi hisztéria, mert jaj báncsák a ph-t a gonoszok. Ott mondjuk a hozzá nem értő többség ír, akinek fogalma sincs az üzemeltetés technikai hátterérről. Itt is sokféle látogató van manapság már, de talán nagyobb arányban vannak szakmailag hozzá konyítók is. Ez nem a síróasszonyok topic, ott vevők az érzelmi manipulációra.

Olyan szintű kiesés (valamint amatőr a kommunikáció és nincs semmilyen vésztervük), ami mellett nem szabad szó nélkül elmenni, még ha PH fan is az ember, pláne, mert egyeseknek a bizniszét másoknak meg úgy néz ki az életüket kukázták. Úgy viselkedtek, mint a mucsaröcsögei tésztagyár, ahol a háttérinfrastruktúra a szükséges rossz vagy még az se. De van olyan mezőgazdasági cég amúgy, ahol már 20 éve komolyabban vették a háttérinfrát, mint jelek szerint a PH lapcsalád. Amondó vagyok a PH ne foglalkozzon a sok dühöngővel, hanem dolgozzanak az újraindításon. De ennyi idő után már vagy meg sem érné, vagy nem is tudják.

PS: a statikus oldalt se tudták elsőre jól közzétenni, valamint ennyi idő után egy csak olvasható, csak cikkeket tartalmazó vagy üres oldalt se tudtak virítani.

Színes vászon, színes vászon, fúj!

Kérem a Fiátot..

Ha hírdetsz H.A.-n, és nagyüzemben csinálod, van fizetős accountod, akkor ugye teljesen jogosan várod el h. működjön az oldal? Ha eladtál több dolgot is pont a lehalás előtt, jogosan vagy ideges mert a kontaktokat nem tudod elérni (az utolsó pillanatban az üzeneteket megkaphattad még emailben is. De oda pont nem bírták berakni az üzenet törzsét, csak hogy ki üzent neked és milyen témában:

 

Kedves XY!

Új privát üzenetet kaptál a HardverAprón ABC felhasználótól.

Hirdetés: Xbox 360 Játékok 1500Ft.-/Darab

Itt nézheted meg: Privát üzeneteim

 

Tehát sem a konkrét üzenet nincs benne, sem az elérhetősége az ABC felhasználónak. Ha nem a H.A. oldalon belépve akarod kezelni a privát üzeneteidet, az ABC felhasználó adatlapján meg lehetNE nézni a tel.számát, emailcímét, de ahhoz Captcha kellett mindig is. Most meg az oldal döglött állapota miatt nem tudod ezt az infót sehogyan sem kikeresni. Ez jó nagy "single point of failure" ha fel akarod venni a másik féllel a kapcsolatot egy ilyen havária esetén.

Főleg akkor, ha a H.A. mellett muszájból odaígéred másnak is ugyanazt a cuccot Jófogáson vagy Vaterán... Utána meg kapod majd a minuszolós cunamit H.A.-n (már ha visszaááll), ami instant bizalom-vesztés ahhoz képest, mint hogy 15 éve csak-plusszos értékelésed volt, most meg megszórják 8-10en minusszal, egyből sokat fog rontani a megítéleseden. Én sem szívesen üzletelek valakivel, ha csak annyit nézek meg az adatlapján h. jéé, volt az elmúlt 1 hónapban 10 minusza, akkor már állnék is tovább. Columbo-t játszani, h. nézzük meg mik voltak ezek a minuszok, olvassuk el a szöveges feladatot is h. pontosan miért kapott minuszt, erre az eladók/vevők nagyon kicsi része fogja elcseszni az idejét. Inkább keres másikat akinek nem voltak minuszai mostanában.

Én H.A.-n adok-veszek évente kb. 30-50-es nagyságrendben cuccokat. Vatera szar, mert eleve drágább a jutalékos rendszerük miatt, aki oda feltölt eleve drágábban teszi fel a filléres cuccokat is. Plussz H.A.-n a kategorizálás számítógép hardverre optimalizált, CPU socket alapján szűrés a Vatera-n soha a büdös életbe nem lesz, ezzel nem tud versenyezni.

A jófogás meg a legvégső esetben. Annak a keresője is szar, szűrés, kategorizálás, sorrendezés minden szar. Használt bugyogó között keresed a processzort. Az eladókat nem lehet minősíteni, nincs előéletük. Nem tudod h. csalóval van-e dolgod, 5 perce vagy 15 éve regisztrált, nem látod mennyi cuccot adott már el, milyen az értékelése stb. Oda csak ha nagyon muszáj akkor megyek.

Véleményes. Pl. nem biztos, hogy az ukránok már rájöttek, hogy elcseszték (tgyk. ők maguk cseszték el). Pedig ott azért sokkal nagyobb a baj, mint a Prohardvernél.

Természetesen azzal egyetértek, hogy a szakmai találgatások és szakmai károgások lehülyézés hiányában is működnének. Ám az is igaz, hogy az emberek élvezik a HUP nyújtotta szabadságot. A munkahelyen sok mindent tolerálniuk kell, más fórumokon és kommentszekciókban erős öncenzúrára kényszerülnek, ráadásul a klimatizált irodából néha ki kell menniük a kánikulába, szóval valahol érthető, hogy kihasználják az itteni szabadságot.

:)

De hát erről van szó? Szó szerint elcseszték a PH-sok. Nem akkor amikor rossz CPU-t húztak maguknak a tálcáról, hanem már akkor amikor hibásan tervezték meg a rendszerüket és ezt az eltelt évtizedek alatt sem korrigálták. 

Ami az "emberi" oldala a történetnek, ezek után valahogy nem tudom sajnálni a PH-t. "Visszanyalt a fagyi", most megtapasztalják valamilyen módon azt, amit ők műveltek önkényesen a tagjaikkal. 

(Soha nem volt regem a PH-n, nem is olvastam. Az egyetlen cikk amit valószínűleg tőlük olvastam az a Padavanra fel című írás volt, de sok értelme annak sem volt, mert egy egyszeri fellángoláskény összerakott rendszer még ha egyébként rendben van, frissítések hiányában rosszabb mintha hagyjuk a gyári rendszert. Annál a Xiaomi routernél is az OpenWRT volt a helyes alternatív rendszer.
Veterán plecsnivel sem bohóckodok a hup-on pedig már több mint 10 éve tag vagyok. Szóval ebben részemről nincs semmi személyes)

Nem. Az az undorító, amilyen lekezeléssel hozzááll a PH a témához. Nem baj, ha hibáztak, eltolták, vallják be becsülettel, ne ködösítsenek azzal, hogy van mentésük, de sérült mappastruktúra, meg hibás CPU, meg P2-esek megfejtéseire nem kíváncsiak kezdetű nagyképű lúzer duma. Mondják akkor azt, hogy tehetetlenek, más üzemeltette, volt ugyan biztonsági mentés, de nem visszaállítható, az üzemeltető nekik is ezt a CPU hiba mantrát nyomja, nem tudnak vele mit csinálni, mivel nem az ő kezükben van az üzemeltetés. Ez így tiszta lenne, nem is kárörvendene rajta senki, de ehelyett még mindig a P2-es kókler dumát nyomják a 90-es évek végéről.

Közben már 4. napja áll az oldal, és kétlem, hogy vasárnapra helyrehozzák, legkorábban hétfő, ha egyáltalán helyre lehet hozni, az min. 5 nap. A felhővel jobban jártak volna. 

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Fisher v | 2025. 07. 26., szo – 11:32 )

Most hirtelen az ugrott be, hogy vajon hányan néztek rá a backupjukra, hogy tényleg működik-e.

(A gyárban hetente teszteljük, itthon vagy egy éve nem néztem, ideje...)

Nálam van olyan adatbázis, ahol minden éjjel szrkiptek ellenőrzik, működik-e a backup, és nyílik az alert, ha valami nincs rendben. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

az ellenorzo script ter vissza 0-val. :)

de az mar a backup szerveren fut.

az ellenorzo script tobb mindent csinal, a mentest a backup szerveren restoralja, csinal dbcc checkdb-t, ha meg lehet az adatokon valamilyen integritas ellenorzest csinalni azt is lefuttatja.

neked aztan fura humorod van...

( pepelopez | 2025. 07. 26., szo – 11:36 )

Szerkesztve: 2025. 07. 26., szo – 11:37

de hogy tud ennyire észrevétlenül "elkorruptálódni" a fájlrendszer 2025ben?

 

"The DOS verify on command enables disk write verification"

intel 13. 14. gen keress rá. Gyárilag, stock bios beállításokkal is túlfeszeli magát boost-kor. Intel 1-1,5 évig tagadta. Aztán kamuzott mindenféle gyártási hibákra. Aztán meg kihoztak 4-5 verziót cpu mikrokód fix-re. De ami már megfőtt időközben, azokon nem segít a mikrokód fix.

Igen, tudom, hogy meri bárki is a processzorát stock beállításokkal használni!? Meg az alaplap gyártók nem hibásak, h. factory default unsafe fesz.-el megküldik a processzort, csak h

 cinebench-ben 50 ponttal többet kapjon a gép, mint a konkurrencia!? Meg miért használna bárki szerverben desktop processzort?!

Ez csak egy példa volt legutóbbról a "normálisan üzemeltetett CPU-t nem láttam megdögleni" -ra.

Nem normális a világ. Senkiháziak kezében van a popszakma. Ez történik akkor, amikor műszaki kérdésekben PR-osok, marketingesek, tulajdonosok döntenek, véletlenül sem szakemberek.

Szerencsére ez a hülyeség nincs a mikrokontrollerek világában. Adsz neki 3.3 V vagy 5 V tápfeszültséget, ahogy az a katalóguslapban le van írva, járatod akkora órajelfrekvenciáról, amiről hivatalosan járathatod, de az is lehet, hogy szándékosan lassabban, aztán működik.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ugy emlekszem, a Banana Pi-nek van ipari kivitelu variansa.

De volt egy CNC vezerlonk, ami egy passziv hutesu ipari PC-n futott volna, de nagyon instabil volt a hardware. Vegul egy 8 magos AMD-s gepet tettunk be a helyere, a real time szalak dedikalt magon futottak, es eleg jol teljesitett.

A strange game. The only winning move is not to play. How about a nice game of chess?

Pont ezt írom én is. Ha üzembe helyezéskor nem hibázott, nem volt nyilvánvaló hiba (hiányzó memória, azonnali fagyás, bootképtelenség), akkor én sem láttam még ilyet. Amit írnak alattam, a 13-14. genes Intel, arra sem adok sok esélyt, ha csak az üzemeltető nem volt olyan balga, hogy tényleg desktop gépet tegyen meg szervernek.

Üzemeltetés közben csak olyan procit láttam megdögleni, amit szénné tuningoltak, általában rekordtuningos bajnoksági szinten.

Mondom, felesleges is fejtegetni, mert beszélnek össze-vissza, van mentés, de mappastruktúra sérült, ez is teljes képtelenség, szerintem kb. semmi nem igaz abból, amit mondanak, vagy esetleg mindenkit hülyének néznek, és túlegyszerűsítenek, az meg félrevezető. Ez a CPU hibázott szöveg is hasonló morbidság, amit nem fogunk tudni itt kristálygömbbel megfejteni.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( gyuri23 | 2025. 07. 27., v – 06:17 )

A legújabb posztjukból:

messze a legfájóbb pont, hogy a mentéseinkből is csak az használható közvetlenül, amit az automata mentésen felül kézzel is leszedtünk saját magunkhoz, mert a mentések is korrumpálódtak.

Egy szerver CPU hiba, hogyan rontja el a mentést? Erre azért kíváncsi leszek.

Csak két magyarázat jut szembe, magára a szerverre ment a mentés is ami kapitális hiba, vagy sikerült lementeni az összedől adatbázist és olyan rövid volt a megőrzési idő, hogy nem volt már régebbi mentés. Ez meg csak akkor "szokás" ha mentési eljárás nem tudja az inkrementális módot. Ilyet már láttam többször is.  

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Nekem egyre inkább az az érzésem, hogy nincs nekik semmiféle mentésük. Csak nagyon égőnek érzik kommunikálni, hogy egy szál szerverről ment minden portáljuk mindenféle mentés nélkül. Nehezen hihető, hogy létezik olyan CPU hiba ami a futó rendszer feladatait rendben ellátja, lehet írni, olvasni, módosítani, törölni az adatbázisból, közben a háttértárra kezelhetetlen és értelmezhetetlen adathalmaz kerül. Az eltelt idő arra enged következtetni, hogy nem a backupokkal nem boldogulnak, ami szintén eléggé égő lenne, hanem egy sérült adatbázist próbálnak megmenteni. Ahhoz valóban kell az idő, sőt még a szerencse is. 

Van egy teljes mentésük ami 2025. 04. 30-i, azt fogják - ha jól vettem ki- visszállítani és abból fognak továbbmenni, először a fórum majd a ph! majd a hardverapró oldalt hozzák vissza. Elvileg hétfőn állnak majd vissza hogy elindítják az oldalakt lépésről lépésre.

Még sosem cseréltem procit szerverben. Adatbázisszerverben meg pláne nem, ott a teljesitményt inkább a háttértár sebessége és/vagy a memória mennyisége határozza meg ; de ha már ottartunk, hogy nagyobb proci kell, akkor jöjjön egy új, korszerúbb, nagyobb vas; az aktuális meg félretesz egyrészt ha valami félremegy legyen hova nyulni ; ha spúr a főnökség vagy még azért bőven használható a masina, akkor meg tarcsi gépnek is jó.  Igen, otthon lelkesen cserélem az AM4 foglalatban az egyre erősebb cpukat ; viszont a cégnél, aminek a léte függ néhány adatbázis egészségétől, eszembe nem jutna ilyesmire vetemedni. Egy kritikus szervercserére mindig kell legyen pénz.

Másik észrevételem, hogy hibás procinak egy alap naplózó filerendszeren sem szokása ilyen mértékben adatbeszántást végezni. A sokáig észrevétlen adat / filerendszer korrupció oka tapasztalatim szerint szinte mindig a hibás memóriára vezethető vissza.

 

Na megyek checkelem a hétvégi mentéseket.

HUP te Zsiga !

Válaszul a kérdésedre:

(Minden amit leírok csak teória és vélhetően hibás, ugyan akkor az alapján fejtegetek amit már láttam):

Legjobb tudomásom szerint (mármint amit leírtak a Prohardver -esek) olyan vasról beszélünk, amiben két fizikai processor van és az egyik processort kicserélték egy - az előzőnél - erősebbre. Azt gyanítom, hogy ha valóban ez okozta a problémát, akkor az úgy történhetett, hogy a rendszerük, vagy rendszereik alatt software raid volt (lehetett).

Valamennyi idő múlva ez a softraid szét eshetett (a két különböző processor miatt, vagy ezzel összefüggésben), ami kihatott a performanciára az sql -en (hogy ez most VM volt, vagy a vason közvetlen futott, nem teljesen tiszta, bár szerintem ez utóbbi valószínűbb nekem). A performancia gond miatt egy idő múlva az sql nem tudta írni a disket és megállt (ha ext3/4 fs volt esélyes a read only is). Ezen a ponton ismerhették fel, hogy gond van (hiszen megállt a site) és kezdték el a hiba keresést, meg hiba elhárítást. Gondolom az első az volt, hogy össze rakják a softraid -et, ami nem sikerült, ezért rakhatták vissza a korábbi procit.

Ezen a ponton vagy az történt, hogy bepánikoltak és a hibás disket próbálták a jóra másolni, vagy úgy döntöttek, hogy ha ez nem megy építsünk fel mindent a nulláról. Akár hogy is, nyilván új telepítés és mentésből vissza állás felé mentek. Ekkor derülhetett ki, hogy a mentés szar, nem lehet belőle vissza állni (vagy mivel soha nem próbálták ki a mentésből vissza állást, nem tudták, nem tudják mi a módja).

Gondolom azért tart ennyi ideig a visszaállítás, mert nagy a disk, tehát a softraid lassan inicializál, miközben megy a dump betöltése a DB -be (amit kézzel mentettek) és annak érdekében, hogy minél kevesebb legyen az adat vesztés, próbálják a releváns adatokat a össze kapirgálni (kb ahonnan csak tudják).

Abból kiindulva, hogy nem igazán beszélnek több szerverről, az a tippem, hogy minden egy vason futott, az összes site, fórumok, levelezés, a nyers videókat is itt tárolhatták, minden, így most nagy a baj.

Nem sokat olvastam a sitejaikat, egy egy hw tesztet időnként, meg a szakkiállításokról szóló tudósításaikat.

Én remélem, hogy mihamarabb sikerül talpra állítaniuk mindent.

----
올드보이

amiben két fizikai processor van és az egyik processort kicserélték egy - az előzőnél - erősebbre

Ugye nem?! Hát, ez az amatőrség remélem nem igaz :D Dual CPU-s rendszerben CPU-kat párban cserélünk, egyformákra. Nem hogy "erősebb" nem lehet órajel differenciában, hanem még stepping-ben sem lehet nagyon eltérés. Leginkább sehogy se. Normális BIOS/firmware (brand szerverek) el sem indul CPU Mismatch error-ral megáll. Ha el is indul valami noname alaplap így, a rendszer kajak instabil lesz. Ez nagyon amatőr hiba lenne. 

trey @ gépház

Simán tévedhetek, de FB -on ezt írták...

De különben ha jól emlékezem HP server is csak warningot dob és ha "le okézod" megy tovább.

Ugyan akkor a PC server se kizárható. Ha megnézed az IP -t: ip-lookup.net/neighborhood.popup.php?ip=92.61.114.179 vagy itt: https://www.maxmind.com/en/geoip-demo látsz érdekes dolgokat. A cég aki hostolja az IP -t nem épp élvonalbeli, ismert szolgáltató.

Nem akarok konkrétabb lenni, nem akarok senkit bántani, mert szerintem nagyon sok hibát követtek el az üzemeltetés során, ami összeadódva vezetett ehhez a helyzethez, minden esetre csak jót kívánok nekik a helyreállításhoz és remélem tanulnak az esetből és a szükséges lépésekete is megteszik, hogy ne történhessen ilyen, vagy hasonló leállás a későbbiekben.

----
올드보이

HPE szervereknél egyértelműen le van írva, higy:

To prevent possible server malfunction and damage to the equipment, multiprocessor configurations must contain processors with the same part number

 

Ha valami bűvésztrükkökkel el is indul, az egy nem supportált konfig lesz. Vajon miért?

Egyértelmű, hogy ilyet nem csinálunk. Dzsunka szerver és a brand közti lényeges különbség, hogy itt tesztelik is az egyes komponenseket egymással.

trey @ gépház

A facebookos friss hírnél a megfogalmazás alapján nekem úgy tűnik, hogy 1 proci 64 maggal? 
"- nem, a TB nagyságrendű adatbázisunk nem futott volna el egy desktop i7-ről (64 magos enterprise procink van… volt… csak hát az meg - valószínűleg nem önmagában, hanem az alaplappal tandemben - nem tette meg azt a szívességet, hogy leállt, hanem működött, néha hibásan, és szétverte az adatokat a könyvtár struktúrával bezárólag az adatbázis-szerveren)."

Nem tudom volt-e hardver fejlesztős blogpost vagy nem szoktak olyat kiadni. Hogy tényleg 64 core vagy több proci összesen 64 core vagy 64 thread...

Még két évtized háttérrel is túlzottnak tűnik a TB nagyságrendű adatbázis ha csak szöveges tartalmakat tároltak benne. 

Ha képek is voltak benne akkor reális, pláne ha base64 tárolták ezeket az adatbázisban, ami kapásból +33% tárhely. Abban a korban amikor a működésüket kezdték ez még gyakori volt, és ha már úgy van akkor úgy is marad mentalitás nem volt ismeretlen náluk a most megismert események tükrében. 

De ez megint egy súlyos tervezési hiba. A minimum, hogy külön adatbázisba és külön rendszerve szervezzék a képeket ha már mindenképpen adatbázisban akarják tudni ezeket. 
De ez egy rossz praktika, mert drága I/O, fragmentáció, backup méret- és időnövekedés. A DB sokkal rosszabbul skálázódik fájlkezelésre, mint a fájlrendszer. Ráadásuk CDN/Proxy cache rendszer is nehezebben használható belőle.
A helyes képkezelés hash alapú fájlnév, csak az adatbázisban metaadat és hivatkozás lenne. 

messze a legfájóbb pont, hogy a mentéseinkből is csak az használható közvetlenül, amit az automata mentésen felül kézzel is leszedtünk saját magunkhoz, mert a mentések is korrumpálódtak.

Ez a mondat nálam nem a CPU hibát erősíti, hanem a ransomware teóriát, amit a hardver hibájával próbálnak elfedni...

https://iotguru.cloud

A rendszer alatt szétcsesződő fájlrendszer azért erősen memória(vezérlő) probléma is lehet. Aztán persze ilyesmire is lehet biztosíték valamilyen szinten, ha vas tudja vagy ha több vas van. Az persze egy érdekes történet, hogy futás időben még nem látszott tünet, de mentéskor igen. De az sem kizárt, hogy a másik processz által snapshot kimentésben érintett címtartomány hibázott úgy, hogy nem vették észre vagy valami sunyibb hiba miatt a vas sem vette észre.

Pont az utóbbi hetekben kezdtem játszani hobbiból ősöreg szerver vasakkal (devops kubernetes játszós környezetet futtatni) és magamnak is épp összeállítottam egy x9-es supermicro nagypapát. Látom már az e5-2600v2 széria is tudott olyat, hogy a ramot redundánsan használja, avagy minden művelet két példányban megy, másik memóriavezérlőn és modulon letükrözve. Persze fele kapacitással.  

Gondolod, hogy windows környezetben ment az egész? Vagy telibe felcsatolt meghajtó volt a webszerver és a backup is egy win desktopon a fejlesztőnél? Én nem hinném, bár láttam már csodákat.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Gondolod, hogy windows környezetben ment az egész?

Kurva sok Linux-os ransomware van, botok keresik a nyitott sebezhetőségeket, bejutnak, minden fájlt titkosítanak, amit csak írni tudnak... egy csomóval találkoztam már, amikor hívtak, hogy "jaj, nagy a baj"...

https://iotguru.cloud

Windows-on számtalanhoz volt "szerencsém", de linux-on még nem. Azon beszívni ilyet, hát...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Windows-on számtalanhoz volt "szerencsém", de linux-on még nem. Azon beszívni ilyet, hát...

Elég hozzá egy nem frissített szerver (drupal, wordpress, bármi egyéb), amin van az adott user-nek futtatási joga, már jön egy ransomware, letitkosít mindent és lehet küldeni BTC/whatever, hogy adjanak jelszót, vagy mehet minden vissza mentésből:

# cat read-me3.txt
C3RB3R INSTRUCTIONS
*************************************************************************
IMPORTANT : DO NOT DELETE THIS FILE UNTIL ALL YOUR DATA HAVE BEEN RECOVERED!!!

All your important files have been encrypted. Any attempts to restore your files with thrid-party software will be fatal for your files! The only way to decrypt your files safely is to buy the special decryption software "C3rb3r Decryptor". We have also downloaded a lot of data from your system. If you do not pay, we will sell your data on the dark web.

https://iotguru.cloud

Hát meglehet, hogy aki ennyit küzd egy visszaállítással, az arra is képes, hogy a www-data user írásjoggal érje el a db fájlokat...

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ok, ez világos, de ez azonnal kiderül és nem teszi tönkre a mentést.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

ha az a mentes a host felol indult, vagy a script ami elviszi ott van, www-data alatt ott a credentials a menteshez, neadjisten direktben van ra mountolva, whatever, akkor siman. :)

de itt az infomorzsak alapjan arrol van szo, hogy az utolso ertelmezheto mentes akkor keszult, mikor PHPistike (pun intended) ranyomott valamikor aprilisban...

ha az a mentes a host felol indult, vagy a script ami elviszi ott van, www-data alatt ott a credentials a menteshez, neadjisten direktben van ra mountolva, whatever, akkor siman. :)

de kis perverz vagy :D

Hát én is arra tippelnék, hogy a "jóvanazúgy" teknlódzsiájával lett üzemeltetve :)

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ez oké, de létezik olyan hekker aki direkt a PH rendszeréhez ír egy DB köztes réteget, ami az app felé oda-vissza titkosít/dekriptál, hogy a működésben ne okozzon zavart (ne vegyék észre), de a DB mentés már használhatatlan legyen majd a jövőben? És ez a rendszer a memóriában tárolja a titkosító kulcsot, hogy ne lehessen elmenteni (a user által)?

Itt most általánosságban írtam, úgy indultunk, hogy Linux-ra nincs ransomware, erre írtam, hogy kurva sok van, tipikusan nem frissített szolgáltatásokat és gépeket támadnak, teljesen automatizáltan.

A PH esete más, ott el tudom képzelni, hogy root jogot kapott valahogy a ransomware kit (remote service exploit, local privilege escalation), és a mentés ugyanazon a gépen volt, így szintén titkosításra került. Továbbra is nehezen tudom elképzelni, hogy célzottan csak az adatbázis fájlokat érinti egy CPU hiba, több héten át elrondítja a mentéseket is, majd hirtelen áll meg, előjel nélkül, és csak a DB meg a DB mentés lesz ettől rossz és system wide sehol egy checksum error, ami felkiáltana ilyenkor, hogy baj van.

https://iotguru.cloud

( trey | 2025. 07. 27., v – 09:43 )

Szerkesztve: 2025. 07. 27., v – 09:44

Lazán kapcsolódik (nem a PH! témához, hanem a DB-korrupcióhoz):

Discovering and recovering from PostgreSQL corruption on Matrix.org

How we discovered, and recovered from, Postgres corruption on the matrix.org homeserver

[...]

TL;DR

Let's start with a high-level summary.

The matrix.org homeserver is backed by a large PostgreSQL database instance. Parts of an index on one of tables in this database had become corrupted. We are unsure exactly what caused this corruption, but believe it happened at least a year ago, and likely significantly longer.

The nature of this corruption was such that it had little or no effect at first. However, a background maintenance task which removes old, unreferenced data from this table recently started working on the corrupted region. Due to the corrupt index, the maintenance task incorrectly removed active data from the table, in effect corrupting rooms.

Having identified the problem, we rebuilt the corrupted index, and then restored the data that had been incorrectly removed, from database backups.

[...]

trey @ gépház

( flatline | 2025. 07. 27., v – 12:55 )

Kozben lett hir/fejlemeny, legrosszabb esetben az aprilis harmincadikai offline db mentest tudjak visszaallitani.

I don't run often, but when I do, I run as administrator.

Mit használtak egyébként? Windows vagy Linux szervernek? MySQL, Postgresql vagy valami kereskedelmi sql szerver? PHP? 

up: a web archive alapján úgy látom php volt. Nagyon "bölcs" lépés volt tőlük, hogy keményen küzdöttek a web archive ellen mint malac a jégen:) 

Nem tudom mi volt mögötte. A PHP valószínű, az adatbázist nem tudom, a kolléga megfejtette valamelyik topikban, hogy a WAL emlegetése miatt SQL, de lehet elvileg többféle, pl. MySQL is.
 

Bár én meg azt nem értem, ha valami elterjedt SQL szerver, akkor meg mit mantráznak a „mappaszerkezet”-en, az az SQL-t nem érdekli. Az a baj, hogy annyira írnak mindenfélét, hogy nem lehet semmire következtetni, amire az ember gondolna, azt egy másik szavuk üti is.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

mappaszerkezet alatt olyasmire tudok tippelni, hogy a különböző logikai adatbázis csoportok különböző tablespacekben lehetnek, más fizikai fájlokban. És a wal fájlok helye is lehet máshol. Meg ha a helyi fájlrendszerben tároltak snapshotokat vagy backupokat, akkor azok is. A nagy fájloknak logikusabbnak tűnik, csak a hivatkozásokat tárolni és nem largeobjectként beletenni, de ki tudja, hogy volt. 

Amennyire láttam, valsz az újságíróbb oldaltól jöttek ki az írások, mert valsz elfoglaltabbak a technikai emberek... már ha vannak még. Pl nem tudom ott dolgozik-e még, aki régebben talán fejlesztéssel vagy esetleg a mögöttes szoftveres háttérrel is foglalkozott.

( gabrielakos v | 2025. 07. 28., h – 07:42 )

Írtok itt HA Kubernetes clustertől multizone AWS installációig mindenről.
Ami persze egy csomó problémát megold/elkerül - máshol. 

Itt valójában nem ez hiányzott, sőt szerintem igény se volt rá.
Valószínűleg kompetencia se lett volna hozzá.

Ha nincs igény, nincs akarat (a menedzsment részéről) akkor teljesen felesleges tovább gondolkozni ezekbe az irányokba - mérnökileg bármennyire is jó megoldások ezek máshol. Egyszerűen alacsonyabbak az RTO és az RPO igényeik is. 

Az abszolút minimum ami a megismert architektúrához (és kompetenciához!) illő, korrekt megoldás lehetett volna:

- egy működő offsite backup (mondjuk napi)
- egy leírt, lepróbált disaster recovery plan

Lett volna kiesés? Persze. Amíg az új hardver el nem indul és a backupot vissza nem töltik.
Lehetett volna kommunikálni? Persze, a DR folyamatról simán le tudták volna írni hogy x. lépésnél tartunk az y.-ból, várható helyreállítás ekkor-meg akkor.

Most is valami hasonló megy, csak egy "talált" valamikori mentéssel és nulla transzparenciával. Legrosszabb esetben maguk számára sem egyértelmű progress-el.

Onnantól hogy egy cégnek van bármilyen DR terve és az neki fontos már van miről beszélni, már van mit fejleszteni:
Ezt most vagy megtanulja a management vagy nem.
 

zászló, zászló, szív

Felelős helyen a múltban is (mindig is) volt igény disaster recovery-re.
Hogy otthonra valaki nem csinál magának mentést és adott esetben elvesznek a családi fotók az mindenkinek a maga dolga.

Az hogy éles rendszerről nincs rendes mentés az 20 évvel ezelőtt is hiba lett volna.

zászló, zászló, szív

( goodbyte v | 2025. 07. 28., h – 13:39 )

Végig olvastam kb itt is meg Facebook post alatt is a kommenteket. továbbra sem világos, hogy tud úgy filerendszer / adatbázis korrumpálódni hónpokig, hogy nem veszik észre, és a backup is hibásan megy ki. 

Nem üzelmeltetek most már, amikor üzemeltettem (Power/AIX) minden fontos cucc alatt volt HA/DR. Szóval nem okoskodni akarok, ilyen helyben kell megoldani, abból ami van helyzethez nem volt sose "szerencsém". Csak érdekel a szakik véleménye - feltéve ha igaz amit írnak -, egyáltalán hogy történhet ilyen, technikai szemmel nézve. 

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

A bajnak megvan a maga pszichológiája. Nem egyszerű megtapasztalni, ha például a mesekönyvben pontosan leírt, eddig hihetetlennek tűnő események pont veled történnek meg. Mindannyian azt hisszük, hogy velünk nem történhet meg ilyesmi, aztán néha kiderül, hogy dehogynem. Azt hiszem az egyik autó alkatrész kereskedővel történt, hogy amikor benyalták a zsarolóvírust, egy ideig kamuztak összevissza, egészen addig, amikor már láttak esélyt a gyógyulásra, akkor aztán kiállt az ügyvezető és részletesen közzétette, milyen csúfság történt velük és hogyan. 

Persze, és azért nem tudják se ők, se a jóisten, mert ilyen szelektív procihiba nem létezik, hogy látszólag minden normálisan fusson, csak az adatbázis, mentések sérüljenek a háttérben. Valahonnan a ’gükből rántották elő ezt a procihibás mesét. Én is már a 3. topikban világítok rá erre, több hozzászólás óta, hogy ilyen nincs. Eleve önmagában a hibás proci is nagyon ritka, mint a fehér holló, erre még rá, az, hogy kezdetben jónak látszik, de később meghibásodik, illetve még erre rá, hogy úgy hibásodjon meg, hogy csak szelektív sérülést okozzon, ezeknek a gyakorlati keresztmetszete 0. Így maradjunk abban, hogy a részükről ez a procihibára fogás egy üres duma.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( Sanya v | 2025. 07. 28., h – 15:17 )

amúgy lehetne már fogadásokat kötni, hogy mikor áll föl az oldal?

( tompos v | 2025. 07. 28., h – 17:33 )

Az elobb beszeltem kollegaval. A hetvegen belefutott egy olyanba, hogy reboot utan egy block device-t nem tudott felmountolni a VM. Meg annak a snapshotjait se (0-asak lettek a snapshotok).

GCP. Persze ott ilyen nem fordulhat elo....a dehogy.

GCP. Persze ott ilyen nem fordulhat elo....a dehogy.

Hány nap állás után jelenthető ki szerinted egy rendszerről hogy el lett baszva?

Cloud ide vagy oda.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

A hetvegen belefutott egy olyanba, hogy reboot utan egy block device-t nem tudott felmountolni a VM. Meg annak a snapshotjait se (0-asak lettek a snapshotok).

Hja, 95% SLA van ezekre és nincs garantálva az adat. Hány AZ-ban volt ugyanez a VM? Ja, hogy csak egy AZ volt? High availability szerint több VM is volt? Ja, abból is csak egy? Hát az szopó.

GCP. Persze ott ilyen nem fordulhat elo....a dehogy.

Ezt ki és mikor írta? Mert szerintem a felhőben arról írtunk, hogy nem "pet", hanem "cattle" van: ha egyet köhint, leöljük, teljesen újat felhúzunk, mentésből vagy replikából megy rá az adat és service disruption nélkül. Ebbe belefér, hogy egy-egy VM időnként megdöglik az adataival együtt, tudjuk, így tervezzük a rendszert. A szopó az, ha nem így tervezed, mint a mellékelt ábra szerint.

https://iotguru.cloud

Ez egy klasszik on-prem egyszerveres gép analógiája volt, csak épp nem on-prem fizikai vason, hanem a GCP-ben VM-ben? Mert akkor nincs itt semmi látnivaló, tipikus legrosszabb felhőhasználat volt csak, aminek tényleg nem kellett volna felhő.

Monitoring nem szólt, hogy nullásak a snapshot-ok? Mentéskor nem derült ki, hogy nullás különbözeteket ment?

A felhő ott tud segíteni, hogy pillanatok alatt, kis pénzért van több kiszolgálód/szolgáltatásod, akár több DC-ben, akár több földrészen. Ezzel a saját SLA-t tudod növelni, megfelelő redundancia saját kezű kialakításával (ez a felhőtől nem lesz automatikusan meg). Az on-prem ellenben bazi drága induláskor, ha ugyan így több DC-ben, több földrészen akarod megvalósítani az SLA növelés érdekében. Emiatt felhőben nagyobb esély van jobb rendszert csinálni, mert nem kell eladni a menedzsereknek egy végtelen $ berzházással járó projektet, aki az on-prem rendszerre azt mondja, elég arra egy gép is, nem számít egy hét kiesés, mert máshogy neki túl drága (persze addig nem számít a kiesés, amíg be nem következik és nem éli át a dolgot...).

Ráadásul ha rendesen megy felhőbe, akkor nem VM-et visz, hanem weboldalt egy bérelt web "konténerre", adatbázist egy bérelt adatbázis szolgáltatásra, stb. Így még a teljesítmény tervezéssel sem kell olyan sokat vesződni, mert majd automatikusan vagy kézzel skálázható egyszerűen, aktuális igény alapján.

De az ellen egyik sem véd, hogy a rendszer nem nagy rendelkezésre állásra van tervezve, nincs rendes mentés, nincs ellenőrizve a mentés, nincs DR terv még fejben sem, satöbbi.

Persze tudom, hogy tudod mindezt, csak azért foglaltam össze, hogy a többiek, akik a jövőben beírnák, hogy a felhő nem jobb, összefoglalva megtalálják, ami itt, a témával foglalkozó topikokban elhangzott ezzel kapcsolatban.

Gyakran járok ki mentéseket és DR forgatókönyveket auditálni, tesztelni.

Ha tudnátok, milyen "nagy neveknél" jönnek az infrások rögtön azzal, hogy "mi mindent mentünk VM szinten egy központi mentőrendszerben, nincs itt semmi látnivaló", nem hinnétek el.

Egy teljesen tipikus beszélgetés:

- Oké, kérlek állítsátok vissza az éles adatbázist egy teszt szerverre, tegnap éjféli PIT-tel. 
- Ohh, reggel 5-kor futnak a mentések..
- És a PIT recovery-t hogyan oldjátok meg? 
- ???
- Oké, legyen akkor a reggel 5 órai állapot.
...
- Ohh, ez nem indul be. Azt mondja valami kell neki a recovery-hez. Te tudod mi az az archív log?
- Persze, a DB delták. Mivel online mentésből állunk vissza, kellenek ezek is. Add oda neki amit kér, visszapörgeti abból. Hivatalosan ezeket is backupból kellene visszaállítani. Megvannak ugye?
- Ja, ezeket mi simán törölni szoktuk, mert mindig feltelíti a diszkeket.
- És akkor hol vannak az adatbázismentéseitek?
- Hát a teljes, futó VM-et mentjük. Azt hittük, ez így elég...