Obnova smazaných souborů z ext3/ext4

7.1.2011 13:02 | Přečteno: 8800× | Linux |

Doma na zálohování používám externí disk 640GB, který připojuji přes USB. Mám jej rozdělený na dvě partition. Na jednu zálohuji já, na druhou manželka. Zálohuji na něj podle potřeby. Někdy jednou za měsíc, někdy obden. Používám na to grsync.

To by všechno bylo v pohodě nebýt mé blbosti. Asi před měsícem jsem upgradoval PC včetně HDD. Přeinstaloval jsem systém na 64bit, z disku nahrál data zpět. Ale kopíroval jsem to ručně a zapomněl na adresář zzz. Ten je docela důležitý, obsahuje zálohu souborů, které se nemění a občas je potřebuji (iso nějakých CD, konfigurace VPN, nějaké zdrojáky, zálohy SQL webů atd.). Dneska jsem chtěl zase zálohovat. V klidu připojím disk do USB, spustím grsync, nastavím adresáře, nastavím grsync tak aby smazal soubory, které na zdrojovém disku neexistují. No a klepnu na Spustit. Před očima mi projel výpis toho co se maže. Na prvním místě adresář zzz. Než jsem stihl zareagovat, byl v háji. Polilo mě horko. Pamatuji si, jak jsem někde četl informaci o tom, že jakmile data smáznu, jsou v háji. Obnovení je buď vůbec nemožné nebo jen velmi obtížné. Zeptal jsem strýce Googla jak na to. Po přečtení x fór a stesků uživatelů jsem narazil na program extundelete. Z webu jsem stáhl zdrojáky zkompiloval pomocí ./configure && make. Make install jsem nedával a použil binárku přímo z adresáře src.

  cd src
  ./extundelete /dev/sdd1 --restore-all

V src vznikl adresář RECOVERED_FILES, který obsahoval vše, co se povedlo z disku obnovit. Naštěstí tam byl i můj zzz.

Pomocí konfiguračních voleb lze upřesnit co obnovovat:

./extundelete
No action specified; implying --superblock.

Usage: ./extundelete [options] [--] device-file
Options:
 --version, -[vV]       Print version and exit successfully.
 --help,                Print this help and exit successfully.
 --superblock           Print contents of superblock in addition to the rest.
                        If no action is specified then this option is implied.
 --journal              Show content of journal.
 --after dtime          Only process entries deleted on or after 'dtime'.
 --before dtime         Only process entries deleted before 'dtime'.
Actions:
 --inode ino            Show info on inode 'ino'.
 --block blk            Show info on block 'blk'.
 --restore-inode ino[,ino,...]
                        Restore the file(s) with known inode number 'ino'.
                        The restored files are created in ./RESTORED_FILES
                        with their inode number as extension (ie, file.12345).
 --restore-file 'path'  Will restore file 'path'. 'path' is relative to root
                        of the partition and does not start with a '/' (it
                        must be one of the paths returned by --dump-names).
                        The restored file is created in the current
                        directory as 'RECOVERED_FILES/path'.
 --restore-files 'path' Will restore files which are listed in the file 'path'.
                        Each filename should be in the same format as an option
                        to --restore-file, and there should be one per line.
 --restore-all          Attempts to restore everything.
 -j journal             Reads an external journal from the named file.
 -b blocknumber         Uses the backup superblock at blocknumber when opening
                        the file system.
 -B blocksize           Uses blocksize as the block size when opening the file
                        system.  The number should be the number of bytes.
Error parsing command-line options.

Některé soubory měly špatný název, respektive do názvu byla doplněna nějaká písmena. Po přejmenování bylo vše v pořádku. Archivy se daly normálně rozbalit, iso také, textové soubory také v pořádku. Protože jsem program spustil s --restore-all obsahoval adresář také spoustu někdy dávno smazaných souborů.

Existence tohoto programu mi ušetřila dost práce. Adresář zzz a i celou zálohu musím uložit i na jiný disk a ty nejdůležitější části i na CD/DVD. Nerad bych si toho někdy zopakoval. Třeba se někomu bude info o tomto skvělém programu hodit.        

Komentáře

[Max]

Ano, zrovna nedávno se tu řešila podobná věc : Dotaz: obnova ztracených dat

Něco z historie :
Data v p*** muzika v p*** všecko v pr****
Midnight Commander (a jemu podobní) a F5 vs. F8
Zdar Max

[xkucf03]

Obnova ztracených souborů

[Grunt]

No, to já jednou měl téměř plný disk (tak 10GB volné místa), stáhnul 8GB soubor a pomazal ho. Ono čistě tereticky jde zase jen obnovit samotný pointer a není potřeba dělat takové harakiri (zvlášť blbě by se 8GB soubor na 2GB volného místa obnovoval na tom stejném disku). Teda čistě teoreticky, protože po pár dnech zápasení jsem ten soubor radši stáhnul znova. Když jsem ho znova promazal tak jsem málem vyletěl střechou a po pár dnech zápasů jsem ho radši znova stáhnul.

Takže jsem mladý, pohledný a perspektivní a hledám: Blbuvzdorný žurnálovací souborový systém s kruhovým bufferem, podobným řazením dat jako JFFS2 a příkazem sakra_prace_uz_rolll-back_one-step.

[fred]

mas v tom zmatek, mladí, pohlední a perspektivní si nemazou data ;)

[phr]

Blbě : Mladí, pohlední a perspektivní nemusí hledat.

[CET]

V rsyncu ZASADNE pri pouziti --delete pouziju taky prepinac -n

[limit_false]

Nejvetsi problem s undelete na ext3 je, ze zurnal kod nuluje inody (a pointry v inodech). Tudiz je nutne hledat fajl jinak (podle hlavicek atd.). Na ext4 se stestim to bude jednodussi, kdyz se FS rozhodne naalokovat pro soubor jeden nebo jenom malo extentu.

Undelete na Reiser 3 se dela hledanim stylem "kde sakra je koren toho B* stromu?" (tam to o moc lepe stejne nejde). Kdyz mate na Reiser 3 partition jiny Reiser 3 image (treba ulozen jako soubor), tak to klidne muze najit ten "spatny" strom. Proto pozor na --rebuild-tree.

Reiser 4 uz neundeletne ani sam Hans Reiser Kdyz je zapnuty tail-packing, pak ani kompletni team Namesys-u. Z podobneho duvodu je temer nemozny undelete na XFS.

V nejhorsim lze pouzit nejake data carving tools a doufat, ze budete mit stesti.

[gtz]

ext3grep je pro ext3 celkem slušný. O XFS jsem již zde byla zmínka a je to celkem hodně velký problém.

[gtz]

V nejhorsim lze pouzit nejake data carving tools a doufat, ze budete mit stesti

u XFS se dá použít testdisk/photorec, ale tyto nástroje neudělají strom, jen zkopírují to co najdou a pokud se něco takového stane pak je to celkem problém to dát dohromady. Sofistikované řešení od recovery společností stojí kupu peněz.

[limit_false]

Zavisi predevsim jak moc je ten XFS rozbity a jestli chcete jeden soubor nebo co nejvic souboru. Jinak je to fakt jako kdyz se promichaji znaky necitelneho write-only perloveho skriptu a pak se to clovek snazi dat dokupy jak to bylo puvodne

XFS ma taky nejakou variantu na tail-packing, tusim ze kratke soubory schovava rovnou do inode.

[Amarok]

Tak to je dost slusna informace. Resil jsem to asi pred 2 rokama a jedine, co google vyplivl, byl skript nejakeho chlapika, ktery na svem blogu popisoval, jak pomoci toho skriptu data obnovit (programovani skriptu mu trvalo asi tyden). Ten navod na pouziti mel asi 5 stran a delalo se mi z toho spatne (nastesti jsem nebyl v situaci, kdy bych to potreboval).

Ted uz to nejen nepotrebuju, ale je mi to i k nicemu, jelikoz jsem kompletne presel na JFS. Jeste jsem nekoumal, jestli nejaky undelete pro JFS existuje.

[limit_false]

Zrovna s JFS nemam moc dobre zkusenosti, rozsypal se mi celkem rychle (za par mesicu), ale recovery tools to zachranily myslim bez chyby. Preventivne jsem tam nic duleziteho nemel (jsem zkousel, ktery FS na co nejvic vyhovuje).

[Amarok]

To bych tipoval, ze nemohlo byt zpusobeno JFS. Pokud je pravda, ze je JFS vyspely file system a pouziva ho IBM na velkokapacitni disky, tak neni mozne, aby se na to nedalo 100% spolehnout. Na externim disku mam JFS uz asi rok (ale jen obcas tam neco zkopiruju, je to disk pro backup), v PC mi ted JFS bezi par dnu a teda doufam, ze problemy nenastanou. Me se na nem hlavne libi ten extremne rychly fsck, oproti ext3 opravdu dramaticka casova uspora.

[Heron]

Já bych tyto diskuse ani nezačínal. Neexistuje FS, se kterým by někdo neměl špatnou zkušenost a současně někdo jiný dobrou. Toto jsou zbytečné flamy. Všechny FS označené jako produkční jsou stejně dobré, vlastnosti toho kterého FS někomu vyhovují více, někomu méně.

[limit_false]

+1

[Cohen]

(BTW, doporučuji místo prostého rsync používat rdiff-backup. V takovém případě by se nic nedělo.)

[Pavel Čejka]

Já riziko zničení zálohy řeším nejčastěji skriptem, který zálohy sám cykluje, přinejmenším jako lichá/sudá, takže v nejhorším přepíšu blbě tu starší a aktuálnější zůstává (nespustím-li skript vícekrát, obvykle spouští cron a reportuje mailem).

Podobně to lze řešit ručně. Např. pro zdrojáky, kterých jsou tisíce souborů řádově v desítkách kB až MB používám DVD RAM a opět cykluju 1. až nté. Pravděpodobnost zničení nejdůležitější zálohy se tím radikálně sníží. Už kvůli tomu, že jednomu cílovému médiu prostě nelze důvěřovat.

Nevýhodou je, že potřebuju nejméně 2x tolik místa v cíli, než mají zálohovaná data, ale stojí to za to.

[kyekros]

Nedá mi to, ale musím vzdát čest a slávu aplikaci PhotoRec. Díky ní jsem z ext4 souborového systému obnovil omylem smazaná jpg data. Troufnu si říci, že 100% všech smazaných.

Nikdy nezapomenu na tvář mé přítelkyně, když dnes ráno na mě otočila hlavu a řekla "Smazala jsem všechny fotky z vánoc a v koši nejsou."

Ihned jsem restartoval její notebook, nabootoval live-CD Parted Magic připojil externí disk a začal obnovovat data pouze z volného prostoru na disku. Zadařilo se...