Újra megy a Prohardver!

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

A kényszerű leállás után már újra elérhető a Prohardver.hu. A leállással és visszatéréssel kapcsolatos tudnivalókról egy weboldalt hoztak létre, ami elérhető itt.

( marcabru | 2025. 07. 30., sze – 08:26 )

Szerkesztve: 2025. 07. 30., sze – 08:33

> A most visszakerült régi processzort azért cseréltük februárban, mert nem bírta már a terhelést -- sajnos a polcon pihenve sem erősödött meg.

A felho, a devops, az IaaC meg a "cattle" elv koraban ilyeneket olvasni nosztalgikus erzessel tolt el. Visszaemlekszem arra, amikor valami uzletben nyomorogtunk a baratommal a pentium elott, kalapalva az ugyviteli szoftver ala rakott postgresql vagy mysql szervert a konzolon keresztul , valamikor az oskorban

Es tenyleg a polcon pihentetessel probaltak a problemat gyogyitani???

Linkelt oldalon:

"Az eset folyományaként sürgősen cseréljük a teljes szerver infrastruktúránkat, 25 év után végleg lemondva a saját vas üzemeltetéséről."

ami nekem kb annyit jelent hogy:

"Összetákoltuk hogy menjen abból amink van, közben tervezzük hogy lehetne a legokosabban megoldani felhőzéssel hogy legközelebb ne szopjuk be"

... és amíg az üzlet is rábólint röpke 6-12 hónap alatt, addig imádkozunk, hogy a régi vas ne fossa össze magát szintén. (Viszont ha nem teszi, akkor azért kell imádkozni, hogy az üzleti oldal ne kényelmesedjen bele a helyzetbe, mondván: "megy ez a régi vassal is") 😀

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Nem ismerem a hátteret, nem is érdekel. Ettől még nem tévedtem; a fogalom létezik, csak akkor egy ember fejében. Eldöntöd, hogy akarsz-e normális vasat alá, vagy sem. Eldöntöd, hogy akarsz-e normális backupot vagy sem.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Elmagyarázom: a Veeam egy enterprise termékek mentésére szolgáló enterprise termék. Értelemszerűen enterprise integrációs lehetőségekkel, enterprise rendszergazdáknak - akik pl. nem feltétlenül értenek a mentendő rendszer lelkivilágához.

Hol látsz te itt enterprise use case-t?

Ide egy faék egyszerű restic kell remote s3 buckettel. Letitkosítod oszt' jóvan.
A restic egyébként egy rettentő hatékony és atombiztos backup megoldás.
Csak így alapból nem enterprise ready.

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

For comparison: azelőtt synology hyperbackup-pal mentettem. Mivel ugyanazt és ugyanoda mentettem elég korrekt az összehasonlítás: a restic nagyjából fele költséggel oldja meg ugyanazt (sokkal kevesebb remote write és read, valamivel kevesebb storage igény)

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

Hat ez az. Ha trendi, cloud meg devops akarnak lenni, akkor meg lehet oldani automatizalva, ugy, hogy felalljon az uj infra 2 ora alatt nullarol, terraform, meg hasonlok, de sima regimodi eszkozokkel is elerheto, hogy ha 2 nap alatt is (beleszamolva a balatonrol valo hazautat), de off site backupbol, berelt potszerverrol felalljon egy mentes. Legrosszabb esetben felhozni egy maximum 1 honapos offline mentest read onlyban, majd nehany nap mulva a diff mentesekbol egy friss valtozat R/W modban. 

a regimodi eszkozok meg: egy DR terv, lehetoleg offline elmentve, milyen szkripteket, parancsokat kell futtatni, hol kell atallitani a networkot egy masik szerverre. es persze egyszer kiprobalni, hogy megy-e.

hogy ha 2 nap alatt is (beleszamolva a balatonrol valo hazautat), de off site backupbol, berelt potszerverrol felalljon egy mentes

Még annyi sem kell hozzá. A Rackforest felhúzza az alap LAMP stack-et, mire feljövök a Balatonról (de minek jönnék fel, amikor ezt onnan is megcsinálom egy lángos meg egy sör mellett, ha nagyon akarom), HTTPS, certificate, szükséges PHP modulokkal, URL rewite / egyéb szar beállításokkal, minden szarral. Odakészíti az MySQL account infót, meg a phpinfo(); kimenetet, hogy minden működik. Na, onnantól kezdve 3-4 parancs az indulás. 

Ennyi az indulás. Kurva bonyolult. Ezzel már fut az oldal, utána meg lehet bohóckodni a fényezéssel. Lófasz nem kell ide, nem hogy felhő meg cluster ... erre aztán csont felesleges. Egy szerver, egy szar fut rajta. Még Dockerrel sem érdemes bonyolítani.

Ez a misztifikálása a dolgoknak, ami itt ment egy héten keresztül, minimum megmosolyogtató, rosszabb esetben sírvaröhögős. 

Szerk: ja plusz nem tákolt dzsunkát kell venni/bérelni, hanem brand szervert. Nem véletlen dolgoznak azok megtervezésén mérnökök. 

trey @ gépház

Persze, hogy nem misztikus, azért tűnt csak annak, mert ezzel a misztifikálással próbáltak hazugságot elfedni. Amit nagyon elítélek. Nem az a baj, hogy valaki hibázik, hanem hogy gerinctelen és nem ismeri be, nem vállalja fel a felelősséget. Az lett volna a tiszta, hogy nyíltan bemondják, hogy amatőrök voltak, eltolták, ransomware vitt mindent, nem számoltak ezzel a forgatókönyvvel, a jövőben viszont átadják az üzemeltetést hozzáértőknek, és onnan már nem kell ilyentől tartani.

“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.”

Ransomware-nek ellentmond h megmaradtak egész friss töredékek is. 

Szerintem egy ransomware-t bevallani jóval kevésbé ciki mint a rendes mentés hiányát és az féllábas cpu cserét.
Btw rendes mentés esetén a ransomware se tud ekkora kárt tenni.

Nulla esélyét látom annak hogy 3 hónapig kussolt a ransomware.

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

Az üzemeltetés átadás lehet kimerül abban, hogy a rackforenstnél bérelnek szervert, mert nem bíznak a régi vasban. De a szoftveres, backupos, működésbeli dolgok kapcsán majd kiderül. Írtak olyat, hogy az új rendszerben sem lesz redundancia...  de hátha már máshová is átmásolják a backupot...

Az üzemeltetés átadás lehet kimerül abban, hogy a rackforenstnél bérelnek szervert, mert nem bíznak a régi vasban. De a szoftveres, backupos, működésbeli dolgok kapcsán majd kiderül.

A Rackforest-nél a vas mellé kérhetsz/kapsz rendszergazdai üzemeltetést is. Ők megoldják az offsite backup-ot: 

  • webroot
    • fájlok
  • DB
    • napi teljes SQL dump
    • app-aware mentés
      • például MySQL/MariaDB/Percona esetén XtraBackup

Probléma esetén az offsite tárhelyet egy sshfs-sel felmountolod és ott a napi fájlszintű mentés, a full napi dump(ok) 2 hétre visszamenőleg (gondolom a retention idő megbeszélés/pénz kérdése, de gyakorlatilag csak a büdzsé a korlátja), plusz az XtraBackup mentések

Ez nem rocket science. Ebből visszalapátolni egy oldalt, nem kéne napokba telnie, főleg úgy, hogy:

Rackforest esetén, ha beszarik az egy szem bérelt fizikai szerver,

  • ha a HW (alaplap, CPU, memória stb.) szart be, de az adatok egyébként megvannak hiba nélkül
    • kiveszik a 2 darab, RAID1-ben levő SSD-t, beteszik egy PONT ugyanolyan fizikai vasba és megy tovább a műsor
  • ha az adatok mentek a levesbe
    • felhúzzák az új rendszert image-ből vagy akármilyen megoldással
      • sshfs mount, bla, bla, bla

Egy esetben lehet szopásod: 

  • ha mentéseid korrumpálódtak több mint 2 hétre visszamenőlegesen
    • ezt azért egy online oldal esetén elég nehéz elképzelni, de ebben az esetben az otthoni kis PC-den napi, heti, havi egyszer durranjon el egy script, ami GFS rendszerben leszopkodja a gépedre is a cuccost.

Tekinolódzsíá! Tekinolódzsíá! 

Mindezt felhő, cluster, bűvészmutatványok nélkül! KISS-elven (mégiscsak UNIX Portál voltunk), egyszerű parancssori eszközökkel, ami minden alap Linux disztró része.

trey @ gépház

A minimum valoban ez lett volna. A $CURRENT_YEAR-ben elfogadott meg az, hogy ne egy szal bare metal vason fusson az egesz lapcsalad. Ez ilyen trukkos matekpelda:

Van mondjuk 4 darab VM-ed, ebbol hasraesik 1 darab (illetve az alatta levo gep, teljesen mindegy miert), marad 3. Maximalis terhelesnel kicsit lassabban reagal a forum, de valoszinuleg a latogatok meg eszre sem veszik. Ha megdoglik 2 - mielott az ujak felallnanak - mar lehet, hogy eszre lehet venni, de igazabol nincs gond. Mig ha eleve 1 darab van, es 0 marad, nem megy tovabb a rendszer. Persze megfelelo SW is kell hozza, de nagyjabol ennyi.

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

a veeam is kb onnan indult talán, hogy a vmware volt olyan kedves, hogy kecseg módra kivezette a megvett csomagból a backup funkciót és helyette 3rd party vacak kell a proprietary szarjukhoz. Van ahol a különböző plecsnikhez muszáj megvenniük a plecsnis céges pénznyelő szolgáltatást. Ahol nem kell, ott meg ghettoVCB. 

Hát, ha mondjuk a filléres VMware-Veeam vagy HyperV-Veeam páros helyett teljesen ingyenes Proxmox van a saját backup megoldásával, akkor máris ott vagy megbízhatóságban, hatékonyságban, teljesítményban. Annyi az ára pénz helyett, hogy meg kell tanulni telepíteni, konfigurálni, üzemeltetni, és az app-aware mentésekhez az előkészítést kézzel meg kell oldani, nincs benne készen. A mentések integritását automatikusan ellenőrzi, és mivel van API, ezért a visszatöltési tesztek teljes körűen automatizálhatóak.

Vagy ott a Bacula, aminek a community verziójába az évek során egy csomó enterprise modul bekerült, app-aware mentések, vm-ek, konténerek, stb. mentéssel egyetemben.

Vagy egy sima, Plus sorozatos Synology NAS (150 ezerért már van ilyen, nem milliókra kell gondolni), amihez ingyen jár az Active Backup for Business szoftverük, ami akár azt is megcsinálja, hogy fizikai vagy virtuális gépet ment (blokk szinten, inkrementálisan, tömörítve, deduplikálva...) és időnként visszatölti virtuális gépbe, lefuttatja, működik-e. És erről jelentést küld...

Az a baj az IT-ben, hogy aki beleszokik a drága (de egyébként kiváltható, másnál is létező) szoftverekbe, az onnantól elképzelhetetlennek tartja ugyan olyan jó, de ingyenes/FOSS szoftverek használatát, és ezt ráfogja arra, hogy az úgyse lenne oda jó ezért meg azért, meg azok amúgy sem megbízhatóak mert csak.

Szóval az igazán jó (műszakilag jó) mentés tényleg nem pénz, hanem elhatározás kérése mára.

Annyi hátrányod lesz, hogy bizonyos compliance tesztekhez ez nem lesz elég, mert nincs valamilyen plecsnijük (amit azért találtak ki, hogy számon lehessen kérni, és így sok pénzért lehessen adni). De ilyen jellemzően multiknál van, annál kisebb cégeknél legtöbbször nem igénylik, csak azt, hogy jól működjön.

Annyi az ára pénz helyett, hogy meg kell tanulni telepíteni, konfigurálni, üzemeltetni, és az app-aware mentésekhez az előkészítést kézzel meg kell oldani, nincs benne készen.

Tehát az ára az idő és az opportunity cost. Avagy nincs ingyen az ingyenes szoftver. És ez az ár esetenként nagyon magas is lehet.

Pontosan. A kész rendszer nem lesz ingyen. A hozzá felhasznált szoftverek lehetnek ingyen.

A "beruházó" dönt, hogy mindent pénzért vesz (hardvert és tudást hozzá) és az Ő részéről csak az elhatározás kell meg a döntés, vagy nincs ennyi pénze, így munkát és időt kell bele tennie, amivel a pénzköltés egy részét megúszhatja.

A gond akkor jön elő a legtöbbször, amikor a pénzt sem akarják beletenni, meg a munkát-időt sem. Szerintem itt is ez az eset áll fent. Ezt nehezíti a Dunning-Kruger hatás, amikor azzal sincsenek tisztában, hogy amit csináltak, az nem jó, mert nincs annyi tudásuk, hogy ezt felismerjék.

Az jutott még eszembe ezzel kapcsolatban, hogy a bölcsesség az a tapasztalat, amit akkor szerzel meg, amikor már épp szükséged lenne rá...

Ha one man show akkor a monolittal jár jobban (ahogy most van). Ebben a méretben (ez már nem kicsi) pedig a "saját vas"sal jár jobban. 
A saját vasat persze nem kell feltétlenül otthon tartani, se nem kell megvenni, lehet bérelni is, hostingban.

A normális mentés az más, azt meg kell csinálni.
Igazából én egy DR-Plan-t írnék. Akár elkezdeném valami AI-generált template-ből aztán kitöltögetni szépen a lokális tartalommal.

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

Igen, a saját vasat egyszer* kell kifizetni, (kivéve, amikor meghibásoidik közben ;) viszont ha megfelelőt akarsz, akkor időtállót kell venned, szal az a jobb, ha fölé lősz árban. Biztosan nem kell senkinek beutatni, hogy az enterprise szintű szerverek és azok alkatrészei mennyibe kerülnek. Ennek üzemeltetési költsége, ha felveszel rá egy kollégát, folyamatos költség. Akkor is, ha nem veszed fel, csak contractort fizetsz rá. A normális (!) backup megvalósítása és annak fenntartása, szintén költség. Ez az amit ProHardverék kivettek a képletből, és még ki tudja mit... stb-stb.

Szerintem ennek fényében hasonlítsuk össze, hogy egy megvett hw mennyi idő alatt hozza vissza a VPS töredékáron fizetett havi díját, ahol a terhek jelentős részét leveszik a válladról.

*Szerk.: Egyszer tízévente, ha nem hibásodik közben semmi meg? Ez alatt visszahozza az árát a VPS-hez képest? Érdekes lenne egy ilyen pénzügyi összeasonlítás.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Sajat vasat egyszer kell megvenni??

"Egyszer tízévente" -> csak mondtam egy példát, mielőtt ebbe is beleköt valaki.

Es hol fogod a netre kotni, otthon a router mellett?

"stb-stb." -> vagyis még ezer aspektusa van a történetnek. Remélem nem gond, hogy nem bontottam ki mind. Egyesek szerint így is szófosás volt.

It is our choices that define us.
Thinkpad X1 Carbon | Arch linux

Igy van. Mindent rendundansra csinalni benne kurva draga, ido es melo. Ha valami beszarik, te ugrasz ki az agybol cserelni: penz, ido, munka. Havi dija is van mert a szervertermet berelni kell.

Hol van az pariban azzal, hogy 3 kattintassal inditasz egy LAMP stack-et es scp-zed fel ra a szarodat otthonrol?

Ez nagyon keményen almát körtével összehasonlítás. Ha mondjuk a Hetznernél megnézed hogy 50-60 EUR-ért mit kapsz bare metal-ban illetve VPS-ben akkor rögtön látod h bare metal sokkal "több vasat kapsz".
VPS-nél meg persze megkapod az egykattintásos mentést (+20%-ért, naná nem ingyen) 

Nekem van egy olyan teóriám hogy ilyen "nem nagyon kicsi" cuccokat hozzáértő kezekben már érdemes bare metal-ra tenni.

A nagyon kicsit nem érdemes bare metalra tenni meg a nagyon nagyot se.

IMHO kell legyen nem is egy olyan VPS szolgáltató akinek amúgy nem saját infrája van hanem valakitől bérli a bare metal-t, erre teszi rá a VPS-ét és adja tovább mint értéknövelt szolgáltatást. Teljesen valid üzleti modell ez (bár valszeg nem könnyű kenyér)

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

Persze nyilvan ez egy nagyon durva becsles, de ezert a penzert mar egy nagyon combos VPS-t kapsz. Nyilvan a PH-re nem eleg a 240 GB SSD tehat kell meg storage-ot venned, de ha feljebb mesz arban +20-30 ezer forintot / ho meg akkor is alacsonyabb fenntartasi koltsegre jossz ki mint bare metallal.

Snapshot mentes meg kell a francnak. Ha tul draga, Trey szepen leirta feljebb, hogyan kell szakadt papucsban, linuxos tool-okkal (tar, gzip, scp) megcsinalni nulla forintert egy mentest ami mar boven elegendo a hasonlo fiaskok elkerulesere. Barmi tortenik, 24 oran belul visszaalsz a legutobbi valid allapotra egy uj VM-en, aztan turhatod a regit, hogy mi a fasz tortent.

Pont hogy az ilyen workload-okra a legjobbak a nem fancy VPS szolgaltatok.

VPS-nél meg persze megkapod az egykattintásos mentést (+20%-ért, naná nem ingyen) 

Ami aztan vagy mukodik, vagy nem, mivel az automata backup ezeken a helyeken csak annyit jelent, hogy napi egyszer tolnak egy snapshotot. Ha veletlenul inkonzisztens lesz, akkor meg szivattyu.

Itt van egy árban a VPS a saját vassal, parancsolj:

Rackforest Hosting Rack szekrényben - Victor Hugo - 1U rack szekrény hely - 26.000 HUF nettó

Rackforest Linux SSD VPS 48 - 10 XEON Gold vCore - 48 GB RAM -220 GB SSD - 25.300 HUF nettó

Magyarán csak és kizárólag a saját szerver havi hostingdíjjából megvan egy viszonylag combos VPS-ed.

Emelett a bekerülési költséged 0 Ft volt, amortizációd 0 Ft, a tartalék alkatrészekre szintén 0 Ft-ot költöttél, a mérnökórákat meg fel sem hozom, mert saját vasra azért illdomos összerakni egy alap hardware monitorozást (legalább raid status, ha softraid vagy csak 1 diszked van akkor minimum smart monitorozás, valamilyen riasztási rendszer integrálása, legalább 3 havonta 1 teszt).

Szóval nem hogy egy árban van, még olcsóbb is, mint ahogy fentebb állították.

Ez a komplett megoldas PH-ra:

10 XEON Gold vCore - 48 GB RAM -220 GB SSD

Storage keves ala, azt a csuszkat meg arrebb kell huzni. Ennyi. Ezen fut Ubuntu Server + LAMP stack + a PHP-ban irt oldalak. Mentesre egy db. bash script cron-bol futtatva ejjel 2-kor. Kesz.

Bare metalt majd osszeallitod ahogy akarod, koltsegben mar a helyberles pillanataban folotte vagy a VPS-nek.

Teljesitmeny reportot majd kiszopkodod a kedvenc AI-odbol. Ha a PH hajlando lenne kozolni a jelenlegi hardware-et, akkor biztosra, de amugy latatlanban is megmondom neked, hogy ez a konfig rohogve elviszi az osszes oldalukat.

Ne haragudj, de 25+ ev szakmai tapasztalattal fel tucat, ilyen faek egyszeru PHP oldal teljesitmenyigenyet illik tudni megbecsulni.

A haromszavas kotoszkodesek helyett (minden info-t mi turtunk ki helyetted) tovabbra is varjuk az erveket, hogy miert necces erre a workloadra a 10 magos Xeon es a 48 GB ram.

Konkrétan milyen onfot turtal ki, h mennyibe van az RF-nel a vos es a hosting, erre vagy nagyra?

 

NezUk akkor a kpnkretumokat:

 

https://www.facebook.com/100063569581946/posts/pfbid02b3uWHMq4qJiQU4mTM…

===

Sziasztok!

Lassan konkrétumokat is tudunk írni, ahogy egyre jobban látjuk, hogy mi mindenünk van, és mi mindenünk nincs. Tudjuk, hogy rengetegen szerettetek volna minél hamarabb minél többet tudni, de amíg nem sikerült stabilizálni a vasat és a környezetet, illetve nem tudtuk elég alaposan felmérni a fájlokat, adatokat, mi magunk sem tudtuk pontosan – a saját, megalapozatlan tippjeinket pedig nem szerettük volna megírni, azok közül számos nem is jött volna be. 

Maga a szerverpara természetesen több szempontból is nagyon rossz pillanatban ért minket: a rendszergazda egy országos esemény komplett technikai backendjén dolgozott látástól-mikulásig már napok óta és még napokig. Jómagam (Parci) öt kamaszodó gyereket táboroztattam a Balatonon épp, ahonnan egyszerűen nem tudtam eljönni, minden akaratom ellenére sem. Az időközben a segítségünkre siető, a mentésbe bekapcsolódó hazai adatbázis guruk is mind valahol nyaraltak. Az első nap a géphez való fizikai eljutás is problémába ütközött.

Amíg a sérült rendszer nem volt stabil (nem az általános stabilitást értve ezalatt, hanem hogy egyáltalán most használható legyen), semmit sem tudtunk csinálni és minden létező erőforrást ide allokáltunk. Igen, lehetett volna, szerettünk volna többet kommunikálni, de se kapacitásunk nem volt egy “live feedhez”, se érdemi infónk nem volt, hogy mit mondhatunk, a baj akkora volt, hogy a jogos kíváncsiság/aggodalom kielégítését azokra a napokra jobb híján elengedtük.

Mivel párszor elhangzott, hogy hülyének nézzük a felhasználókat, nevetségesek vagyunk, egyáltalán nem értünk hozzá és miért nem vesszük végre tudomásul, hogy v-é-g-e, egyetlen alkalommal kitérnék erre a vonalra is (többet és kommentben nem fogunk):

- nincs kapacitásunk kommentharcolni, nem is lesz, hiába látjuk az olykor egész extrém teóriákat, vagy az olykor nettó rosszindulatot, kárörömöt. Nem azért hallgatunk, mert beleegyezünk, hanem azért, mert nincs erre allokálható energiánk. A mondanivalónk úgy is azoknak szól, akik szeretnék még használni a szolgáltatást.

- amint van megosztanivaló infónk, megosztjuk, beleértve a számunkra nem hízelgő dolgokat is. Az elmúlt 25 évben eddig is így tettünk, ellentétben a vérvádakkal.

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

- egyáltalán nem mentegetendő a felelősségünk, de az elmúlt napokban kis túlzással a fél IT szakma, az elmúlt 25 év sok-sok kollégája, versenytársa, ismerőse hívott minket, kivétel nélkül mind azért, hogy elmondják, hogy pontosan ismerik így vagy úgy a helyzetet saját tapasztalatból, őszinte részvétük, minden IT-üzemeltető rémálmaként ellenségüknek sem kívánják, és hogy hogyan tudnak segíteni. Súlyos technikai gondok nálunk több nagyságrenddel nagyobb cégeknél is voltak, vannak és lesznek.

- noha többek fejében egy nagy cég vagyunk, igazából egy mára nagy rendszert üzemeltető kis cég vagyunk, limitált erőforrásokkal. Sima közgazdasági matek, hogy azt a fajta robusztusságot nem tudjuk nyújtani, mint a nagy cégek. Ez nem azt jelenti, hogy most a mentésben nem segítenek a legjobb szakemberek (önkéntes alapon, amiért végtelenül hálásak vagyunk és köszönjük ezúton is), de azt igen, hogy az alap infrastruktúránk lehetett volna jobb, akár sokkal jobb.

- nem szeretnénk tudomásul venni, hogy végünk. Lehet, hogy végünk lesz, lehet, hogy ezért lesz végünk, számos okból lehet végünk, az élet már csak ilyen, hogy minden véges… de, amíg itt vagyunk, és amíg emberek örülnének annak, ha visszakapnák kedvelt felületeiket, tisztelettel küzdeni szeretnénk és fogunk is.

- nem gondoljuk, hogy nevetségesek volnánk, azt sokkal inkább, hogy a mai internet toxikussága egészen biztosan nem tartozik az erényei közé.

- megértjük az informálás iránti igényt, igyekszünk is neki megfelelni, és ahogy megyünk előre az időben, egyre több infóval tudunk majd jelentkezni. Valóságsót, live streamet nem tudunk csinálni.

És akkor az érdemi infók, amit jelenleg tudunk/gondolunk:

- ami elromolhat, az most tényleg mind elromlott 🙁 (egy példa: recovery közben is újraindult a vas)

- az adatbázis szerver olyan mértékig korrumpálódott (a schema is, könyvtárstruktúra is, data+wal fájlok is, minden), hogy nem tudjuk maradéktalanul helyreállítani, biztosan lesz adatvesztés.

- 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 az offline mentés az új címlap és a Gamepod + IT café Prohardverbe olvadása ELŐTTI közvetlen állapot: 2025.04.30.

- az adatbázisból rengeteg fragmentum fájl rendelkezésre áll, de ezekből az adatok csak részlegesen nyerhetők vissza, sok adat nem, és egy-egy tábla ilyen részleges helyreállítása is napok (hetek). Ezek vizsgálata már legalább két napja tart, rengeteg módon lehetne adatot visszanyerni egy sérült adatbázisból, ehhez rengeteg segítséget is kapunk és sikerül is egyre inkább végigjárni minden lehetőséget (sajnos: lassan minden opcióból kifogyunk).

- talán a legnagyobb eséllyel a hozzászólások és a privát üzenetek menthetők.

- a site-okat el fogjuk tudni indítani, maga a kód teljesen sértetlen, a működést maradéktalanul vissza tudjuk állítani, de sok olyan bejegyzés, komment, hirdetés, teszt, hír hiányozni fog az elmúlt 3 hónapból, ami korábban ott volt.

- a rangok, értékelések a legrosszabb esetben is az április végi állapotot fogják tükrözni, de jó eséllyel ebben tudunk előrelépni.

- a teljes technikai hátteret átalakítjuk. A közvetlen tűzoltás és az adathiány miatt jelentkező hibák kezelése még le fogja kötni minden időnk egy darabig, addig gyakori belassulások várhatók.

- a downgrade-elt szerverünk most látszólag stabil, de nem bízunk már benne, sürgősen el szeretnénk hagyni, ugyanakkor szeretnénk mihamarabb indulni is. Keressük az áthidaló megoldást, aminek szintén lehetnek kockázatai (de ezek legalább tervezettebbek).

Menetrend: lépcsős újraindítás tűnik reálisnak, és hétfőig mindenképp szeretnénk elindítani “valamit” az oldal 3 fő pilléréből:

1. Fórum (közös)
2. Tartalom (Prohardver, Mobilarena, Logout),
3. Apróhirdetések (Hardverapró).

A tervezett sorrend is ez, de ez csak terv, mert nagymértékben függ attól, hogy melyik rész milyen gyorsan állítható helyre, hol van a legnagyobb, de időben beleférő esély adatot menteni (és jellemző momentum, hogy eredetileg a tartalmat akartuk előrevenni és egy órája is még azt gondoltuk, hogy azzal kezdünk). Mindenesetre túl sokat nem tudunk egyik pillér adatmentésére sem várni, hiába tudnánk még némi adatok kinyerni a szerveren maradt fájl-masszából, ha az két hétig tart. Onnantól pedig, hogy újraindítottuk az adott táblákat és kerülnek bele új adatok, a régieket visszahelyezni inkább csak elméleti, mint valódi opció a sok ilyen-olyan reláció miatt.

Egy-egy élesítés után pár nappal a következőt is szeretnénk, ennyi idő van plusz adatokat menteni.

Ezen a ponton ezer forgatókönyv forog a fejünkben, de egy biztos: az elmúlt 25 év legnagyobb technikai kihívása ez számunkra, ami a méreténél fogva kihívás az egész cégnek, az egész lapcsaládnak. Sajnos a rosszabb forgatókönyvek sem zárhatók ki teljesen, de egyrészt mindent megteszünk, hogy felálljunk ebből, másrészt sokat gondolkodunk rajta, hogy ha így lesz, milyen kisfőnix emelkedik majd ki a romokból.

Szeretnénk megköszönni a sok bátorítást, emailt, telefont, lelkesítő kommentet, ezek komoly szerepet játszottak abban, hogy mostanra, bármilyen nagy is a baj, a pánik, döbbenet és elkeseredés helyett a jelen lehetőségeinkbe szorítva is előre nézzünk és megoldani akarjunk!

Végszóként pedig álljon itt egy régi kollégánk tegnapi üzenete: “Számomra az életem egyik legjobb szakaszát (is) jelentette a PH, és azóta is része. Teljesen biztos vagyok benne, hogy ha valaki, akkor ti ki tudtok ebből jönni, és bármi is megy a levesbe, helyébe új, értékes tartalom kerül.”

====

https://rackforest.com/szolgaltatasok/vps/premiumamdvps/#premium-amd-li…

 

10 vCore-ig lehet skalazni nalunk VPS-t. Szoval mégcsak a közelébe sem tudsz menni annak, VPS-sel, amit hasznalnak. Legalábbis az RF-nél.

 

Ami viszont tény, h a szóban forgó CPU egy Epyc 7662 64/128 core-ral (itt írta vki, utána nem jártam):

https://www.amd.com/en/support/downloads/drivers.html/processors/epyc/e…

Hetznernel már van 48 vCore, igaz, ha teccik, ha nem, 192GB rammal 360 usd/ho, az haverok kozott is tobb., mint 4k egy evben. Valójában még ezt is körbe röhögina bare metal.

Varom a linkeket a versenykepes VPS-ekkel.

Az eddigiek alapján (tehát nem latatlanban, de meg mindig csak feltetelezve), az en 25 eves tapasztalatom azt mondatja, h bullshitelsz a legures terbe, okosnak akarsz tunni es replikazod, amit korabban olvastal vhol. A gyakorlatban aztan ebbol lesznek a felmegoldasok, magyarazkodasok meg az "azt hittem" kezdetu mentegetozesek.

Nalad biztos nem igy lenne. Egy karriert futhatnal be:

https://youtu.be/YkRWhmkxtj8?si=3tz9fvFBFMV84fv0

Ha te 25 ev tapasztalattal elhiszed hogy egy magyar forum meg par magyar weboldal ala 64 magos adatbazisszerver kell, meg hogy az egy jo megoldas hogy 1 db DB szerveren kell futni az egesznek, akkor nincs tobb kerdesem.

Az egesz PH sztori tokeletes esetleirasa annak hogy miert nem erdemes sajat vassal szenvedni igy 2025 tajekan.

Ez az elkepeszto szerencsetlenkedes sajat hw-rel, hibas cpu-val, recovery kozben random rebootolo geppel, hogy nem fernek hozza 1 napig a vashoz mert a joskapista nyaralni van, stb. mikozben egy 100 millios eves bevetelu ceg mulik rajta.

Persze aki nem ert hozza meg nem tud infrastrukturat tervezni annak csak annyi latszik hogy huuuu TB-os adatbazis meg 64 magos enterprise proci, azta! Amit latom te is fenyesen bekajaltal :)

Aki meg ert hozza az ennyibol levagja hogy annyira elkepesztoen amatorok vannak a hatterben hogy meg azt se tudjak mi az a terheleselosztott rendszer, ami egy ilyen helyen alapkovetelmeny lenne.

( ggallo | 2025. 07. 30., sze – 10:01 )

Szerkesztve: 2025. 07. 30., sze – 10:03

Egy hét alatt nem tudtak pár százezerért venni egy használt, de erősebb szerver hardvert? A régit kell tovább használni, ahol valójában csak egy tipp, hogy a CPU volt hibás?

Meg egyébként nem napi-heti szinten, de rendszeresen ránézek a PH-ra, olykor van érdekes cikkük. Na, február előtt, a CPU csere előtt nem volt ilyen tetűlassú. Szóval nem a régi CPU gyengébb ennyivel...

Ráadásul nem azt kellene vizsgálni, hogy saját hardveren fusson-e, hanem azt, hol csúszott el ennyire az üzemeltetés. Mert ha ugyanaz fogja csinálni ugyanúgy, de bérelt cuccon (akár fizikai, akár virtuális a bérlemény), pont ugyan így meg fogják szívni.

ezt érzem én is ez az egész CPU hiba, meg hogy a régit tették vissza kurva gyanús. 

rendszeresen olvastam az oldalt , február előtt nem volt ilyen lassú. most kb olyan mintha marika néni asztali gépén indult volna el. még azt tudom elképzelni hogy most MINDENKI IS egyszerre akar mindent csinálni az oldalon. de bejelentkezés nélkül a főoldal 10mp ... ?

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

( khiraly | 2025. 07. 30., sze – 10:28 )

Szerkesztve: 2025. 07. 30., sze – 10:39

Ez a visszatérési oldal viszont normális. Kár, hogy magáról a haváriáról hallgatnak.

 

Ez meg "érdekes":

PROHARDVER!
Sándor Csali Ez egy eredeti árán 2-3M ft-os, 64 magos, már kifutott enterprise szerverprocesszor. Nem lehet "1 óra alatt elintézni". Garanciális, de abban sem vagyok biztos, hogy van még cseredarab belőle, meg őszintén szólva be sem mernénk tenni egy másik ugyanilyet ezen a ponton. 🙁 (és mindegy is, mert az egész infrastruktúrát cseréljük)

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

nem.

Ebben én nem látom, hogy mi volt a probléma, mit csináltak, mi volt a szoftver setup. Tudod a szakmai rész hiányzik csak.

User oldalról viszont hibátlan. De azt írtam is.

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

Ez egy eredeti árán 2-3M ft-os, 64 magos, már kifutott enterprise szerverprocesszor.

Soknak hangzik, de sajnos nem az. Ez egy 7k USD processor újkori MSRP áron.

Nézzük meg a 2025-ben megjelent Xeon 6-os processzorokat (7529-es foglalat):

Xeon 6980P, msrp: 12460 USD

Xeon 6979: 11025 USD

Igazából nem is találok 7k USD alatt 2025-ben megjelent Xeon 64 magos processzort:(

6760P ami talán közelít, 64 mag, 7803USD.

 

Ettől függetlenül, lehet hogy nehézkes a beszerzése. De ha kiírták volna, hogy X foglalatú processzor kell, akkor lehet akadt volna hamarabb is.

 

Egyébként mostmár tudjuk, hogy mindösszesen 1 számítógép volt, és abban is 1 processzor.

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 közben megjelen, csak a korábbi közléseket összegyűjtő írás kommentszekciójában elárulták, hogy a problémás proci egy Epyc 7662 volt (2020as széria). Ahogy nézem használtan kb 200-400 ezer közt szerezhető be, attól függően honnan és mennyire kreatívan sikerül.

Az is következtethető belőle, hogy valsz nem fogják közzétenni a pontos prolémát, biztonsági okokból  link
Max, ha majd átköltöztek a rendszerükről máshová, de gondolom a szoftveres körítésről túl sok részletet akkor sem publikáknak így.
 

Pedig nem a publikum az ő biztonsági veszélyforrásuk, hanem a saját maguk inkompetenciája.

Nálam még mindig nem jó a PH. Linkekre kattintást nem fogadja el, csak a jobb egérgombos kattintást. Próbáltam tracking protection-t, uBlock Origin-t, Tridactyl addonokat kikapcsolni, sütiket törölni, stb., bugos marad az oldal FF-ban.

Nekem ez a régi proci lassú is elég user errornak tűnik. A PH nem lett nagyob, mint 10-20 éve volt, és 10-20 éve sem hajtotta 64 magos proci. Itt az van, hogy a saját tákolású rendszerük erősen optimalizálatlan, és nem használja ki rendesen a hardvert.

“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.”

Attól, hogy a "trollszűrő" elrejtené a hozzászólásaidat, te a többi felhasználó posztjait még látnád. Már ha automata, tanított szűrésre gondoltál. Ha saját feketelistát szeretnél, azt bármikor megcsinálhatod magadnak, ráadásul bejelentkezés nélkül is működik.

:)

Igen, az adatbázis. De ez egy napra meg egy másodperce eső forgalom, lekérések száma, stb. szerintem még csökkent is, ahogy megy ki a divatból a fórumozás. Az teljesen mindegy, hogy az épp lekért aktualitásokat mekkora adatbázisból ássák elő. Így szerintem a hardverigény nem nőhetett jelentősen, és 10-20 éve még a szerverprocik is sokkal gyengébbek voltak, így ha akkor eflutott, most se kéne neki 64 mag meg 128 giga RAM, meg hogy ezalatt lassú legyen.

“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.”

Hát, ha a PHP kód azt kéri a DB-től, hogy "SELECT * FROM CIKKEK", és amit kap mondjuk 5600 sort, abból a futó kód választja ki azt a 5 cikket, amit megjelenít az user felé, akkor akár lassulhatott is 20 év alatt... :-D

Csak azért írom ezt, mert az SQL-re épülő szoftverek 80%-a így indul pályafutása elején, és vagy továbblépnek, vagy így maradnak örökre. A PH jelenlegi esete után nem vagyok biztos benne, hogy az ő kódjuk a "továbblépett" kategóriába esik...

Igen, egy kicsivel több idő lekérni, de pl. egy dupla akkora adatbázisból nem dupla annyi idő. Ne felejtsd, hogy a modern SQL adatbázisok optimalizálnak, meg indexelnek, hozzáférést meggyorsítva, meg a nagy adatbázisból mindig csak a legújabb felhasználók, témák, cikkek pörögnek, azt meg a rendszer a cache-ben tartja, így egy nagyobb adatbázisból a lekérdezés nem lesz feltétlen szignifikánsan nagyobb. Erre akartam célozni.

“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.”

Na, közben kiderült, hogy az oldal bugos FF-ban, de gyanítom ez is valami webdeves gányolás miatt, mert csak a Prohardver érintett. Brave-ben jó viszont. Ott meg is próbáltam belépni a legutolsó fiókommal, erre közli a rendszer, miután a jelszócsere után be tudtam lépni, hogy kitiltottak, de indoklás nincs, nem is voltam a fórumon már több éve. Okot nem írnak, mert adatvédelem, védik az adataimat saját magamtól. Hazug ’cik ezek. Még azt is behazudták, hogy a kitiltás okát megírtak az email-címemre, hát nem, egy fiókról van szó, amiből nem töröltem a régi leveleket, szóval ellenőrizhetően itt is hazugságon kaptam őket.

“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.”

A kérdésed értelmetlen. A hiba állítólagos oka a konkrét cépéu példány hibája. Az, hogy nem árulják el a pontos hw és szoftver rendszer tartalmát és felépítését, az a biztonsági ok. 

Az egyébként valamennyire logikusan hangzik, hogy a lehetséges sebezhetőségek miatt nem teszik közzé a pontos infrastruktúrát. Azért szakmai szemmel nézve, jelen helyzetben, picit inkább úgy hangzik, mintha ciki lenne bemutatni. De ez csak az én szubjektív meglátásom.

Közben látom úgy írják, hogy új proci volt az 5 éves.  Meg bérvas nem felhő lehet a terv vagy még nincs leütve. Szóval nem kell semmit tényként kezelni, mert minden ködös...

Leszámítva azt az esetet, hogy remote root exploit van a processzorban, miben járul hozzá a biztonsághoz, hogy elhallgatják a teljes hardverkonfigjukat és azt is, hogy pontosan mi történt? Minden, a biztonság mellett a transzparenciára valamit is adó szervezet közzéteszi az ilyen tanulságokat.

Nem tudom, mivel nem ismert a rendszerük :D  Ez ilyen paradoxon, hogy a rendszerük ismerete nélkül nem tudhatom, hogy bullshitelnek vagy tényleg van bármi olyan tényező, ami miatt kockázatnövelő lenne ismerni. 

Konkrét verziószámokban lehet veszély, de az meg valsz nem kell a leíráshoz. Azért annyira nagy csoda dolgaik/szoftvereik sem lehetnek, amit kb ne találtak volna ki a 25 éves működés során csordogáló információkból. Ha valaki meg támadni akarja őket, akkor úgyis kipróbálja a valószínű szoftverek ismert sebezhetőségeit, hátha nem friss van nekik. Szóval nem tudom. 

Lehet majd valami cikket azért írnak belőle valamilyen formában. Remélhetőleg nem csak manager mesét, hanem olyat, amiből tanulni is lehet.

Konkrét verziószámokban lehet veszély, de az meg valsz nem kell a leíráshoz.

Hát épp ezaz. Az "XXYY típusú CPU hibája miatt keletkezett bithibáknak köszönhetően tömegével sérültek meg a rekordok az adatbázisban" című mondatot nem muszáj úgy folytatni, hogy ", ami egy PostgreSQL 17.2 volt". :P De ettől még le lehet írni részletesen, hogy mi történt, meg hogy vették észre az első hibákat, meg hogy sikerült végül visszahozni.

( prion | 2025. 07. 30., sze – 15:44 )

Király! Nyilván van valamilyen tudásuk, tapasztalataik, erőforrásaik és csinálják, amit tudnak. Szerintem, ami kívülről legtöbb hozzátehető, ha előfizet náluk az ember és ha stabilnak érzik magukat lehet jobb döntéseket tudnak hozni.

Éves 170 milliós forgalom mellett (aminek a jelentős része reklám bevétel egy kiadványnál, ergo nincs jelentős anyagköltség kiadás oldalon hozzá) 10 évente teljen már ki egy rendes rendszer, normális üzemeltetéssel.

De ha mégsem telik ki objektívan valamiért (nem látok bele és nincs is közöm a részletesebb pénzügyeikhez), akkor szerintem érdemes más biznisz után nézni, mert akkor ez nem rentábilis, ha a saját normális működését sem tudja kitermelni.

Egy ilyen hetes kiesés után akkor sem fizetnék elő, ha eddig szerettem volna, még akkor sem, ha ilyen csak sok évente van egyszer. Ugyanis szerintem eléggé hiteltelen lesz egy olyan IT portál, ami a saját IT-ját ennyire rosszul csinálja.

Oh, my bad. Valahol olvastam a 170 milliót a PH-val kapcsolatban, és elhittem, hogy annyi, nem kerestem ki a cégtárból. Sorry.

Nem vagyok egy menedzser típus, de szerintem én évi 80 milliós forgalomból is ki tudnák szorítani 10 évente egy IT cserét. Ezen állításom arra építem, hogy nem keresek évi 80 milliót se, de itthonra a hobbi szerverem (ami igazi szerver, nem desktop PC-t léptettem elő) 3-4 évente lecserélem, van felügyelt UPS tápellátása, és van onsite meg offsite mentésem egyaránt mindenről is. A mentések pedig rendszeresen ellenőrzöttek, hogy használhatóak-e.

Szóval szerintem egy bármilyen cégben is megoldható ugyan ez.

( Fisher v | 2025. 07. 30., sze – 18:08 )

Lassú? Tegyünk alá még vasat.

Az ilyet a legjobb felhőbe költöztetni. /s

Ha jól értem a leírásokat, itt már az is 1-2-3 napot gyorsított volna, ha nem saját vasuk van, hanem sima bérelt a valamelyik magyar, külföldi vagy akármi helyről, mert akkor nincs az, hogy nem tudunk elmenni a táborból fizikailag kicserélni a cuccot stb dolog, amivel elment az elején sok idő.

Web, Domain, Tárhely

( Elbandi v | 2025. 07. 30., sze – 18:50 )

amennyi szagero van itt, mar 100 ph szintu portalnak kene lennie!!! aztan megis alig van egy tucat! \o/

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Az, hogy az itt jelen lévők tudnának-e egy jó rendszert csinálni egy ilyen portál alá, és az, hogy az itt jelen lévők szeretnének-e IT hírportált maguknak, szerintem két tök különböző dolog.

A PH esetében az látszik, hogy ott fordítva van a HUP közönségéáhez képest. Ők szeretnének maguknak egy IT hírportált, de nem tudnak alá rendes rendszert csinálni. Ezért is mondják, hogy cipőt a cipőboltból. Az újságíró hobbizzon IT-vel, írjon róla, értsem az újságíráshoz és az IT-hez olyan szinten, hogy hiteles legyen. A cikkei alá pedig csináltasson rendszert ahhoz értővel, aki cikket írni valószínű nem tudok olyan jót, de rendszert tervezni és csinálni tud...

Szerintem meg nem volt olyan, hogy egy külsős csak drágán csinálta volna, azért nem lett.

Inkább az lehetett, hogy szerintük, a saját ismereteik alapján teljesen jó volt a rendszer tervezési és kivitelezési meg üzemeltetési szinten, így fel sem merült, hogy külsőst megbízzanak bármivel ezzel kapcsolatban. Aztán most kiderült, hogy rosszul tudták, nem volt jó.

( palmaci | 2025. 07. 31., cs – 14:03 )

Hát megmondom öszintén inkább beszoptak egy randsomware-t. Azért eléggé nehezen tudom, elhinni, hogy egy valóban server vas nem szúrta ki, hogy a CPU hibázik. Főleg úgy hibázik, hogy adatokat ront el és soha nincs exception? És mind ez úgy, hogy Február óta crash-elget a proci suttyomban. Meg az is sántit, hogy az adatbázis engine se futott rá az elmúlt hónapokban egy hibás adatra., és nem sírta tele a naplót. Majd hónapok szemetelése között egyszer csak crash-el az egész FS. Az FS crash-nel meg az a furcsa, hogy azert egy mondern FS-t ami journaled azért eléggé nehez úgy megütni, hogy total szétessen rajta minden adat. Mondjuk a dir struktúra szét is esik azért a fileokat össze lehet lapátolni. Még akkor is ha az online backupk amit elvileg szintén megsérültek. Na ezt így már nagyon tudom szakmai oldalról megérteni.   Főleg hogyan sérül meg file szinten valami, CPU hiba miatt amihez mondjuk 1 hete nem is nyúlt a rendszer. Nekem nagyon sok kérdőjel van a story-ban. Persze az IT okkult tudomány, de ennyire azért nem. 

ugyanezt mondom az eleje óta. ez nem CPU hiba volt... nagyobb összegbe fogadnék is rá. nem , mielőtt megint valaki belémköt, nem változik semmi ha tudom ,vagy nem ,egyszerűen szakmai kiváncsiság, hogy igazam volt-e.

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

Megmondom őszintén, hogy szégyellem magam, hogy ez az egyértelmű forgatókönyv eddig eszembe sem jutott. Pedig annyira adja magát, a ransomware egy csapásra megmagyaráz mindent, miért ment a levesbe az adatbázis, és egyszerre a mentés is, meg miért csak későn vették észre. Pont azért, mert a modern ransomware-ek szép alattomosan, kis CPU terhelésen titkosítanak, hogy semmi észre ne vegye, ki ne szúrja, és mikor végeztek, akkor törlik hirtelen az eredeti állományokat, és ott bukik ki fénysebességgel, hogy megette a fene az egészet. Ezt nem merték beismerni, hogy ilyennek ők áldozatul esnek, így kitalálták ezt a szelektíven, csak az adatbázist szétnyíró rejtélyes CPU hibát, amilyet még senki nem pipált rajuk kívül a világtörténelemben. Persze, hogy nem ilyen okkult az IT, hogy rejtélyes voodoo CPU hibázások legyenek, csak mi kerestünk értelmet az értelmetlen hazudozások közepette. Ebben is az lesz, hogy a legegyszerűbb, legközönségesebb, legkézenfekvőbb magyarázat mögött lesz az igazság.

“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.”

Apr 30-Jul 22-ig minden elveszett, elvileg Jul 22-29 van 1 heti adatuk van reszlegesen meg. Pont abbol az idoszakbol amikor velhetoen a CPU egyre jobban es tobbet hibazott. Mivel mar elindulni se volt hajlando a vegen. Nem tudom milyen DB engine lehet, de erdekes, hogy a 04.30 es 07.22 kozott minden a tablaban tarolt adat kiesett, de a 07.22-29 kozott megmaradt. Az osszes tablara ertendoen. Valamint, egy backup-bol se sikerult semmit se visszanyerni. Foleg azert egy valamire valo DB csinal tranzakcios logot.

Vagy egy atom villanas elotti windows serveren futott FAT32-es file rendszerrel es egy 3-as mysql myisam tablakkal.  Mert akkor valoban egy CPU hiba oda tud csapni a FAT-nak amit a memoriaban tarol a win folytom es azt irogatja vissza a diskre. Vagy valami oldschool linux Reiserfs-sel, az meg tudott szep adatveszetesek csinalni hw hiba eseten. Ilyen helyzetbol tenyleg 0 esely barmit is osszekalapani.  De ne mar, hogy ilyen osdi cuccon futatnak egy ekkora lapcsaladot. 

" Jul 22-29 van 1 heti adatuk van reszlegesen meg" 
nem. Április és jul 22 közti van meg részlegesen. 22én állt le.

A csepegtetett infókból következtetve külön tábla tartalmazhatja a topicokat és azok metaadatait és másik táblában lehetnek a kommentek.
Ezt abból következtettem, hogy az április 30 utáni nyitott topicokat nem tudták helyreállítani. Valsz az a tábla teljesen megsemmisült a helyi fájlrendszerben lévő fájlokban/mentésekben. Így nem tudják milyen nevű topic volt és milyen témacsoporthoz tartozott, milyen beállításai voltak. Az alattuk lévő kommentek egy része persze attól meglehet, csak lehet nem akartak küzdeni vele, hogy megpróbálják egyenként visszakeresni a topicokat, hogy milyen témájúak lehettek a kommentekből visszakövetkeztetve. A legtöbb elveszeett topic valsz a hírekhez/cikkekhez tartozhatott, az azoktól független topicokat sokszor lezárnak és átirányítanak már létező gyűjtő topicokba, hogy ne legyenek duplikált témák.

A kommentes táblákat tartalmazó részekből lehet többet vissza tudtak hozni és topic id alapján betölteni a már korábban létező topicokhoz kötve. Lehet sérült fájlokból kivagdosott töredékekből importálták vissza. 

Az a szornyu -szvsz- hogy nem hittem volna, hogy egy ekkora oldalt ennyire amator mondon uzemeltetnek. Tegyuk fel nincs ransomware, volt hw hiba, de nincs egy masik gepen replica a db-rol? Nem kell clusterbe kotve lenni, de mar a firebird is tudott shadow copy-t. Az ossze mai modern Db tudja, meg a free verziok is. De a jelekszerint az online backup-ot nem hogy ugyanzon a disk-en hanem meg ugyanazon a volumen-en, ugyan azon az FS-en tarolod. Azert ehhez mar nagyon batornak kell lenni. Na ne, hogy mar legalabb egy USB-s 4Tb kulso drive-ra nem futotta? Oke nincs penz, de tudod oroszrulettezel az adatokkal akkor leglabb heti egyszer nem csinalsz egy offline backup-ot? Oka lehet a ransomeware titkolasanak, hogy azt biza be kell jelenteni a NAIH fele, akkor hatosagilag kimennek, es mivel nem par user szemelyes adatarol van szo, jo sokaig allna a rendszer. Amig vizsgalodnak. Viszont ez ami kirajzolodik, hogy honapig hibazgato CPU-t 3 honap alatt nem tunik fel senkinek, hogy kozben szetforgacsolja az FS-s, es ezzel a DB strukturakat, ez sem tunik fel 3 honapig. Nulla mentes stb stb. Ezek utan hogy bizz meg bennuk? Mert inkabb lenne vallalhato egy ransomware beszopasa, mint ez a nulla szakmaisagot tukrozo mukodes. 

Sajnos a DB-t lassan mérgező ransomware még egy jól felépített offsite backup mellett is rizikó, egy ideje gondolkozom azon, hogy hogyan lehetne kitesztelni egy olyat, ami mondjuk naponta csak 30 cikket titkosít le, fut hónapokig, mikorra végez, addigra meg kipörögnek a offsite backup-ok. Egy DB dump diff-elés alapú megoldáson gondolkodom, majd foglalkozom vele ha nem lesz más dolgom. Ha van erre valami kész megoldás, ne kíméljen, aki tudja. 

Mert ez ellen pl. egy DB replikáció, annak mentése és több helyre elosztása stb. sem teljesen jó megoldás. 

trey @ gépház

Ez nyilván nagyon függ attól, hogy mi van az adatbázisban, de pl ilyen portáloknál szerintem nulladik körben már ha csak azt a kontentet nézed, ami kb 1-1-ben megváltozott, az már bőven ki tud szűrni mindenféle gyanús szart. Illetve ha a file, vagy vmi olyasmi, nem tudja róla érdemben megmondani, hogy mi ez (vagy megváltozik), az is.

Ezek egyébként imho fájl alapúakra is működnek jó eséllyel.

Meg hát lehet mindenféle anomáliákat nézni, eleve, ha régit piszkálnak, az gyanús, ha hirtelen többet, mint szoktak, akkor főleg, drasztikus méret változás szintén.

De nyilván kicsit végiggondolva lehet ezt szofisztikálni erősen...

zcat backup_20250715.sql.gz | grep -i 'INSERT INTO node ' | md5sum
zcat backup_20250801.sql.gz | grep -i 'INSERT INTO node ' | md5sum

leveszek az aktuálisból mondjuk 200-at (mert ennyi új node születhetett egy hét alatt), de erre is jöhet fals pozitív, mert mondjuk valamelyik user megszerkeszt egy 15 éves blogbejegyzését ... szóval azért nem olyan egyszerű. 

trey @ gépház

Ó hogyne, anomália detekcióban fals pozitívok vannak, annyira kell őket leszorítani, hogy az operátor még ne hagyja figyelmen kívül. Az nyilván esetfüggő, hogy a 15 éves post szerkesztése elég ritka esemény-e ahhoz, hogy rá lehessen nézni. (Esetleg ilyenkor ránézetni a felhasználóval, bár kétes eredményt várok ettől).

De egyébként pont ezért mondtam, hogy kéne nézni pl változás méretet, vagy, ha az adattípus elmászik, mert azok azért valószínűbb indikátorai a bajnak, mint pusztán az, hogy termékenyebb hét volt. De ehhez nyilván kicsit többet kell dolgozni, mint egy grep. És hát az is biztos, hogy ezt általánosan kitalálni akármire is még kevésbé egyszerű, konkrét cucc konkrét adatszerkezetének ismeretében azért könnyebb. Bár lehet, valami jó heurisztika megfogná, annyira baszott lassan nem terjedhet egy ilyen szar...

Hát, egy ponton kell nézegetni embernek is, meg biztos lehet ezt AInak is adni, de ide lehet, hogy túllövés. Valójában ha van arra akarat, hogy felhúzza a dumpot valahova (azért ez ma már nem egy nagy etwas), ott már nyugodtan módszeresen végig lehet ellenőrizni, aztán lesz olyan, ahol az odabaszott hányást egyértelműen fel lehet ismerni imho. Mármint gondolom at the end of the day itt a vége az lesz, hogy random post helyén valami hexadecimális szemét lakik majd mondjuk...

Valójában ha van arra akarat, hogy felhúzza a dumpot valahova

Ez már nálam 15 éve is meg volt csinálva, voltak minimális tesztek is rajta. Egy nem volt még nagyon 15 éve: fejlett kriptovírus. Ahol van főállású rendszergazda, meg üzemeltető, ott lehet van idő és energia ilyesmire. HUP-nál nincs. 

trey @ gépház

Ja, hogy ha konkrétan a hupról beszélünk, side projectként... Hát, végülis grepelhetsz, vagy akár be lehet nyomni az érdekes részét egy sqliteba, aztán abból lehet túrni egy kicsit (persze greppelni is lehet, de text dumpbból, hát fene tudja, kissé törékenynek hangzik). A gyanúsakat meg végül is akár be is lehet küldeni valamelyik ai apinak egy jó curllal, hogy szerinte mizu, azt szeva. A semminél több, cserébe várhatóan kevés energiát igényel tőled.

ez csak ötlet.

idönként be kell szurni az adatbázisba "csalirekordokat", amik amugy sehol nem jelennek meg, viszont egyszerűen le lehet kérdezni őket valami spec alapján ( pl : néhány mező olyan kombinációt tartalmaz, ami normál esetben nem lehetséges. mondjuk dátum : 2511.12.23 ) és időnként ezeknek a tartalmát checkelni.

HUP te Zsiga !

Van egy most futó projektem, ahol hasonlón töröm a fejem jó ideje a sok egyéb feladat mellett. Csak kevés időm volt kidolgozni a megoldást. Működnie kellene Pgsql, Oracle, Mariadb környezetben is.
Ha találsz erre jó megoldást, akkor arról írhatnál egy cikket. Engem is érdekelne, hogy ezt hogyan lehetne jól megvalósítani.

Szerintem adat szintű konzisztenciát és sérülés (titkosítás mentességet) csak adat szinten tárolt checksum-mal tudsz ellenőrizni. Pl. minden cikknek kell legyen egy checksum, amit időnként végig kell pörgetni, stimmel-e.
Vagy kapásból titkosítva tárolod az adatot, és ha nem tudod értelmesen visszaolvasni (visszafejteni), akkor nem a Te programod módosította, baj van...

Adatbázis fájl/mentés változást nézve szerintem bazi nehéz kiszűrni, hogy legitim vagy nem legitim a változás benne...

Ha a DB hozzáférést szerzi meg a támadó (mondjuk konfig állományból vagy titkosítatlan komm. elolvasásából), akkor kiszűrhető checksum/titkosítás módszerrel az illetéktelen beavatkozás a DB tartalomba.

Ha az eredeti szoftver forrásához fér hozzá, akkor teljesen mindegy a DB tárolási módszer, mert hozzáfér a kulcsokhoz, checksum módszerhez, bármihez, amit tud érvényesíteni. De az eredeti kód változását meg lehet monitorozni külső eszközzel, szóval azt is észre kellene venni, hogy egy támadó átírta a forrást...

Így csinálják jobb tárolók is: adat mellett ellenőrző összeget is tárol, kiolvasáskor és időnként a háttérben ellenőriz.

Célzott támadás ellen nyilván vannak korlátai, mert ha a támadó hosszú távra tervez és ismeri a logikát, akkor az ellenőrző összeget is frissíteni fogja, de a hardver és egyéb hibák ellen jó védelmet nyújthat.

Ha akkora méretű az adatbázis, hogy még lehet értelmes időn belül SQL dumppal menteni, akkor a deduplikációs mentések statisztikái is elég jól mutatják a változások trendjét. Nagyobb adatbázisnál pedig az archív logok méretének alakulása hasonló információt ad.

Még igen méretes adatbázisnál is vettünk észre - pusztán ebből az értékből - programozási hibákat illetve alkalmazotti visszaéléseket (például: adatbázis méretbeli növekedése megfelelt a trendnek, de az archív logok / DB delták mérete aránytalanul magas volt egy konkrét időponttól kezdve. Kiderült, hogy olyan UPDATE-k futottak, amiknek nem kellett volna...)

Alkalmazásoldalról (nálunk általában SAP) pedig még részletesebb infók vannak egy tranzakcióanalízisben vagy audit fileban, ha nyomozni kell.

De egyszerűbb adatbázisokból is meglepően sok adat lehúzható, amelyek szintén trendként értelmezendőek; önmagában egy-egy érték, pillanatfelvételként túl sokat nem mond. Pl. MySQL-ben:

SHOW GLOBAL STATUS WHERE variable_name IN ('com_update','com_insert','com_delete');

Vagy táblánként lebontva még beszédesebb, ezt már bele lehet tenni akár egy monitoring forrásba is, és vizuálisan is azonnal látható lesz a trendtől való eltérés:

SELECT 
  table_schema, 
  table_name, 
  rows_updated, 
  rows_inserted, 
  rows_deleted 
FROM sys.schema_table_statistics 
WHERE table_schema NOT IN ('mysql','performance_schema','information_schema')
  AND GREATEST(rows_updated, rows_inserted, rows_deleted) > 0
ORDER BY rows_updated DESC;

+1

Content-aware validacio kell a backupra. Mondjuk a HUP eseteben, ha tortenik egy komment-szerkesztes ket backup kozott, akkor kell lennie megfelelo adatnak a history-ban is (gondolom van ilyen a Drupalban). Ha nincs, akkor at kell dobni manual review-ra.

Ezt a vegtelensegig lehet finomitani, de kesz megoldas nem hiszem, hogy van ra.

Gondolom nem dolgoztál még elég helyen. 😀

Minél nagyobb egy cég (létszám, bevétel, hírnév), annál nagyobb a kupleráj.
Audit se garancia mindenre.
A csillogó külső mellett a belső sokszor csak tákolt, rohad, esik-kel. Mondjuk ez nem csak cégek IT-jára igaz.

Nem kell ehhez kis cégnek lenni. Mint írtam a PH-nál nagyobb, nevesebb cégeknél is történnek hasonló esetek.

Annyira siralmas, sőt, felháborító látni, amikor láthatóan nem költenek IT-ra. Se hardverre, se szoftverre, se szakemberekre. Aki meg vészmadárkodik ("Baj lesz ebből, csinálni kellene ezt-azt...."), őt kiutálják vagy lelép magától. Nem mindenki (én se) vagyok hajlandó a nevem adni egy kuplerájhoz.

Én nem mondanám hogy egyértelmű korreláció lenne.
Vannak nagyobb cégek ahol egész jó rend van. 

A vezetőségen múlik nagyon sok minden:
- milyen embereket vesznek fel
- hallgatnak-e a jelzésekre
- költenek-e a "technical debt" csökkentésére

Nagyon más a szitu azoknál a cégeknél ahol "az IT-n múlik minden" vs "az üzleten múlik minden, az IT kiszolgál".

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

Az a gond, hogy az itthoni (magyar tulajdonú) vállalatok java részénél at IT csak ilyen megtűrt, "sajnos kikerülhetetlen" dolog, és csak akkor költenek rá, mikor letérdel valami. Ez az én tapasztalatom, cégmérettől majdnem függetlenül (KKV szintig mozgok, felette nem). Persze mikor baj van, akkor az egyetlen, aki nem felelős benne az az, aki a döntéseket hozta az IT-vel kapcsolatban. Mindenről valaki más tehet.

Van-e olyan cég (bármilyen tevékenységgel), akinek a napi működését nem befolyásolja jelentősen egy IT-ben bekövetkezett leállásos hiba? Max. egy pár régi, kisebb termelő cég, ahol a gyártás nem IT vezérlet, hanem kézzel megy minden és termelnek számítógép nélkül is. Mindenki másnál komoly gondot okoz az IT kiesése. Ennek ellenére sem az IT-ből élő, sem az IT-t "csak" használó cégek nem gondolkodnak kellően felelősen az IT-ről.

( bennyh | 2025. 08. 02., szo – 11:35 )

Most már el kellene kezdeni foglalkozni a hup-pal is, mert valamiért meg-megbicsaklik (lapváltás, bejelentkezés, hsz beküldés 5-10mp tököléssel), miközben a PH-n meg folyik az élet.

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

Kérem a Fiátot..

Nagyon ritkán tapasztalatok ilyet, akkor is arra jutnak, hogy valami scarper fut az oldalon, vagy valami ragequit-es takarítja a szemetét scriptből. Ezeket kitiltják és akkor nyugalom van. 

az is kéne a bugreport-ba, hogy honnan jelenetkezik neked: itthonról|külföldről, melyik szolgáltatóval stb. 

trey @ gépház

A Rackforestnél szoktak tiltani? :)

Itt egy lista (nagy részén valami megtákolt wordpress lehet, ami próbál másokat tákolnini, de van közte szkenner is :))

109.122.217.82|100|RackForest|Data Center/Web Hosting/Transit|prismafinanceclaim.net|RackForest|Hungary|Dunavarsany, Pest County|20||2025-06-24T22:48:10+00:00|2025-06-25T22:36:31+00:00|1753920006||
193.201.189.116|100|Rackforest Zrt.|Data Center/Web Hosting/Transit|w4.itit.hu|Rackforest Zrt.|Hungary|Budapest, Budapest|||||1754204401||
185.80.49.12|100|RackForest|Data Center/Web Hosting/Transit|raul.netpeople.hu|RackForest|Hungary|Budapest, Budapest|406||2022-10-12T06:56:11+00:00|2025-07-24T14:05:20+00:00|1754204401||
185.80.49.155|100|RackForest|Data Center/Web Hosting/Transit|mail.netpeople.hu|RackForest|Hungary|Budapest, Budapest|107||2025-07-03T14:33:24+00:00|2025-07-25T13:00:20+00:00|1754204401||
193.201.185.171|100|RackForest|Data Center/Web Hosting/Transit|carlos.netpeople.hu|RackForest|Hungary|Budapest, Budapest|289||2025-06-23T19:00:00+00:00|2025-07-23T14:05:10+00:00|1754204401||
193.201.185.228|100|RackForest|Data Center/Web Hosting/Transit|isp3.mconet.hu|RackForest|Hungary|Budapest, Budapest|151||2025-07-02T17:31:42+00:00|2025-07-26T21:30:10+00:00|1754204401||
79.139.57.49|91|RackForest|Data Center/Web Hosting/Transit|vps01.komodoart.hu|RackForest|Hungary|Budapest, Budapest|863||2021-05-24T02:41:53+00:00|2025-07-08T20:47:47+00:00|1754206301||
193.201.185.38|100|RackForest|Data Center/Web Hosting/Transit||RackForest|Hungary|Budapest, Budapest|326||2025-06-18T16:18:15+00:00|2025-07-19T18:08:39+00:00|1754209279||
193.39.14.8|100|RackForest|Data Center/Web Hosting/Transit|cpanel33.rackforest.com|RackForest|Hungary|Budapest, Budapest|57||2025-07-24T06:25:52+00:00|2025-07-28T14:16:09+00:00|1754215200||

Az abuseipdb.com-on vagy a threatbook-on vagy kinek mi a kedvencén le lehet csekkolni.

( x-daemon | 2025. 08. 04., h – 10:27 )

a hupon jo, hogy ha valaki valaszolt egy hozzaszolasra, akkor mar nem modosithato. annyi kellene meg, hogy mondjuk 1 napon tul mar azt se lehessen modositani, amire nincs valasz. a nyitot szinten ne lehessen modositani 1 nap utan, csak hozzaszolasban lehessen updatelni, mondjuk az OP megjelolhetne a hozzaszolasat, hogy az a nyito update-je, akar felulre is kerulhetne. innestol a regi forumok es hozzaszolasok nem modosulhatnanak, ennek megfeleloen lehetne ellenorizni, hogy adatbazisban megis modosult-e.

neked aztan fura humorod van...

ha 1 napnal regebbi a rekord, akkor az nem modosulhat normal modon, vagyis hozzafernek a DB-hez, vagy a programban van valami res, vagy doglodik a raid vezerlo, vagy barmi. hogy valtozott-e az 1 napnal regebbi rekord, azt a visszatoltott es 1 nappal korabban visszatoltott DB osszehasonlitasabol fogod latni, nem marad rejtve eloled. ez arra is jo, amit fent irtal, hogy ha mondjuk 30 hozzaszolasonkent modositjak a regi rekordokat, azt nehez eszrevenni.

neked aztan fura humorod van...

( influencer | 2025. 08. 04., h – 23:15 )

Lehet én vagyok fenyőfa, de nekem akkor sem áll össze ez a történet. Összeesküvés-elméleteket sem akarok gyártani, így abban bízom, hogy lesz majd egyszer egy számomra hihetőbb magyarázat erre az egészre.

Ne legyél ilyen szigorú magadhoz, ez senkinek nem áll össze. Ellentmondásosak az infók. Szarkenegetésnek, terelésnek, amit a PH csinált. Mondom, itt nem is az volt a baj, hogy szakmailag amatőrök, meg hibáztak, és hogy 10 napig állt, hanem a szövegelés, meg a dezinformációs magyarázatok, amiket megeresztettek mellé. Egyébként az egyik hivatalos PH YouTube videóban az egyik szerkesztő (wombat) elismerte, hogy rosszul kommunikáltak, elnézést kér érte. Az legalább egy korrekt dolog volt, csak nem volt kellőképp kiemelve.

Sose fogjuk megtudni, hogy igazából mi történt. A két legvalószínűbb, a ransomware támadás, vagy a procival inkompatibilis mértékben túlhajtott memória miatt összedőlt nekik a ZFS pool vagy a szoftver RAID. Vagy-vagy. Plusz nem volt rendes backup. Ennyi.

Én is sajnálom, mert ha korrekten megmondják az okát, lehet más is tanulhatott volna belőle szakmailag, elrettentő példának szolgálva. Így sose tudjuk meg. El kell fogadni, hogy csak összeesküvés-elméletek maradnak.

“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.”

Azért ha a processzor + memória inkompatibilitás okozta a hibát, akkor különösen vicces a hardver szakértőktől, hogy ez történik velük. Mert hát ebben jók, hogy nagyon értenek a hardverekhez?

Arra a kérdésre, hogy mikor álltak vissza legutóbb a teljesen adatmentésből új hardveren a katasztrófa előtt, erre sem válaszolnak szívesen. Meg még sok kérdésre nem válaszoltak.

Azt sem olvastam sehol, hogy konkrétan, név szerint ki üzemeltette, ki volt a főnöke, kinek mi volt a felelőssége, vállalása, stb. Gondolom a későbbiekben aki itt ezekkel dolgozott, nem fogja kidomborítani, hogy az ő hibája és felelőssége volt ez az egész, hanem az fog ott szerepelni, hogy neki NEM az volt a munkája, azt más végezte. (Ja, elfelejtettem, hogy a hardverek a hibásak, az nem az én hibám, ha soha nem próbáljuk ki az adatmentéseket!)

Tippre nem lesz Magyarországon egyetlen ember sem, aki bele meri írni az önéletrajzába, hogy ő üzemeltette 2025. augusztusig a Prohardver lapcsaládot. Vajon miért?

"hardver szakértőktől" -> újságíróktól. Nem lekicsinylésből írom, hanem ez gyakori tévedés a kommenteknél. A prohardver nem hardver szaktanácsadó, üzemletető cég, hanem újság. Régebben lehet volt, aki házon belül vitte az üzemeltetést, de már rájöttek, hogy nincsenek erre errőforrásaik és úgy tűnik átadják hivatásosoknak ezt a részét.
https://hup.hu/comment/3208977#comment-3208977

Egyébként épp néztem egyik fiókot náluk aki régebben legalábbis szoftveres oldalt vitt - a fiók alapján valsz váltott más céghez korábban. Másik kollegájuk pedig nemrég elhunyt, bár nem tudom ő mely területet vitt. Sajnos minden erodálódik idővel.

Nem is inkompatibilitás, hanem különböző procik különböznek, hogy milyen RAM frekit és időzítéseket tudnak kihajtani. Szerintem az lehetett, hogy eleinte volt nekik egy kisebb Epyc procijuk, kevesebb magos, de magasabb órajeles, ami szépen tudta a RAM-okat magas frekin, alacsonyabb időzítéseken hajtani. Ezt lecserélték egy 64 magosra, ami önmagában hiába erősebb proci, csak több szálon gyorsabb, egy szálon sokszor gyengébb is, alacsonyabb frekit tud, ezzel együtt a RAM vezérlője se tud ugyanannyira kihajtani egy gyorsabbra állított RAM-ot, emiatt a memória elkezdhet hibázni, az meg taccsra vágta a ZFS poolt. Természetesen ez nem proci gond, hanem továbbra is user error, hogy a memóriát nem állítják be stabilra.

Ja, szégyen, nem illik önéletrajzba, az tuti. Nem is értem, hogy szervert ki a rák üzemeltet túlhajtott RAM-okon. Sokan nem tudják, de az XMP meg egyéb profilok is hivatalosan tuningnak minősülnek. Szabad őket használni, de tesztelni kell azért, nem garantálható, hogy mert a RAM tudja a sokezer MT-t gyárilag, hogy azt a proci is szeretni fogja.

“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.”

Én még nem, nekem mindig minden stabil volt az Xmp beállítással, bármelyikkel. Régebben még az Xmp beállításnál erősebbeket is elvitt atom stabilan. Mostanában már nem szórakozok ezzel, elég ha az Xmp megy. Főként Kingston komolyabb időzítésű memóriákat vettem, amikre ez igazak, élettartam garanciával. Mindegyik jó még, amit használok.