Date: Thu, 28 Feb 2013 13:39:01 +0100 From: Polytropon <freebsd@edvax.de> To: "Joseph A. Nagy, Jr" <jnagyjr1978@gmail.com> Cc: "Questions @ FreeBSD" <questions@freebsd.org> Subject: Re: Fat Fingered An 'rm -rf' of Important Files Message-ID: <20130228133901.a067e368.freebsd@edvax.de> In-Reply-To: <512F45C1.7090004@gmail.com> References: <512ECA4A.3030202@gmail.com> <20130228100211.17e2cb43.freebsd@edvax.de> <512F45C1.7090004@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 28 Feb 2013 05:55:45 -0600, Joseph A. Nagy, Jr wrote: > On 02/28/13 03:02, Polytropon wrote: > > On Wed, 27 Feb 2013 21:08:58 -0600, Joseph A. Nagy, Jr wrote: > > Obviously we're talking about a USB stick, so no TB amount > > of data has to be processed. First of all: Do _not_ alter > > the USB stick in any way. No matter what you do, it can > > always get worse. > > Oh no, not a USB stick, I'm talking hdd partitions (4GiB on one, 64GiB > on another) but it will be the same process. I'll see about investing in > an external hard drive. Okay, than I must have misread something. But the same idea applies: Do not alter the disk in question (or at least not the partitions). If you have a spare disk, make a dd copy of the partition and work with that. Disks are cheap, your data is not. You're going to need a new disk from time to time anyway, so enough space to try out things is worth the purchase. > >> I've not wrote any data to > >> either partition since the accidental deletion. > > > > Very good. > > > > You can first make a copy of the file system (the whole > > stick) and use that: It will be faster to access and if > > you do something wrong, the original data (which we can > > assume is still there) won't be affected: > > > > # dd if=/dev/da0 of=stick.dd > > > > Now let me introduce you to the "list of helpful programs > > in case you've done something ultimately stupid" which I > > have already repeated several times on this mailing list. > > I'm sure you can find some program that will help you. > > See my individual notes regarding your specific situation. > > > > I will "refactor" text from a previous message. > > > > A worst-case tool to recover data (not file names, but file > > content) is testdisk; in ports: sysutils/testdisk. It's also > > on some diagnostics and recovery CDs like UBCD. > > I've tried test disk but it doesn't have a UFS option for some reason. I also had this problem with testdisk on UFS (also with accidentally deleted files). It might be that it needs to operate on a slice, not on a partition, but I am not sure about this. > > You can also try this: > > > > # fetch -rR <device> > > where would I fetch to? It will fetch to the current directory, that's why my suggestion with a disk big enough for restoring data. > > Also recoverdisk could be useful. > > also in /usr/ports/sysutils ? No, it's already part of the OS: /sbin/recoverdisk, and therefor "man recoverdisk" is available. > > The ports collection contains further programs that might be > > worth investigating; just in case they haven't been mentioned > > yet: > > > > ddrescue > > dd_rescue <- use this to make an image of the stick! > > magicrescue > > testdisk <- restores content > > recoverjpeg > > foremost > > photorec > > > > Then also > > > > ffs2recov > > scan_ffs > > > > should be mentioned. > > > > And finally, the "cure to everything" is found in The Sleuth Kit > > (in ports: tsk): > > > > fls > > dls > > ils > > autopsy > > awesome A suggestion: If you have understood the basics of a UFS file system (e. g. by reading McKusick's famous article), you'll see that data on disk basically equals inodes as a "form of database" that point to blocks on disks, either directly or to blocks pointing to other blocks. There are tools to write the content of the blocks into files, for example icat (from TSK). You can find out which blocks are in use by files using the command "blocks" from within fsdb (an OS tool); "fsdb -r <device>" to invoke, and "man fsdb" for instructions. Note that deleted files cause two things: The inode information will be cleared, and the blocks will be marked "unused". But chances are good that the blocks theirselves are intact, i. e. they still containt the data. > > Keep in mind: Read the manpages before using the programs. It's > > very important to do so. You need to know what you're dealing > > the testdisk man page is very unhelpful. ): Sadly true. :-( The program emphasizes a "self-explaining interactive" way to be used and shortens the amount of information provided in the manpage, because... well, nobody reads them, and people expect to simply click on "undelete" anyway. :-) There's better information here: http://www.cgsecurity.org/wiki/TestDisk Go down to "Documentation" and see what you can use. But note that TestDisk primarily is intended to deal with partition tables and file tables (primarily FAT- based). To recover files (as in: "data that is somewhere on the disk, but not in the file system anymore), give PhotoRec a try. More info than in its manpage here: http://www.cgsecurity.org/wiki/PhotoRec See my comment regarding MagicRescue later. > > with, or you'll probably fail. There is no magical tetroplyrodon > > to click ^Z and get everything back. :-) > > well, not so sure. Found a Windows program to recover deleted stuff on > UFS, but I imagine it's harder touse then the above (and more > expensive). There are recovery tools for "Windows", but as you said, those that actually work are quite expensive. Tools like TSK can do the same, but are _much_ harder to learn. You still have the option to send the disk to a recovery comany and pay them $$$, this will maybe lead to a faster result, but you'll never know what they actually do, and you won't be able to add the item "data recovery" to your skill list. :-) > I will definitely work on the above first. You can use the free / trial versions to check _if_ there will be anything to restore. I did so myself (with the "R-Studio Emergency" life system CD and "UFS Explorer" under wine), but then did the actual restore work with free tools. Further suggestions to use with The Sleuth Kit: # tsk_recover -v -e -i raw ${DISK} ${OUT}/ 2>&1 | tee /tmp/tskr.log where ${DISK} is the disk partition to deal with, and ${OUT} the directory where to output results. Also see "man fls", it can be used to spot deleted files (and their inode numbers and if they have been re-allocated, good food for icat and fsdb). To "scan through the bare data", you can use MagicRescue. Try something like this: # magicrescue -r /usr/local/share/magicrescue/recipes -d ${OUTDIR} ${IMAGE} where ${OUTDIR} is where you want to store the results, and ${IMAGE} is the image of the disk (but applying this command to the partition device will probably also work). -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130228133901.a067e368.freebsd>