Trumpas aprašymas kaip vyko duomenų atstatymas

Pradinis nuskaitymas

Du mėnesius buvo mėginta nuskaityti duomenis su dd_rescue pagalba. Šiaip tai buvo mėginta pasitelkti į pagalbą ir kitas priemones (sakykim - labiau specializuotas) šiam reikalui, bet jos pasirodė kur kas mažiau efektyvios nei dd_rescue. Taipogi buvo mėginama padėti ir techninėmis priemonėmis - išvalyti visi susijungimai, kontaktai.

Duomenų surinkimas

Bet kokios trečių šalių programos pasirodė visiškai neefektyvios, lyginant su standartiniais reiserfs įrankiais. Visą pagrindinį darbą atliko reiserfsck + hexdump'as. Dirbama buvo su dd_rescue pagaminta disko kopija, tiesiogiai su originalu niekas nedirbo. Labai nemaža dalis (~800 objektų) buvo prarasta negrįžtamai, dar dalis (~300) buvo sugadinti. Labiausiai nukentėjo tos vietos, kurios buvo arba dažniausiai naudojamos, arba buvo sukuriami nauji failai jų vietoje. Keletas iš tokių objektų, kuriuos reiserfsck reportino kaip prarastus:

rebuild_semantic_pass: The entry [20250 20274] ("log.MYD") in directory [17829 20250] points to nowhere - is removed

iš tikrųjų pavyko atstatyti, tegul ir labai sugadintus, bet dalis iš duomenų juose išliko. Tam buvo panaudota hexedit bei dd.

MySQL duomenų surinkimas

Visur buvo naudojama MyISAM lentelės. Kai kur buvo prarasti frm failai (nesudėtinga atstatyti žinant struktūrą, arba analizuojant MYD), kai kur - MYI (nesunku rebuildinti, ypač žinant struktūrą). Bet kur kas blogiau, kad kai kur buvo sugadinti MYD failai. Teko prisižiūrėti turbūt šimtus MySQL segfaultų pakišant sugadintas lenteles ;-) Kai kur teko redaguoti rankomis MYD failus, iškarpant sugadintas vietas, kai kur - replacinant gero failo duomenis atstatytų duomenų blokais. Taip buvo atstatyta ~90% visų duomenų. Nebuvo dedama pastangų atstatyti rečiau naudojamas vietas - admin forumui, e107 testinėms bazėms ir panašiai.

Keletas reikalingų DB vistik neišliko. Iš naujųjų saulėtekio forumų išliko išvis, tik žinutės (su kalnu papildomos info, kas, aišku, iš vienos pusės nesuteikia garbės DB dizaineriams dėl normalinių formų nesilaikymo, bet iš kitos pusės - padėjo atstatyt duomenis), bei skilčių pavadinimai. Kitos reikalingos lentelės, pavyzdžiui, visai prarasta buvo naujųjų forumų privačios žinutės (išliko jų dumpas iš senųjų forumų), narių profiliai ir, kas blogiausia - visų temų sąryšiai. Sąryšius po kurio laiko pamėginau atstatyti su tokia stored procedūra MySQL'e (turėtų tikti ir kitur, ne tik SMF'ui):

    delimiter //
    DROP PROCEDURE IF EXISTS lpall //
    CREATE PROCEDURE lpall()
    BEGIN
        DECLARE done INT DEFAULT 0;
        DECLARE a INT;
        DECLARE crs
            CURSOR FOR
            SELECT DISTINCT(ID_TOPIC)
            FROM smf_messages;
        DECLARE
            CONTINUE HANDLER FOR
            SQLSTATE '02000'
                SET done = 1;
        OPEN crs;
        REPEAT
            FETCH crs INTO a;
            IF NOT done THEN
              UPDATE smf_topics 
              SET ID_FIRST_MSG = (SELECT MIN(ID_MSG) FROM smf_messages WHERE ID_TOPIC = a), 
              ID_LAST_MSG = (SELECT MAX(ID_MSG) FROM smf_messages WHERE ID_TOPIC = a),
              numReplies = (SELECT COUNT(*) FROM smf_messages WHERE ID_TOPIC = a) 
              WHERE ID_TOPIC = a;
            END IF;
        UNTIL
            done
        END REPEAT;
        CLOSE crs;
    END;
    

Neypatingai efektyvu, bet užtat veikė, rezultate - 2/3 lentelės atstatyti. Buvo prarasta peržiūros statistika, bei kai kur susimalė temų pavadinimai, bet toks praradimas dar priimtinas.

Buvo dar iškilę problemų su koduotėm (reikia nepamiršt - saitas buvo kuriamas ~2003 metų pabaigoje, duomenys pradėti ištraukinėti 2006 pradžioje), bet jos tai santykinai lengvai išsprendžiamos ;-)

Dabartinė situacija - dauguma lentelių yra read-only režimu (tiesą sakant, jei dabartinė mano naudojama MySQL versija palaikytų BLACKHOLE storage engine tai visos lentelės būtų read-only, ir kelios, kurios būtinos funkcionavimui - BLACKHOLE), ir planuojama taip palikti - kad būtų kaip archyvas tik skaitymui.

Laiko sąnaudos

Maždaug du mėnesiai dd_rescue darbo (beveik automatinis procesas, t.y. žmogaus įsikišimo reikėjo labai nedaug), ~3 savaitės iš viso žmogaus darbo.


2008.08.10 ABLomas