On Mon, Oct 02, 2006 at 08:56:57AM -0400, Jeff Quast wrote: > On 10/1/06, Joachim Schipper <[EMAIL PROTECTED]> wrote: > >On Sat, Sep 30, 2006 at 07:24:43PM +0200, Bambero wrote: > >> Hello > >> > >> I need to recovery overwritten txt file. > >> > >> Ex. > >> echo "my data" > testfile.txt > >> echo "" > testfile.txt > >> > >> I have partition image file creted using dd. > >> Is it possible to dump it and search using grep for example ? > >> Is it possible to recover overwritten data ? > > > >Well, let this teach you about the values of good backups. amrecover > >(AMANDA) is considerably friendlier than what you're about to go > >through... (and I can attest to both from personal experience. Ouch.) > > I only backup my large repositories and media once a month. 29 days of > work is worth hunting for.
My backups are semi-daily, and /home is synchronised regularly between my laptop and my desktop. A single hard disk crash is enough to get one truly paranoid [1]. > >You're quite lucky, though, to have deleted a plain text file. Provided > >you still know a couple of words, you could search for them. grep -A > >would work, but be careful to redirect it or it'll mess up your > >terminal. > > (I dont see how grep would help here) I was going to talk about how a text file contains easily-findable data, most of the time, but considering the link you posted below... grep -bA /dev/rwd0a might be a quick way to get some offsets, without using special tools (hexedit really isn't, but most people aren't familiar with it). > >Tools like TCT (The Coroner's Toolkit, by Wietse Venema &c) or The > >Sleuth Kit (more modern; apparently, Autopsy is something of a GUI for > >it) could help a lot, if you're desparate. > > > > Joachim > > hexedit works just fine for this purpose imo. > > http://archives.neohapsis.com/archives/openbsd/2005-01/1717.html > > It is very safe to use, and free (as in COST, it is probobly gnu, not > meeting my own concept of 'free'). That's another option, yes. It all depends on what one likes. Joachim [1] The student association's server. No data was lost, but we were *really* lucky that /var/mail was in the part that didn't get damaged, and /usr was. The other way round would have been thoroughly unpleasant. Also, it was a good thing we were doing backups, albeit to another hard disk, and that it wasn't the second hard disk that failed. Quite a scare, although it amounted to no more than a couple of hours of downtime in the end.
