Keskustelu: Yleinen keskustelu: Tietokannan palautus hajonneelta levyltä

Mod. otsikoi. Vanha otsikko: Tiedoston signature ja offset

Mikähän olisi MAMP sovelluksen käyttämien tietokantatiedostojen .frm ja .opt sekä .sql HEX muotoinen signature ja signaturen offset? Mitä nuo sitten suomeksi onkaan; allekirjoitus, kuittaus? Koetin netistä etsiä (siis englanniksi tietysti), mutta joko en ymmärtänyt avata oikeaa sivua tai ei muuten vain osaa.

Voisiko joku viisaampi auttaa tässä?

Voitko avata vähän tilannetta jossa tuollaiset tulee vastaan.

"File signature" tarkoittaa usein tiedoston alussa olevaa tunnistetta. Se voi myös tarkoittaa tiedoston allekirjoitusta, jolloin se tyypillisesti on allekirjoitettu tiiviste.

Koska tietoa on ilmeisen vaikea hakea, voin antaa suoran linkin: MySQL .frm File Format. Etsi sivulta sanaa ”always”, niin näet vakiokentät, joita on useita, mm. tavut FE ja 01 tiedoston alussa.

Helposti voi omin silmin todeta, että opt-tiedosto sisältää ASCII-muotoisia asetuksia. Sen sijaan sql-päätteisiä tiedostoja ei ainakaan minulla tietokantapalvelimella näy yhtään, mutta ehkä kyseessä on tekstimuotoisia MySQL-kyselyitä sisältävä ”SQL-dumppi”.

Kyllähän minä tätä koetin hakea ja tuonne samalle sivulle päädyin, mutten vain ymmärtänyt tuosta listasta mitään. Johtunee siitä, ettei minulla ole hajuakaan mitä tiedoston signature ja offset ovat (enkä jaksanut lukea koko tekstiä läpi, koska sana-haulla huomasin, ettei se sisältänyt mitään signaturesta).

Juu, tuo sql-päätteinen tiedosto on nimenomaan MySQL-kyselyitä sisältävä "SQL-dumppi" eikä niitä tosiaan ole tietokantapalvelimella. Idea ei nyt kuitenkaan ole se mitä tietokantapalvelimella on ja mitä ei ole.

Tarvitsisin näitä frm, opt ja sql-päätteisten tiedostojen signaturea ja signaturen offsettiä Remo Recover nimiseen ohjelmaan, jolla koetan kaivaa kovalevyltä poistettuja tietokantatiedostoja esiin. Voisin kohdistaa ohjelman haun tietyn tyyppisiin tiedostoihin (juuri niihin frm, opt ja sql), jos tietäisin nämä asiat.

"Enter signature in hex (e.g. FFD8)"
"Enter offset of signature in file (e.g. 0)"

Tuo Metabolixin neuvo ei nyt valitettavasti auttanut yhtään. Kun noita vakiokenttiä on niin paljon, niin mikä tavu olisi se oikea? Mitkä tiedot minun pitäisi tälle ohjelmalle antaa, jotta se osaisi etsiä kovalevyltä näitä haluamiani tiedostoja?

Minulla ei siis ole hajuakaan mitä signature ja offset ovat ja ASCII sekä hex ovat minulle käytännössä lähes tuntemattomia, eikä näiden tutkiskeluun löydy erityisemmin mielenkiintoakaan. Jos siis joku voisi vain antaa suoraan sen oikean vastauksen mitä minun kuuluu tuolle ohjelmalle syöttää, niin olisin oikein kiitollinen.

MySQL:n frm-tiedoston kohdalla siis syöttäisit tuohon luultavasti tiedot FE01 ja 0. Tekstitiedostoissa yleisesti ei ole mitään vastaavaa tietoa, mutta SQL-tiedosto saattaa alkaa SQL-kyselyn kommenttimerkeistä, joten voit kokeilla hakea tiedoilla 2D2D20 ja 0. Onneksi opt-tiedosto on käytännössä turha; voit kopioida sen vaikka toisesta tietokannasta.

AkeMake kirjoitti:

ASCII sekä hex ovat minulle käytännössä lähes tuntemattomia, eikä näiden tutkiskeluun löydy erityisemmin mielenkiintoakaan.

Jos meinaat ohjelmointiuralla edistyä, kannattaa kyllä tällaisista tietokoneiden perusasioista ottaa selvää. On hyvin aikaa lukea vaikka Wikipediaa, kun ohjelma etsii noita tiedostoja. ;)

Kiitos!

En aio kehittää tästä uraa itselleni, joten pyrin edistymään ohjelmoinnissa vain siinä määrin kuin mielenkiintoa harrastelulle löytyy. Ei tällaisten perusasioiden ymmärtäminen siitä huolimatta varmaan haitaksikaan ole, joten voisihan tuota joskus hiukan tutkia mistä näissä oikein on kysymys. :)

Sain nyt tutkittua kovalevyn läpi. Löytyi 33000 yli 50 gigan frm-tiedostoa ja 1400 yli 50 gigan sql-tiedostoa (tarkkaanottaen 52,43 gigaa).

Miten on mahdollista, että 1 teran levyltäni löytyi yli 1800 teraa tietoa ja suurin osa siitä on juuri näitä frm ja sql-tiedostoja? Sisältääköhän nämä tiedostot mitään järkevää, kun levyltä sai muka kaivettua noin paljon tavaraa?

Kannattaako minun maksaa vajaan 200 euron lisenssiä tähän ohjelmaan, jotta saisin otettua nuo löydetyt tiedostot ulos tuolta kovalevyltä? Eli voikohan nuo 50 gigan tiedostot sisältää sitä erehdyksessä poistettua MAMPin tietokantaa, jota olen etsimässä?

Mod. yhdisti keskustelut.

Syksyllä koneesta hajosi kovalevy ja olen koettanut Remo Recover ohjelmalla palauttaa siinä yhteydessä kadonnut tietokanta. Sain [äsken] ohjeet miten palautan MAMP käyttämiä .frm -tiedostoja. Remo Recover palautti niitä yli 7500 tiedostoa. Laitoin ne paikkaan, jossa MAMP säilyttää tietokantoja ja kopioin toisesta tietokannasta opt-tiedoston näiden seuraksi. Sen jälkeen koitin avata nämä phpMyAdmin:lla, mutta se ilmoitti:

phpMyAdmin kirjoitti:

MySQL ilmoittaa:

#2002 - Can't connect to local MySQL server through socket '/Applications/MAMP/tmp/mysql/mysql.sock' (2)
Palvelin ei vastaa (tai paikallisen palvelimen pistokke ei ole määritelty oikein).

Koetin netistä etsiä ohjeita miten .frm-tiedostoja voi lukea, mutta joko englantini tai muu käsityskykyni näistä asioista petti. Olisiko minun pitänyt siis komentoliittymän avulla koettaa jotain tehdä? Sen kanssa olen täysin peukalo keskellä kämmentä.

Voisiko joku antaa rautalankaohjeen miten noiden .frm -tiedostojen lukeminen onnistuu?

Kannan data on joka tapauksessa ihan muualla, niin et sä noilla minnekään pääse. Binäärimuotoisen datafilun lukeminen on muutenkin eri asia kuin tietojen palauttaminen vaikkapa oikeasta dumppifilusta, joten sulla lienee tekemätön paikka edessä.

Yli 7500 tiedostoa kertoo jo, että tiedostoissa ei ole luultavasti järjen häivää, ellei sinulla sitten todella ollut yli 7500 taulua kannassasi.

Tiedostoja ei ylipäänsä avata phpMyAdminilla, vaan MySQL-palvelin avaa ne. Virheilmoituksesta näkyy, että selvästi MySQL-palvelin ei ole käynnissä: joko unohdit käynnistää sen tai viallinen data esti sen käynnistymisen.

Palautusprojektissa voi saman tien unohtaa ehjän tietokannan käsittelyyn tarkoitetut koodit, jotka vain ottavat yhteyden SQL-palvelimeen. Vähän viallisen taulun osittainen palauttaminen saattaa onnistua MySQL:n omilla työkaluilla (ks. MyISAM Table Maintenance and Crash Recovery), mutta jos tilanne on pahempi (kuten luultavasti on), on turha haaveilla taulujen palauttamisesta entiselleen, vaan tuurilla voit saada datasta palan sieltä ja toisen täältä jollain asiaan erikoistuneella ohjelmalla.

The Alchemist taitaa myös olla oikeassa, nimittäin dokumentaation mukaan ainakin MyISAM-taulun varsinainen data olisi .MYD-tiedostossa.

Elättelin toiveita, että edes jokin noista 7500 tiedostosta sisältäisi sitä mitä pitää. Ja kyllähän minulla oli koneella useita tietokantoja, jotka sisälsivät monia tauluja. Tuskin yhteensä kuitenkaan noin montaa. Ei kukaan sitten viitsinyt aiemmin sanoa minulle siinä vaiheessa, kun aloin puhua tietokannan palauttamisesta, etten tule näillä tiedostoilla saamaan sitä kannan dataa ulos?

Minulla oli MAMP auki, joten kai se huolehti siitä, että MySQL-palvelin oli käynnissä? Virheilmoitus johtui tieten sitten siitä, että data oli viallista.

Minunko pitäisi siis .frm -tiedostojen sijasta kaivaa levyiltä ulos näitä .myd ja .myi -tiedostoja?
Mitkä niiden "signature in hex" ja "offset of signature" sitten ovat, jotta niitä voisi etsiä?

Ja miten on mahdollista, että tämä Remo Recover löytää noita tiedostoja noin paljon ja ne kaikki ovat aina määrittelemäni maksimin kokoisia? Jos siis olen laittanut tiedoston maksimikooksi 50Mt, niin ohjelma löytää 7500 * 50Mt tietoa, vaikka kovalevyn koko on vain vähän päälle 200Gt.

Tästä lähtien kannattanee ottaa ajoittain varmuuskopiot tärkeistä tiedoista.

Juu, tuosta on tullut opittua ja nyt on varmuuskopiot kaikesta. Jälkiviisa(us|stelu) ei kuitenkaan auta tässä tilanteessa ja harvoin muulloinkaan.

Jos hajonnut levy on vielä tallessa, niin yksi mitä kannattaa harkita on https://www.grc.com/sr/spinrite.htm

Riippuen tilanteesta, tuolla saat levyn siihen kuntoon että pääset dataan käsiksi aivan normaalisti ja voit vedostaa matskun esim. mysqldumpilla talteen.

AkeMake kirjoitti:

Juu, tuosta on tullut opittua ja nyt on varmuuskopiot kaikesta. Jälkiviisa(us|stelu) ei kuitenkaan auta tässä tilanteessa ja harvoin muulloinkaan.

Näissä tilanteissa se juuri auttaakin jatkon kannalta.

AkeMake kirjoitti:

Elättelin toiveita, että edes jokin noista 7500 tiedostosta sisältäisi sitä mitä pitää. Ja kyllähän minulla oli koneella useita tietokantoja, jotka sisälsivät monia tauluja. Tuskin yhteensä kuitenkaan noin montaa. Ei kukaan sitten viitsinyt aiemmin sanoa minulle siinä vaiheessa, kun aloin puhua tietokannan palauttamisesta, etten tule näillä tiedostoilla saamaan sitä kannan dataa ulos?

Minua ei ainakaan kiinnostanut, koska tässä hommassa ei ollut alkujaankaan järjen häivää. Toisaalta Metabolix linkkasi sinut jo 7. tammikuuta MySQL:n dokumentaatioon, missä sanotaan frm-filujen olevan vain taulujen skeemoja ja kooltaan muutamia kilotavuja, ja että MyISAM-taulujen data löytyy myd-tiedostoista (ja InnoDB-taulujen ibd-tiedostoista).

lainaus:

Ja miten on mahdollista, että tämä Remo Recover löytää noita tiedostoja noin paljon ja ne kaikki ovat aina määrittelemäni maksimin kokoisia? Jos siis olen laittanut tiedoston maksimikooksi 50Mt, niin ohjelma löytää 7500 * 50Mt tietoa, vaikka kovalevyn koko on vain vähän päälle 200Gt.

Arvaan, ettet ole lukenut käyttöohjeita. Arvaan myös, että käytät jotain advanced modea, ja tuo syöttämäsi 50 Mt ei ole enimmäiskoko vaan tiedoston koko, mitä Remo Recover etsii. Eli kun ohjelma löytää määrätynlaisen tiedoston alun, se lukee 50 megatavua eteenpäin ja siinä on sulla "tiedosto". Nuo 7500 filua voivat olla ihan täyttä puppua tai skeematiedostojen vanhoja versioita, sillä tiedostojärjestelmät voivat joskus kirjoittaa tiedoston kokonaan uudestaan levylle, kun tiedostoa muokataan. Vanhan kopion varaamat sektorit merkataan vapaiksi mutta data jää levylle. Tähän perustuu koko recovery-ohjelmistojen toimintaidea.

AkeMake kirjoitti:

Ei kukaan sitten viitsinyt aiemmin sanoa minulle siinä vaiheessa, kun aloin puhua tietokannan palauttamisesta, etten tule näillä tiedostoilla saamaan sitä kannan dataa ulos?

Yleensä ihmisten ei tarvitse tietää, missä tiedostoissa MySQL säilyttää mitäkin dataa. Tulit kysymään frm-tiedostoista, joten oletin, että olit selvittänyt asiaa edes sen verran, että tuo olisi se oikea tiedostotyyppi.

AkeMake kirjoitti:

Ja miten on mahdollista, että tämä Remo Recover löytää noita tiedostoja noin paljon ja ne kaikki ovat aina määrittelemäni maksimin kokoisia?

Kovalevy ei ole mikään laatikko, jossa on ehjiä tai rikkinäisiä tiedostoja. Kovalevyllä on tavuja peräkkäin. Yhden tiedosto tavut eivät välttämättä ole peräkkäin, vaan tiedosto voi olla palasina. Osa levyn tavuista kertoo, mihin tiedostoihin muut tavut kuuluvat. Nykyään itse asiassa osa tavuista kertoo ensin, missä on lisää niitä tavuja, jotka kertovat tiedostojen tavuista. Tasoja voi olla enemmänkin. Jos jossain tällä matkalla on vikaa (tai jos palautusohjelma ei edes ymmärrä levyn tiedostojärjestelmää), ei ole paljonkaan toivoa suurten tiedostojen palauttamisesta. Luultavasti on käynyt juuri noin, kuin The Alchemist arvaa: palautusohjelma etsii levyltä kohdan, jossa on määrätty tavujono, ja olettaa sitten, että tiedosto on tästä tasan 50 megaa eteenpäin. Oletus ei useinkaan päde.

The Alchemist kirjoitti:

Toisaalta Metabolix linkkasi sinut jo 7. tammikuuta MySQL:n dokumentaatioon, missä sanotaan frm-filujen olevan vain taulujen skeemoja ja kooltaan muutamia kilotavuja, ja että MyISAM-taulujen data löytyy myd-tiedostoista (ja InnoDB-taulujen ibd-tiedostoista).

Ja samana päivänä minä vastasin, etten lukenut kyseistä sivua läpi, koska siellä ei mainittu mitään siitä etsimästäni signaturesta enkä muutenkaan ymmärtänyt kyseisestä sivusta paljoakaan.

The Alchemist kirjoitti:

Arvaan myös, että käytät jotain advanced modea, ja tuo syöttämäsi 50 Mt ei ole enimmäiskoko vaan tiedoston koko, mitä Remo Recover etsii.

En tiedä mikä on advanced mode, mutta sen verran englantia osaan, että "max file size" tarkoittaa tiedoston maksimi kokoa. Ja kun muuta tyyppiä olevat tiedostot eivät lähes koskaan saavuta niille määrättyä maksimikokoa, niin epäilen sen oikeasti tarkoittavan sitä mitä siinä lukee.

Tuo timoh:n antama ohjelma ei tieten toimi suoraan macin päällä vai ymmärsinkö tuon väärin? En osaa/halua alkaa asentaa mitään muuta käyttistä tai mitään sen kaltaista tähän tuon ohjelman takia ja rahaakin on palanut tähän touhuun jo sen verran, etten mieluusti alkaisi lisää rahaa polttamaan uusiin ohjelmiin.

Onko minun siis mitään mahdollisuutta saada haluamiani tietoja edes osittain ulos etsimällä noita .myd ja .myi -tiedostoja? Ja jos on, niin mitkä on niiden signature ja offset?

Tiedätkö nyt edes, olivatko taulusi MyISAM- vai InnoDB-tauluja vai jotain muita? Ihan mahdotonta tämä touhu, kun et edes tiedä, mitä etsit. (Mistä alunperin keksit, että etsisit frm-tiedostoja?) Lisäksi en käsitä, miksi et viitsi perehtyä asioihin vaan säädät ja sähellät ja heität rahaa hukkaan.

Mitä hakemalla nyt taas löytyy, ilmeisesti MYD-tiedostoissa ei ole mitään tiettyä otsikkoa vaan suoraan dataa, mutta koska data alkaa rivin otsikkotiedoilla, taulusta riippuen saatat pystyä muodostamaan pari tavua tiedoston alusta itse.

Sattumoisin samalla haulla löytyikin StackOverflow'sta kysymys taulun palautuksesta. Sieltä selviää, että voit luoda uudestaan samanlaisen taulun, jolloin saat oikean frm-tiedoston. Kun vielä lisäät tauluun itse sellaisen rivin, kuin kuvittelisit kadonneessa taulussa ensimmäisenä olevan, saat myös MYD-tiedoston, jossa on ehkä oikea alku (tai sitten ei, jos rivi on poistettu). InnoDB:ssä tilanne ei nähtävästi ole paljonkaan kummempi, mutta tiedostopääte on ibd.

Jos etsimässäsi taulussa on tekstiä, voit yrittää etsiä levyltä myös tätä tekstiä ja katsoa, löytyykö taulun näköistä kokonaisuutta. Tosin en nyt pysty tältä istumalta opettamaan täydelle ummikolle, miten kokonaista kovalevyä tutkitaan itse, joten jos kuulosti vaikealta, unohda koko juttu.

Jos data oli oikeasti tärkeää, ehkä kannattaisi vain viedä levy ammattilaiselle palautusta varten.

AkeMake kirjoitti:

Tuo timoh:n antama ohjelma ei tieten toimi suoraan macin päällä vai ymmärsinkö tuon väärin? En osaa/halua alkaa asentaa mitään muuta käyttistä tai mitään sen kaltaista tähän tuon ohjelman takia ja rahaakin on palanut tähän touhuun jo sen verran, etten mieluusti alkaisi lisää rahaa polttamaan uusiin ohjelmiin.

Näin on, levy täytyy siirtää operaation ajaksi PC:n alle. Mitään erillistä käyttistä et PC:ssä kuitenkaan tarvitse (SpinRiten mukana tulee FreeDOS minkä pohjalta saat homman käyntiin).

Hiemanhan SR maksaa, mutta luulen että se on helpoin tapa saada matskut talteen hajonneelta levyltä, tai siis saada levy siihen kuntoon että et tarvitse mitään erillistä palautusohjelmistoa datan onkimiseksi. Toki voi olla vastaavia ilmaisiakin ohjelmia, googlaamalla selvinnee.

Datapalautuksen ammattilaisista puheen ollen, tosiaan ja varsinkin jos data on arvokasta, niin nämä itse suoritetut palautusyritykset voivat vain pahentaa tilannetta. Kannattaa pitää mielessä.