Kérdezz, jár erre pár guru. Hamarabb kapsz választ, ha precízen leírod mi a baj (oprendszer, sw verzió, hibaüzenetek, egyéb) - de kérünk, egy kérdést ne írj bele több topicba, kérdezés előtt keress vissza, hátha már volt a problémád.
Ja, és amennyiben warez windowsod lenne, ez nem az a hely ahol segítene bárki. És kodekpakkot, soha, sehova sem teszünk fel.
Mi műszaki problémákat szoktunk megoldani és nem óvodás társadalmi marhaságokat. Verd pofán, mószerold be a főnöknél, mittomén. Főleg ha ez kell a munkához és azt sem biztos, hogy sejtem miből tudja, hogy el szeretnéd érni a gépet meg miért fáj.
Céges munkahelyi asztali gépre rátelepitettem az Anydesk programot hogy távolról rátudjak nézni munkaidőben a gépre,másik műszakba lévő egyik kolléga kihúzta az internet kábelt hogy ne tudjam használni, 6napja vettem bele usb wfi jel erősítőt (titokban) hogy legyen a gépen internet ( internet kábel kihúzásával müködőtt ti) ma reggelre megint nem lehet ránézni,nincs internet! Hogy tudok még ennél is titokba rátenni az asztali gépre internetet??? Asztali gépház belsejébe rákötni netet hogy lehet??
Áll ez az eset akkor is, ha az a sok apró fájl, egy ZFS/BTRFS vagy régebbi SQUASHFS-rendszerű tárolón/archívumban volt?? Egy tömörített fájlrendszer esetén, nem egy streamként lehetne visszaírni backupból, azt a sok adatot?? (Az üres helyek is 0-ákkal kitöltve.) Szemben, az NTFS-el. (lásd: Linux telepítők/LiveCD, sok ezer-fájl egy SQUASHFS-archívumban van, mégis gyorsan betölthetőek az adatok, akár egy CD-ről is.) Tudom, a Linux-os FS-ek,totál mások, mint Windóz alatt.
Vagy tényleg ennyiere aprózott minden? Egy XML-t/LOG-fájlt, meddig hagyunk, írás alatt? 1nap, órák, percek?
Ami még érdekes adalék, egy Reddit-en posztoló kiszúrta, hogy a domainjük, lassan 1 hónap múlva lejár. Ha, mégis a legrosszabb eshetőség esik be az ajtón, akkor nem biztos a visszatérés. Az elkövetkező 2-5 nap döntő lesz ebben.
Ha az a pár TB jellemzően pl. xml vagy más, kis méretű (pár kilobyte-os) fájlokból áll, akkor kell neki idő mert az olyan kis fájlokat sosem a max. szekvenciális írási sebesség közelében másolják a meghajtók, hanem nagyságrendekkel lassabban (még az SSD-k is).
"Gyanús előjelek nem voltak, hogy a proci rosszalkodik?"
Ezel szerint nem, de Face csoportjukban is jönnek a töketlen hülyék akik az infra ismerete nélkül osztják az eszet, oda azért írtam 1-2 trükkösebb hibát, itt meg ugye valami lehet a mikrokóddal ment félre. Nagyvasnál előfordul. hogy szól, de ott is láttunk csodákat, oszt ha a filerendszer kócolódik, akkor ott ahogy látom vége a dalnak és max. építik az új oldalt. Érdekes, hogy nem volt DB mentésük, bár nem tudom hány gigáról van szó.
"Gyors helyzetjelentés, sajnos semmi igazán lelkesítőt nem tudunk írni:
- az adatbázisszerveren hardveres hiba lépett fel, ami jelenleg úgy fest, hogy a februárban upgrade-elt processzorhoz köthető
- ez a hiba magával rántotta a teljes adatbázist, a könyvtárstruktúra is sérült
- a hardveres rendszert sem tudtuk helyreállítani mostanáig, eleinte jónak tűnt, de aztán a recovery-be is beleborult
- visszakerült a régi cpu, és most tűnik először stabilnak a gép
- telepítődik a rendszer, másolódnak az adatok (egy-egy rész másolása is 4-5 óra)
- ha minden fent van, utána tudjuk csak elkezdeni megnézni, hogy az elvileg meglévő adatok gyakorlatilag is megvannak-e, tényleg minden el tud indulni stb.
Sajnos ezen a ponton biztosra kizárni az adatvesztést nem tudjuk (de reméljük, hogy elkerüljük), ahogy azt sem, hogy mikor lesz ebből újra működő lapcsalád. Ma nem túl valószínű."
Mi a tök?? Túlhúzták, a Xeont vagy füstös 13/14.-ik gen CPU-t raktak bele a szerverbe? Gyanús előjelek nem voltak, hogy a proci rosszalkodik?
PH: eddig is volt átlag heti 1 kiesés de azok legfeljebb 1 órán át tartottak. Most is lehet a heti 1 kiesésre gyúrnak de mostmár kedd reggeltől hétfő estig fog tartani.. 😁
Annak semmi akadálya sincsen, hogy egy HDD házába be legyen építve egy redundáns tömbösítő, ami az egyes lemezeket kezeli. Én nagyon pontosan leírtam a kulcs szavakat amik miatt szükséges a nagy méretű belső redundáns adatmennyiség. - sok nulla egymás után - sok 'I' egymás után - kevés nulla-'I' átmenet - RLL hibajavítás
- eszement frekvencia
Az ECC az már csak kb, 2,25% lévén 4K-s szektorok vannak általában. Így utólag megtaláltam a White Paper-ben egy részét az érveknek. Tök érthetően leírja, hogy a nulla-egy az már nem a mágnesezettség szintje, hanem a mágneses momentum polaritása. Meg hogy miért nem horizontális a felületre írás, hanem miért vertikális
Külön szoftveres cuccal meg az XP és előtte is. Legfeljebb nem volt értelme. Akkor sem értettem a kommersz otthoni vonalat, mikor a rendes kontrollerek kezelték a dolgot, itt a vashoz odaírták, hogy raid a *nix alatt ugyanazt a szoftveres baromságot kellett művelni, mint nem raides vason és az sem úgy műxött, hogy kivettem a vincsit aztán újraépült. Akkor meg kb. minek ugye, de legalább volt némi adatbiztonságabb. Első Linuxos vasamból is kirántottam, csere, nem megy. Ja, újra kell csinálni a partíciókat, raid szinkron, boot record, minden szépen kézzel. Hát, jó cucc ja.
SW raid, az régebbi találmány, bár a raid az nem mentés ugye és ebben az esetben lehet éppen ezért szívnak, hogy ha ilyenkor a filerendszer összekócolódik, akkor mindegy, hogy raid vagy sem.
A W10-nek van egy tároló funkciója, amivel RAID-ra nem képes régi alaplappal rendelkező gépnek is lehet adni redundáns tömböket, sőt ha jól emlékszem megoldható, hogy a rendszer is ilyenen legyen.
Szerintem kb. annyit tudunk, amit nyilatkoztak, hogy dráma van és szopolnak. Facén a sok okosaka meg infrastruktúra ismerete nélkül magyaráz a fotelből és mindenki más helikopter.
