Sérült particiós tábla.

UNIX haladó

Tanácstalanságomban fordulok hozzátok... próbálom összeszedni időrendi sorrendbe az eseményeket hogy a lehető legjobb döntés meghozatalába segítsetek nekem.

Adott egy rendszer ~10 éve még debian 4.0-val kezdődött az élete majd sorba fel lett frissítve szépen talán 8-as debianig. Idő közben az utolsó szakaszban eltelt 3 év és a szerver nem lett újraindítva.

Jött a nagy bumm... egyszer csak a rendszervinyót Read-Only módba vágta, amit úgy vettünk észre hogy a mysql szerver elhasalt.

A nagy kapkodásban a MySql szerverről készült egy friss bináris mentés (amit hála istennek azóta használunk tovább) viszont a levelezésről (cca 5giga) illetve 4-5 fontosabb "weboldalról" de inkább háttér alkalmazásnak használt fájlokról elfeledkeztem.

Reboot.... hátha.... hát nem! :(

Kernel panik. Éjjel be a szerverhez, és próbáltuk újraéleszteni a rendszert, először egy új kernel felépítésével ami egy ideig nagyon szépen ment, kapott új grubot, kernelt, csak valamiért nem akart elindulni ez végül is nem releváns most.

Kiderült hogy van 2 db badsector a lemezen, így rebootot követően DD-vel akartunk csinálni egy képet, de végül átgondolva, hogy ez nagyon lassú, és úgyis új rendszert kellene építeni, úgy döntöttünk hogy csak csatoljuk fel a lemezt, mentsük le amit le kell levelezés+fontos fájlok (kb 10 giga) és nem kell a DD....

A probléma nem lehetett mountolni a disket mert fs hibát írt ki. Gondolkoztunk az fsck-n de jelezte hogy a badsector miatt adatvesztés lehet ezért meg sem próbálkoztam vele.

Hazahoztam a vinyót, majd itthon próbáltam lementeni róla az adatokat, testdisk-el. ami látta a mappákat, de üres volt minden mappa.

Egyértelmű volt hogy ehhez az én tudásom már kevés, így szakmai segítséghez fordultam. Egy adatmentéssel foglalkozó céghez mentem hasonló profizmust ígértek mint a KÜRT de fele áron. Tisztáztuk a feltételeket hogy nekem csak akkor sikeres a mentés ha a fájlokat kapom vissza mappákba (végülis nem képekről van szó amit majd szétválogatok hanem levelező rendszerhez tartozó fájlokról). Az első fekete leves akkor fogadott mikor a sürgősségi felárat kifizettem és azonnal ránézett egy technikus a vinyóra. Közölte hogy a fej már ki se jön a biztonsági zónából, felpörög de nem történik semmi, szóval ez biztosan laboros lesz.

El is vitték másnap a laborba ahol leszakadt fejre hivatkozva kértek 10 napot amíg a gyártótól beszerzik a fejet, amire nekem nem volt időm (azóta eltelt már amúgy 2 hét) ezért mondtam nekik hogy semmi gond ugyan abból a szériából nekem van hideg tartalékom, és mint kiderült 2-3-mal arébb jött le a szallagról, tehát minden klappolt. (ez volt egy kellemesen meleg csütörtökön).
Pénteken telefonáltam nekik ahol mondták hogy minden rendben 90% hogy vissza tudják állítani az adatokat, nyugodjak meg de hétvégén nem dolgoznak a laborba csak ha nagyon durva felárat fizetek. Hétfőn jelentkeznek.

Jelentkeztek, rossz hírrel, a particiós táblát nem tudják megcsinálni, így lementették a disk tartalmát egy image fájlban (winyóneve.img) ami egy dd-nek felel meg 239 giga, de még próbálkoznak valami szoftverrel (már az image-n) visszaállítani az adatokat. Kedden reggel jelentkezzek.

Kedd reggel jelentkeztem és az eredmény: image lementve, menjek vigyek egy legalább 250 gigás adattárolót megkapom az image fájlt. Ők nem tudták visszaállítani a particiós táblát úgy hogy az adatok olvashatóak legyenek. Bár a szerződés értelmében az adat visszaállítás 100%-os volt mert imageben megkaptam a disk felületén található adatokat, nekem értékelhetetlen volt az eredmény. Végül korrekten elváltunk nem kellet kifizetnem a megállapított díjat, csak a sürgősségi bevizsgálás díját, ami 5 perc volt és megállapították hogy a fej nem jön ki a biztonsági területről.

A szakmaiságot illetően nem vagyok biztos benne hogy jó céget választottam, de nem a múltat akarom megváltoztatni, mert óránkénti távoli biztonsági mentéssel ez az egész megelőzhető lett volna, hanem megoldást szeretnék találni.

Most ott állok hogy van két diskem (egy donor és egy ami érték számomra) amit nem merek bedugni mert ugyan összeszereltek, de az eredeti állapotba tehát elvileg a leszakad fej került vissza a régi vinyóba a donorba meg a sajátja. Van egy image fájlom amivel én nem tudok mit kezdeni.

Első kérdésem, hogy szerintetek van-e értelme elmenni a kürt-höz és belerokkani az általuk ajánlott árba vagy sem.

A második sokan kérdezni fogjátok a testdisk MS DATA particiókat lát, fájlok nincsenek.
Az fdisk pedig ezt látja:

root@debian:~# fdisk -l /dev/loop1
Disk /dev/loop1: 232,9 GiB, 250059350016 bytes, 488397168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0001c3e8

Device Boot Start End Sectors Size Id Type
/dev/loop1p1 * 63 476327249 476327187 227,1G 83 Linux
/dev/loop1p2 476327250 488392064 12064815 5,8G 5 Extended
/dev/loop1p5 476327313 488392064 12064752 5,8G 82 Linux swap / Solaris
root@debian:~#

p1: itt vannak az adatok
p2: swap volt.
p5: egy régi régi messzi messzi galaxisban véletlenül két swap lett létrehozva és nem foglalkoztunk vele.

A fájlrendszer ha minden igaz ext2 volt (nem emlékszek hogy ext3 vagy ext2 és az ext2 az adat visszállító cég adta a számba, de a deian 4.0 idejében én is úgy emlékszek hogy ezt2 volt a default.

Első levegőre ennyi.... tanács? Nem mondom hogy pénz nem számít, de szánunk rá pénzt.

A helyzet az hogy ez egy vps, amit erre a célra hoztam létre. egy külső vinyóról buzergálom az image-t és van 2db backup egy a hoston egy pedig egy offline külső vinyón. Ezen a VPS-en bármilyen ökörséget csinálhatnék ezért is hoztam létre hogy ne egy használatba lévő rendszert vágjak szét egy egy olyan program használatával ami minden függőségi szarral szétkeni a stabilan működő programokat.

( kisbetu v | 2018. 10. 28., v – 17:36 )

p1: itt vannak az adatok
p2: swap volt.
p5: egy régi régi messzi messzi galaxisban véletlenül két swap lett létrehozva és nem foglalkoztunk vele.

p1: biztos...
p2: egy extended partíció (type=5)
p5: a swap az extendeden belül, a legtöbb galakszisban

( SzBlackY | 2018. 10. 28., v – 18:57 )

Próbáld ki egy "-o debug,ro"-gal is a csatolást, hátha abból látszik, hogy mi vele gond (és próbáld ki expliciten megadni az ext2 típust).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( sanyex | 2018. 10. 28., v – 19:02 )

"Kernel panik. Éjjel be a szerverhez, és próbáltuk újraéleszteni a rendszert, először egy új kernel felépítésével ami egy ideig nagyon szépen ment, kapott új grubot, kernelt, csak valamiért nem akart elindulni ez végül is nem releváns most."

Ez alatt pontosan mit értünk ? Mert ugye ezekhez a műveletekhez működő fájl rendszer kellett.. Ebben az esetben pedig jó eséllyel pont ti nyírtátok azt ki.

Ezzel csak arra utalnék, hogy ha a fentiek igazak, akkor a kezedben lévő image túl sokat nem érhet, mert szerintem nem csak partíciós tábla probléma van.

Egyetértek. Ez szét van qrva keresztbe-hosszába, amin a Kürt sem fog tudni segíteni. Ők is csak fizikailag tudják visszahozni az adatokat img-be, de logikailag nem hinném, hogy ki tudnák bogozni.

Elvileg meg lehet próbálni a lemezkép másolatán próbálkozni, létrehozni rajta ext2 partíciókat, szektorról szektorra próbálkozva, hátha lesz 1-2 partíció, amin lesz még értelmes adat, de nem nagyon reménykednék benne. Ebbe bele kéne nyugodni, hogy önhibából történő adatvesztés volt, nem volt se RAID, se backup, így járás esete. Tanulni kell belőle, és legközelebb jól csinálni. Eleve nem lett volna szabad sajnálni az időt mindjárt egy dd-re.

No keyboard detected... Press F1 to run the SETUP

Osztom a nézeteid, csak van egy X tényező amit nem veszel figyelembe.... a kapkodás, és az hogy ilyenkor nem gondolja át az ember nyugodtan egy sör mellet egy szakmai haverral átbeszélve hogy mik a helyes lépések, hanem nekiesel mint hülye gyerek a legónak, és a kapkodásnak ez lesz az eredménye.

Egy biztos hogy a saját butaságaim a legjobb tanárok, mert még egyszer ilyen hibákat egymásra nem fogok halmozni az is biztos!

Osztom a nézeteid, csak van egy X tényező amit nem veszel figyelembe.... a kapkodás, és az hogy ilyenkor nem gondolja át az ember nyugodtan egy sör mellet egy szakmai haverral átbeszélve hogy mik a helyes lépések, hanem nekiesel mint hülye gyerek a legónak, és a kapkodásnak ez lesz az eredménye.

Én azt se értem, aki olyankor kapkod, amikor nem kritikus a helyzet, de kritikus helyzetben még aki egyébként nem szokott gondolkozni, annak is kellene.

Mivel eleve kernel panik volt, rengeteg hibával ráadást túl öreg volt már a kernel (3,5 éve nem volt újraindítva a szerver... akkor is csak valami apró dolog miatt távolról) ezért a 2.6.18 illetve 2.6.24 illetve 2.6.26 os kerneleknek nem álltunk neki javítani, pláne hogy a rendszer viszonylag naprakész volt (pontosan nem tudom de deb 7.0-ig biztosan de szerintem már deb 8.0 ig is naprakész volt...) úgy gondoltuk hogy felteszünk egy új kernelt.

Hogyan:

Ubuntu live cd... felmountoltuk a szükséges mappákat pl "mount --bind /dev /mnt/dev" és először megpróbáltunk feltenni egy friss 2.x-es kernelt, ami szintén nem indult. Utána újrapróbálkozás, de már 3.x kernellel.... ami szintén problémát okozott.... azthiszem itt jött elő hogy a grub is öreg, így kapott egy új grubot, de lehet hogy a 4.x-es kernelnél volt ez... végül mikor nem indult, a kernelbe elkaptunk egy I/o hiba sort, akkor mondtam hogy jó DD-vel mentés.... eszembe jutott hogy basszus 250 gigát le DD-zni ökörség mikor jó ha 10 gigára lenne szükségem csak és a rendszer amúgy is kukába megy, na ebben a pillanatban a dd kiírta ezt a sort:
dd: error reading '/dev/sda': input/output error.

Ezt követte hogy még 1x megpróbáltuk felmountolni a vinyót hogy simán le coppy-zam az adatokat, de már sajnos nem volt felmountolható, és a fent leírt hibát írta ki.

Ha maga a telepítések baszták szét a particiós táblát akkor nekiállok egy windows szerver tanfolyamnak és felhagyok a unixal mert ha ez volt a kiváltó ok akkor ez vicc.

Gyanítom hogy valóban io hiba lehetett. (a cég mondta hogy 2db badsector és talán 4db gyenge szektor volt a vinyón), de ügye a diskről készült image, az elmondásuk szerint 100%-os... tehát a badsectorrol is sikerült visszaállítani amit kellet.

Lentebb írta valaki hogy jó dolog hogy látszanak a particiók... én is így gondolom, mert ha sérül nagyon a particiós tábla akkor semmi nem látszik csak egy raw disk....

Ebbe szerintem semmi zavaros nincs. Nem vádaskodok, de szerintem csak simán lementették az adatokat és kész... ha csak ennyit mondtak volna hogy lementjük mert ez egy egyszerű eset akkor nem tudnak ilyen magas árajánlatot adni. A probléma ott lett nekik hogy nem tudták a fájlrendszert helyreállítani.... szerintem nem is ilyen helyzetekre rendeződtek be... amikor voltam 2x voltak valami egyetemtől, mert a külső vinyójuk beszart és a képek kellettek... így ha csak bányásszák a képeket, kap egy dsc00xxxx fájlnevet és kibogarássza magának az ügyfél, és ezzel elégedettek....

( taarzaan | 2018. 10. 29., h – 02:06 )

Amúgy legközelebbre, amolyan köztes megoldás lehet dd helyett a fájlrendszer klónozása, ha nincs agyonhasználva a fájlrendszer. Clonezilla elég hatékony tud lenni. (Pláne, hogy egyéb hasznos infókat is rögzít a művelet során és talán nem azon kéne utólag meditálni, hogy vajon milyen lehetett a fájlrendszer)

Most, ha jól értem, akkor a mysql, a levelezés és a fontosabb fájlok végeredményben helyre lettek állítva, azokról készült backup még időben, nem? ...vagy az már leszakadt fejjel készült és igazából nem lett használható eredmény?

Mi az, ami akkor hiányzik?

Az fdisk kimenet amúgy megegyezik az eredetivel?

Gondolom azon már túl vagyunk, hogyan mountoljunk fel particiót image fileból...
https://askubuntu.com/questions/69363/mount-single-partition-from-image…

e2fsck mit mond?

Bocs a kérdésért, de csináltál neki saját könyvtárat (pl mkdir /mnt/saved) ? /root és /mnt alá szerintem kevés rendszer lesz hajlandó bármit is mountolni közvetlenül :/ ...kérlek pontosan fogalmazz és mondjuk parancssor logokat mellékelj... te érdeked lenne...

...nem mellesleg egy bash history vagy /var/log/messages fájl visszaszerzése is már hasznos lehetne photorec-kel, ha a könyvtárstruktúrát még nem is tudod visszaállítani.

Itt válaszolok többek felvetésére. Eredetileg volt klonozott raid ezért volt hidegtartalék a labornak. A probléma hogy hirtelen szükség volt egy vinyóra ezért a másik vinyót vettük igénybe. Tudom faszság be kellet volna menni másik vinyót betenni, tisztába vagyok a hibáinkkal, nem megkövezésért jöttem ide, eléggé kövezzük mi saját magunkat a hülyeségek miatt, hanem segítségért jöttem, hátha valaki tud egy kis szikrát adni nekünk.

Backup készült több mindenről, sőt nem egy vinyó volt a szerverbe hanem sok, többségük raidben van még most is. A rendszer vinyón volt a levelezés (nincs róla mentés) nem is mindről kéne igazából 1-ről amiről nem pop3-mal töltötték le a leveleket. A mysql-ről készült naponta 2x dump, de arról sikerült még a legelső restart elött amikor read-only módba tette magát a rendszer csinálni bináris mentést, így erről naprakész mentésem lett. (igen tudom ekkor kellet volna mindenről mentés csinálni, újra kövezzetek meg sőt ez közvetlenül az én hibám, én adtam ki a halálos reboot vezényszót). Ezek mellet volt 4-5 Vhost ami hátér folyamatokat végzett pl az adatbázison stb, ez lenne nagyon fontos, mert erről sincs naprakész mentés.

A backupok nem leszakad fejjel készültek, nálam még nem volt semmi gond a vinyóval. Amikor bevittem a céghez és kifizettem a sürgősségi azonnali bevizsgálás díját, akkor jött egy "technikus" gondolom bedugta és közölte hogy nem indul el a fej a helyéről.... majd késöbb a labor mondta hogy le van szakadva a fej és kell egy donor vinyó. (amit én adtam, különben 10 nap lett volna. ez volt az a vinyó amit kb 2 hete leválasztottunk és másra használtunk. lementettem róla az adatokat, kivettem a szerverből, és odaadtam a labornak hogy szedjék szét, és használják donornak.)

az fdisk kimenet tökre megegyezik most azzal aminek lennie kéne. lát mindent... még azt is hogy az sda1 boot partició....
Ez a kimenet megegyezik azzal aminek lennie kéne:

/dev/loop1p1 * 63 476327249 476327187 227,1G 83 Linux
/dev/loop1p2 476327250 488392064 12064815 5,8G 5 Extended
/dev/loop1p5 476327313 488392064 12064752 5,8G 82 Linux swap / Solaris

innen gondoltam hogy igazából olyan nagy baj nem lehet mert ha sérült a particiós tábla pl a badsector miatt, akkor szerintem a particiókat se látná rendesen, vagy csak részlegesen....

természetesen az fdiskből látszik hogy felmountoltam az image fájlt ezért lett /dev/loop1 az eszköz neve... és innen nyerem ki az fdisk adatokat, illetve így próbálok dolgozni tehát a jelenlegi /dev/loop1p1 felel meg a régi /dev/sda1 -emnek amiről az adatok kellenének.

természetesen prbóáltam már mindenhogy felmountolni, próbáltam rootba (bár ez csak itteni kérdés miatt hogy mit ír ki) próbáltam simán az mnt-be is, de a legelső probálkozásomkor az /mnt/hdd1 -be próbáltam tehát csináltam saját mappát neki.

Hibaüzenetek logok, igazából mindent leírtam már mindenkinek aki kérdezett, egy marad ki a syslogból most néztem ki két sort a mount próbálkozás után:

Oct 29 09:15:10 debian kernel: [778141.602296] EXT4-fs (loop1p1): mounting ext2 file system using the ext4 subsystem
Oct 29 09:15:10 debian kernel: [778141.602486] EXT4-fs (loop1p1): bad geometry: block count 61049000 exceeds size of device (59540898 blocks)

Remélem, resize2fs már megoldotta a problémát :)
...elvileg illene neki:
https://www.linuxquestions.org/questions/linux-general-1/cannot-mount-h…

Szerintem érdemes kipróbálni közvetlenül az egész diskre is:
resize2fs /dev/loop1

...ha mégsem:

nekem ezek a "/dev/loop1pX" device-ok gyanúsak...

Kérhetnék alábbi kimeneteket?
sudo fdisk -lu sda.img
ls -al sda.img

Lehet, hogy valami elírás történt és a partícióra rá lett dd-zve a teljes image... vagy fordítva...

Esetleg szerver típust kérdezhetek, amiből a disk származik?

Már csak holnap fogom tudni kivitelezni, mert kimerült a mobilnet keretem és a korlátozott mobilnet mire bead egy képet összeomlok idegileg 2x...

Elírás nem történt, dokumentálva lett (fotó) az összes művelet hogy mindent vissza tudjak keresni ha kellene... és már 100x kielemeztünk mindent oda vissza...

Szerver típus: http://eps.msi.com/server/K9ND_Master_Series_MS9182_series#tab=download…

A többit képzeld hozzá :) 2006-os építés...

- nos... a resize2fs azt mondja hogy elöbb futtasam az e2fsck-t, amit lent láthatsz hogy milyen eredményekkel fut....

- nem tudom hogy /dev/loop1pX ezek miért gyanúsak neked.... ugye a labor nem particióról csinált bináris image-t hanem a komplett eszközről, így nekem az imageben 3 partició van. Az imaget "felcsatoltam" mintha eszköz lenne és az eszközön van 3 parcició.... p1 ami eredetilet az sda1 volt és a másik kettő meg a swap.

- az fdisk -lu kimenetelét fent látod a nyitó poszban.

- root@debian:/home/max7# ls -al /dev/loop1
brw-rw---- 1 root disk 7, 1 okt 20 19:19 /dev/loop1

Koszi az infokat... azert gyanusak a loop1pX device-ok, mert egyszer talalkoztam hasonlo bug-gal beagyazott linuxnal, hogy egy teljes image csatolasakor pl csak a benne levo particio meretet vette alapul a teljes image-hez... vagy ilyesmi... szoval ezert erdekelt volna kozvetlenul az image fajlbol kinyert info (akar meg loop device letrehozasa elott)

Itt az a fura, hogy a 61049000 az kb. pont megfelel a teljes hdd méretének. Nem lehet, hogy valaki odatett egy olyan superblock-ot, ami a teljes hdd-nek felel meg, nem pedig a partíciónak? Vagy esetleg az, hogy rossz a partíciós tábla, és eredetileg csak 1 partíció volt rajta (azaz nem volt 5.8G elkülönítve, hanem egyben volt az egész)?

1000% hogy volt swap! és az is 1000% hogy amit az fdisk kiír az megfelel a valóságnak tehát ahogy most látja az úgy is nézett ki!

Ez azért tuti mert én raktam össze a raidot, és én is szedtem szét és a szétszedés nem olyan régen volt, így emlékszek is rá, illetve lett berakva másik vinyó és akkor is volt fdisk -l kiadva és szinte fejből megtudom mondani hogy melyik vinyó hova van beduva melyik az "a" melyik a "b" és hogy azokon belül melyiken mennyi partició van és hogy mi hova van felcsatolva.

Okés, akkor a másik eset van, hogy valaki/valami átírta a filerendszer méretét a superblock-ban. Kérdés, ki/mi, és miért. Ha jól értem, akkor megvan ennek a vinyónak egy régebbi tartalma valahol? Mert akkor össze lehetne vetni a superblock-ot, hogy tényleg különbözik-e. Vagy azt, hogy vajon az összes superblock megváltozott-e (mert ugye, mint mondtam, az ext2 több helyre is duplikálja a superblock-ot).

Amúgy, nekem furcsa ez a sok hibaüzenet az fsck-nál. Most vagy az van, hogy valami olyan metaadat sérült meg, hogy az fsck meghülyül, és azért dob ennyi hibát. Vagy pedig az, hogy mégiscsak sokkal több sector sérült meg.

Nincs. Volt egy rendszer vinyó, ami klónozva volt raid tömben. Szükség lett egy 250 gigás vinyóra, hirtelen ezért szét lett rugva a tömb. Majd most hogy kellet egy donor, kivettük ezt is és donor lett belőle. Szóval sajnos nincs.

Nem lett semmi olyan téve ami hozzá nyúlt volna a particiós táblához. Ezért nem értem. Illetve ha ennyi sérülés van akkor nem csak 2 bad sector volt..... igazából előre megállapodtunk hogy ha nem tudják a mappaszerkezetet visszaállítani akkor részemről sikertelen a visszaállítás, így nem lett volna értelme hazudnia a cégnek hogy 8000 badsector helyett csak 2 db-ot mondtak.

Itt akkor most nem a partíciós tábláról van szó, mondtad, hogy az rendben van. Hanem a filerendszerben eltárolt méretről. Az ext2 eltárolja saját magáról, hogy mekkora (meg még egy csomó metaadatot - ezek egy része van a superblock-ban). Na, ez az érték nem stimmel. Mintha valaki/valami átírta volna a HDD teljes méretére a partició méretéről. Mivel pont ~5.8GB-tal nagyobb érték van benne, mint kellene. Ez csak úgy nem íródik át... és pont egy olyan értékre, aminek pont van köze a HDD méretéhez.

ha a superblok sérült (tegyük fel pont ott volt a badsector, bár ezt nem igen valószínű) akkor lehet hogy valami pl egy fsck (amit nem futtatunk) nem kereste meg a backup részt és nem onnan akarta visszállítani hanem beállította a disk méretét?

Bár ezek minden feltételezések, és nem juttat közelebb az adatokhoz :(

Hát, ha nem futtattátok, akkor nem valószínű :) Az nem lehet, hogy akik leszedték az image-t, azok nyúlkáltak bele?

Amúgy dumpe2fs-sel meg tudod nézni a superblockot, hátha van ott valami gyanús. -o superblock=szám-mal tudod kiválasztani a superblock-ot. A szám pedig az, amit a Group X-nél kiír Blocks **-**, itt az első szám.

Akik leszedték az imaget először mentettek és utána imagevel próbálkoztak, mivel nem voltam ott csak remélem hogy nem a leszedett imagevel és azt adták oda hanem másoltak egyet és azon próbálkoztak.

dompe2fs nekem nem mond semmit ehez én már kevés vagyok de hátha neked mond:
https://pastebin.com/9SzUvVna
alul még folyatatódnak kb 4x ennyi mert 2 mega lett a txt-be importált dumpe2fs tartalma de a pastebin csak 512kb-ot enged.

Az vajon akkor hogyan lehet, hogy Oct.29. az utolsó írás dátuma, ha nem nyúlt bele senki a filesystembe? Ez a dátum nem azutáni, hogy elszállt a HDD, és elviekben nem történt rajta semmi módosítás?

Szinte 100%, hogy itt valaki/valami beleírt a filerendszerbe utólag. Annak a valószínűsége, hogy a blokk szám eddig is rossz volt, kb. 0. Tehát valami megváltoztatta azt. Az meg kb. kizárt, hogy pont arra a számra változik meg, ami a HDD méretének felel meg.

oktober 28.-án indítottam a topikot... valószínüleg valamit már futtattam rajta... este ha hazaérek újratöltöm az image-t és lekérek arról egy friss dumpot.... bocsi nem volt szándékos a félreinformálás.... hozzáteszem valami továbbra sem stimmel, mert azóta próbáltam fsck-t futtatni rajta, és az elvileg modosított rajta, és annak is látszania kellene.....

este jövök az új dumppal...

Kicsit jobban ránéztem az fsck kimenetére, és az összes hibaüzenet amiatt van, mert rossznak hiszi a filerendszer a saját méretét. Szóval elviekben csak vissza kellene írni a méretet az igazira, és készen is vagyunk. Vagy legalábbis a hibaüzeneteknek a nagy része el fog tűnni. Ezt akár egy hexa editorral meg lehet tenni (mondjuk jó kérdés, hogy az fsck miért nem csinálja ezt meg, fura).

Elviekben a 0x404-es offseten van a méret, a következő byte-oknak kellene ott lennie: "0xA8 0x88 0xA3". És ezt kellene kicserélni mondjuk "0x80 0x85 0x8C"-re, ez egy biztonságos értéknek tűnik (jó lenne tudni persze az eredeti méretet pontosan. Ha megvan még az a mke2fs, amivel csináltad, akkor meg lehetne nézni, hogy akkora partícióra pontosan mekkora FS-t csinál). Mondjuk arra nem tudom, mit lép a rendszer, hogy csak 1 superblock-ban írjuk ezt át (meg hogy, ha van checksum a superblockban, akkor az se fog stimmelni), de reméljük, hogy megoldja :)

Ez nekem sajnos kínai... ennyire nem ástam bele magam a particiós tábla rejtelmeibe, de ha jól veszem ki itt többen azt mondták hogy ez az adat több helyen le van tárolva (biztonsági okokból).... akkor miért nem keressük meg azt és írjuk át az elsődleges adatot arra ami a biztonsági helyeken van?

Mert szinte biztosan nem véletlenül annyi az a szám, amennyi. Azaz valami tool írta át, ami nyilván átírta mindenhol. Az fsck egyébként megtenné azt, amit mondasz (azaz, ha az fsck észreveszi, hogy a master superblock hibás, akkor megjavítja azt egy másolat segítségével. Mivel ezt itt nem teszi, feltételezhető, hogy az összes másolat elromlott, azaz szándékosan lett átírva).

A hex editálás nem egy nagy ördöngősség amúgy, midnight commanderben van beépített hexa editor. F3(view), aztán pedig F4(hex), F2(edit), megeditálod, majd F6(save).

Ha jól nézem, akkor a partíció a 63-as sectornál kezdődik, szóval amit írtam, hogy 0x404-en van (ez ugye a partíción lévő offset), az az image-ben valszeg a 0x8204-en lesz.

Vagy még az lehet (tudom, mondtad, hogy nem, akkor is mondom :) ), hogy mégse az a partíciós tábla, hanem a HDD-n egy nagy partíció volt.

Ebben a dologban valaki vagy nem mond igazat, vagy rosszul emléxik, ez egészen biztos.

Oké. Akkor csak az a kérdés, hogy hogyan lehet, hogy a filerendszer mérete nem egyezik a partícióval, hanem a HDD méretével azonos. Vajon ki/mi írta azt át? És nem csak az a szám lett átírva, hanem a reserved block szám is (defaultból 5% ugye a rootnak fenntartott terület. És ez a szám is szépen stimmel: 3052450/61049000=0.05). Sőt, az inode szám is stimmel: azt mondja, hogy összesen van 15269888 inode, grouponként 8192. Amiből ~1864 group jön ki. Ami megfelel a HDD méretének: 250059350016/32768/4096.0 (HDD mérete/blocks_per_group/block_size) = ~1864. Tehát minden szám arra vonatkozik, hogy az FS a HDD méretére lett készítve, és nem pedig a particióéra. Ha a partició méretét nézzük, akkor csak 59540898/32768.0 = ~1817 groupnak kellene lennie. És ugye pont az 1818. groupra száll el az fsck.

Valami itt nagyon nem kerek.

( Dwokfur v | 2018. 10. 29., h – 08:05 )

Az szerintem már eleve egy szerencsés eset, hogy látszódik az image-ben a partíciós tábla.
Ha nem megy virtuálisan, akkor keríts magadnak egy identikus vinyót és írd ki rá az image-et. ?
Klónozásra meg ddrescue, vagy dd_rescue (a sparse opció használata nélkül).

Üdv:
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Ezt én sem értem; de azt sem, hogy 2 bad block-tól miért ne lehetne felmount-olni? Mit akarna csinálni, ha e2fsck-val nekimész?

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

( kmARC v | 2018. 10. 29., h – 08:54 )

Sok sikert a tűzoltáshoz.

Én azt nem értem, hogy ma még adnak fizetést "szakembereknek" akik egy 5G nagyonfontos levelesládát képtelenek biztonságban tartani 2018-ban, amikor 2perc alatt bárhol lehet ingyér10G synceket két kattintással szerezni.

> A szakmaiságot illetően nem vagyok biztos benne hogy jó céget választottam
Lehet csak külső megerősítő véleményre vár a tudatalattid: biztos hogy nem jó céget választottál. Csilliós fizetések az egekben, pár hét alatt találsz újat, hajrá.

( hnsz2002 v | 2018. 10. 29., h – 10:15 )

Egy HDD-ről ment a "nagyonfontos" rendszer? Mindenféle backup nélkül? Ki üzemeltette ezt, hogy se nem frissítette, se nem indította újra 3 évig? Gondolom smart vagy egyéb bármilyen monitoring se volt beállítva a gépre, amiből esetleg előre látszódott volna valami...
--
"Sose a gép a hülye."

Monitoring nem volt beállítva viszont kb a baleset elött 1 héttel néztem hdsentinel linuxos változatát mivel a nyers S.M.A.R.T nekem nem mond semmit vagy csak erős guglizgatás után és minden 100/100-as volt, nem volt semmi hiba, sem gyenge szektor stb. A szervert pedig nem rugdosták, victor hugóba van, eléggé komoly szolgáltatónál.

Ha visszaolvasol volt raid tükrözés amire szükség volt. Igen itt elkövettük a legnagyobb hibát.

Sajnos a hibákkal mi is tisztába vagyunk, közösen hoztuk meg a döntéseket így nem hibáztatjuk egymást inkább csak mindenki saját magát. Megoldást keresünk, nem okokat az akasztásra.

Pedig itt az kell, hogy elfogadjátok, hogy a ti hibátok, és okultok belőle. Nem szemétkedésből írom, a saját károtokból tanulnotok kell, még ez is jobb eset annál, mint amikor valaki a saját kárán sem okul. Nem kell akasztani senkit, azzal már senki nem lesz előrébb, legközelebb kell ügyelni, hogy normálisan meg legyen csinálva a rendszer, RAID-en minden adat, minden partíció, plusz rendszeres mentés mindenről, nem összekapkodva, hogy 2 swap, meggondolatlan kernelfrissítés és hasonló gányolások, rendszeresen frissítve a rendszert, nem úgy, hogy évekig rá se néz senki.

Abban biztos vagyok, hogy itt nem csak 2 szektor sérült. Ha így lenne, akkor a superblock-másolatból (eleve több másolatban tárolódik) vissza kéne tudnia állítania mindent az fsck-nak. Ha az utóbbi forced yes kapcsolóval sem tudja megjavítani, akkor bukta van. Baracklekváros.

Erre a közösen hozott döntésekkel is vigyázz, ha ilyen inkompetens a cég. Vagy te üzemelteted a rendszert kompetensen, nem közösködve, vagy ha ragaszkodnak a közös döntésekhez, hogy más is szabadon belegányolhasson a rendszerbe, akkor meg szépen vállalják ők a felelősséget. Most vagy te üzemelteted normálisan, és rád bíznak mindent, vagy ha ők úgy gondolják, hogy jobban értenek hozzá, akkor üzemeltessék ők, de ez a csoportos egyik erre üti, a másik amarra kalapálja módszer, mindenki kapkod össze-vissza, a végén senkinek nem lesz felelősségre vonható típusú rendszer az egyik legrosszabb, ami létezik. Így legalább az meglesz a jövőre nézve a RAID meg a rendszeres mentés mellett, hogy felelősségre lesz vonható, aki miatt kiesés vagy adatvesztés volt.

No keyboard detected... Press F1 to run the SETUP

( geza42 | 2018. 10. 29., h – 10:16 )

Hát, ha tényleg csak pár sector döglött be, akkor vissza kellene tudni hozni (majdnem) az összes adatot. Ext2-nek a superblock-ja több helyen duplikálva van, szóval kb. mindennek meg kellene lennie. Amúgy a particiós tábla megléte/nem megléte túl sokat nem számít, ha nincs is partíciós tábla, hamar meg lehet keresni a partíciókat.

Tudom, hogy sok értelme nincs már mondanom, de az alap, hogyha hdd hiba van, akkor nem rebootolunk, nem írunk rá semmit. Hanem azonnal lementjük a legfontosabb adatokat (NEM dd-zünk!). Ha ez megvan, utána mehet a dd.

A halvány ész felvillant bennem is, ezért lett realtime-os mysql bináris mentés....(igazából úgy vettük észre hogy valami gond van hogy lehalt az sql).... ha tudnék utazni az időben nem érdekelne a szerver, minden pénzem feltenném meg még hitelt is vennék fel és azt is feltenném egy tuti nyerő 3-mas vagy 10-es odds-ra a tipmixen :D

( MGy v | 2018. 10. 29., h – 12:55 )

Egy ötlet, hogy ne csak arról legyen szó, hogy a múltban mit kellett volna csinálni.
Lehet, hogy csak az fs szuperblokkja sérült meg, de az adatok megvannak. Amikor készül a filesystem a szuperblokkról készül egy csomó bakup, amit az mkfs ki is ír, hogy hova tette. Az fsck-nak meg lehet mondani, hogy honnan vegye a szuperblokk másolatot (talán e2fsck -B, de a man-ban benne van). A másolatok helyét ki is lehet matekozni, de legegyszerűbb, ha egy ugyanakkora méretű üres partíción csinálsz egy mk2ft-t és felírod, hogy hova tette. Valószínű az is oda tette a másolatokat, amivel a sérült készült.
Javítás előtt még futnék egy kört azzal is, hogy a muntnak megadod az alternatív szuperblokk helyét - a blokkméret kicsit kavarhat, olvasd el itt: https://www.cyberciti.biz/tips/mounting-with-an-alternative-superblock…

( hgen | 2018. 10. 29., h – 16:02 )

gpart megpróbálja kitalálni a partíciós táblát, persze nem biztos hogy sikerül is neki.

Itt 100%, hogy a szuperblokk sérült, a partíciós tábla megvan a kimenetek szerint. De nem értem hogy történhetett, mert ha még a bad sector pont itt is keletkezett, a szuperblokkról kéne lennie másolatnak, meg ha még rossz kernelt is frissítettek és kernel panic fordult elő, annak sem kéne hazavágni a fájlrendszert.

No keyboard detected... Press F1 to run the SETUP

Én úgy gondolom hogy bármit telepítek az nem nyúl az fs táblához az csak adatokat másol adott partícióra. így maximum egy létező adatot kellet volna felülírnia..... de nem a partíciós táblába módosít.... maximum egy fsck ami belenyúlhat, de az se tönkre vágja hanem megjavítja, és az meg már a módosítás után történő dolog.... azt sem értem hogy ennyi helyen hogy lehet gond:
https://pastebin.com/vvqWsJaM

Az fsck-t nem futtattam még végig amúgy, mert 45 perc után meguntam hogy rá kell feküdni az "i" gombra. Nézegettem hogy lehetne ezt megoldani, de mindenhol csak a probléma adott, sikeres választ sehol nem írtak még.... bár a labor a saját image fájlján lefuttatta.... legalábbis amit az átadó elmondott, hogy dobókockával ékelték ki az I betűt de hogy miért azt nem tudta elmondani, ebből arra következtetek hogy a laborosok lefuttatták az fsck-t és nekik nem oldotta meg a problémát.... (mert akkor kaptam volna adatokat és a gatyámat is otthagyom náluk.

Minden ötletet szívesen fogadok és kipróbálok :)

Fingom nincs hogy ki és milyen titulusba dolgozik ott... Amikor először mentem még a wc-re is kísértek.... másodjára mire mentem nem volt ott már a "tulajdonos" akkor már be akartak engedni hogy ránézzek a vinyóra hogy tényleg csak felpörög.... a labor meg olyan titkos hogy 1 munkanapot kellet várnom hogy munkaállomást szabadítsanak fel és betegyék üvegfal mögé a vinyómat....

mint írtam egyetemről járnak oda adatokat visszaállítani.... szóval nem teljesen kóklerek és elvileg ha azt feltételezem hogy tényleg leszakadt a fej akkor végülis kaptam bináris mentést....

Pont ebben a szálban már megírták, hogy az e2fsck-t -y kapcsolóval futtatod. Ez azzal egyenértékű, mintha ráfeküdtél volna az „i” gombra. Szigorúan csak a mentés másolatán próbálkozz vele, mert elméletben az is előfordulhat, hogy nem csak hogy nem segít, de még jobban szét is cseszi az egészet, mint eredetileg volt.

No keyboard detected... Press F1 to run the SETUP

Ezt írtam én is, de írta a topiknyitó, hogy az fsck különbséget talált a partíciós táblában tárolt méret, és a superblockban tárolt méret közt. Így rákérdez hogy abbahagyja-e. A válasz meg automatikus igen .....ugye.
A sluszpoén, hogy elvileg a resize ezt meg tudná oldani, de az meg nem fut le, amíg nem tiszta az fs. Szóval ördögi kör.

---------------------------------------------------------------
Ritkán szólok hozzá dolgokhoz. Így ne várj tőlem interakciót.

Ez tényleg szopatósnak tűnik elsőre, de akkor futtatja először kézzel, ott megjavítja a méretkülönbséget azzal, hogy az abba nem hagyást választja, aztán a következő kérdésre is nem, ezzel kilép. Majd utána mehet végig automatán -y kapcsolóval.

No keyboard detected... Press F1 to run the SETUP

Sajnos nem engedi az fsck a pipe-ot. A másik sajnos, hogy ennyire ostoba, hogy nincs neki olyan kapcsolója, ami azt mondaná, hogy "javítsd meg, nem érdekel, hogy mi veszik el". Eléggé kőkorszaki azt hiszem, hogy a "-y" tényleg azt jelenti, hogy "yes always". Még akkor is, ahol inkább a "no" lenne a helyes válasz. Ennek az opciónak így semmi értelme. Kivétel, ha pont olyan szerencsés a helyzet, ahol az "y" jelenti mindig azt, hogy "menj tovább, és fixálj, amit tudsz".

na de nincs egy force vagy egy akármilyen erőszakos kapcsolója? Ez vicc azért....
Meg hát a manual szerint:

"-a
Automatically repair the file system without any questions (use this option with caution)."

Gyenge angoltudásommal az én értelmezésemben: Automatikusan kijavítja a fájlreszert bármilyen kérdés nélkül.

Erre azt mondja hogy futtassam kézzel..... a illetve p kapcsoló nélkül mert csak..... na de basszus ha egyszer ezt akarom miért erőszakoskodik?

Nincs baj az angoloddal. Ezt így kell érteni, de nem a teljes man-t idézted be. A -a kapcsolónál ott van, hogy már csak visszafelé kompatibilitás miatt maradt benne, helyette a -p kapcsolót kell használni. A -p kapcsolónál meg oda van írva, hogy nem minden hibát javít, csak azokat, amiknek a javítása kockázatmentes, nem igényel emberi beavatkozást. Meg lehet ezeket próbálni, de nem fognak segíteni. Kipeckeled az i-t és ránézel néhány óra múlva.

No keyboard detected... Press F1 to run the SETUP

( mrceeka v | 2018. 11. 03., szo – 21:53 )

Valamelyik másik superblock-al próbáltad mountolni vagy fsck-zni?

pl.
e2fsck -f -b 98304 /dev/akarmi
mount -o sb=98304 /dev/akarmi /mnt/akarhova

Üdv,
Marci