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, ...
_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"

Reply via email to