Obnova smazaných souborů z ext3/ext4 (diskuse)

[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...