Data recovery issue

mark9117 · 02-04-2012, 02:27 PM

I have a question which may or may not be appropriate here. Please feel free to point me in the right direction.

My daughter was backing up her data to a usb hard drive when she says that the usb connection wiggled loose or something and disaster ensued.

At this point, the file structure has been preserved as we found it. I've pulled a copy and what I have is about 7,000 directories. Here is an example of one of these directory/subdirectory trees:

$ pwd /7B15#n/F8U4#m/E#n#zAE/#o#f#y08/_#q2K#w

Some of these directories contain image files that have random strings for names, some have octal string files in them, and some have nothing in them.

I've tried using photorec to see if it could recover files but that only recovered deleted files (go figure).

How can I use something like the Find command to get the image files out of this furball? I can't seem to get the syntax right to recurse these directories for files of a given size.

Help?

Mark

mark9117 · 02-05-2012, 03:53 PM

OKay, I've got the syntax for "find" working and spitting out lists of subdirectories containing files greater than 4000k. It looks like this:

Code:

find . -size +4000k -ls
2093929 5852 -rw-------   1 madams   madams    5989080 Feb  4 00:52 ./#cI9HY/#f9AX#e/+#h#g8#z/#hC#p#lO/G1#kC#n/#g0
131611 6040 -rw-------   1 madams   madams    6182872 Feb  4 01:09 ./Y19#u+/#x#j#nKG/#t#tDZM/#b#u8P#r/IUDXJ/#sU
2226563 6748 -rw-------   1 madams   madams    6906576 Feb  4 01:07 ./UXLUW/QOM#g9/#mEG#d1/_HWDJ/#c#w8GG/#tU
131867 5820 -rw-------   1 madams   madams    5958680 Feb  4 01:10 ./YRO8#b/ER#mLO/#h#hM6B/2U#vIA/#p#k#xU8/6#c
1703189 9852 -rw-------   1 madams   madams   10088424 Feb  4 01:05 ./SJ#l0F/#t#iN#uN/#cFCBB/#m4#e#z#r/FB#fJ#g/CU
131147 5704 -rw-------   1 madams   madams    5839112 Feb  4 01:08 ./#wT0#v#g/#uP2+6/Y#c#nJ#a/#a0E1#a/#h#cC#nT/#a8
2224011 8564 -rw-------   1 madams   madams    8769144 Feb  4 00:47 ./2#hHY+/KYG#p+/R#k1Z#h/#j#f#l#fO/#vF#pCZ/08
654485 4248 -rw-------   1 madams   madams    4349848 Feb  4 00:48 ./_+6#tW/0DN#l#p/#r#yP3#z/1#bA#t#h/X#r#y#g3/N#o

There are 2984 lines of that when finding files 4000k or larger.

Following that trail of breadcrumbs leads to:

Code:

]# pwd
/mnt/backup/00#nGG/#gXG#qS/#f70#zB/#l#r#x2K/G#wUSM
[root@spike G#wUSM]# ll
total 5276
-rw------- 1 madams madams 5399848 Feb  4 00:46 #v#k
-rw------- 1 madams madams       0 Feb  4 00:46 #v#k.refcount.1

Attempting to detect file type mostly fails:

Code:

# file #v#k
Usage: file [-bchikLlNnprsvz0] [--apple] [--mime-encoding] [--mime-type]
            [-e testname] [-F separator] [-f namefile] [-m magicfiles] file ...
       file -C [-m magicfiles]
       file [--help]

Occasionally these files turn out to be "octet-streams" which could indicate the graphic images I'm looking for.

Is there some way to search files for a file type (given that there are no extensions on any of these files) to locate graphic files (png, jpg, etc)?

Just grasping for straws here.

Mark

syg00 · 02-05-2012, 05:49 PM

Enclose the filename in quotes. Or you could stick a backslash before each # (or other special) character ....

I was going to post yesterday, but reckoned you had enough pain, so didn't.
My thoughts were:
- if this was a backup, your daughter still has the original disk .... right ?.
- if you have corrupted directory and file names, what gives you confidence the files themselves are not corrupted ?. It's all just a data stream being written to the same (USB) disk. I am always very reticent to rely on any disk that has had an "incident" - but I'm anal about backups.

H_TeXMeX_H · 02-06-2012, 06:04 AM

From the file names, it looks to me like the FAT was corrupted. Testdisk may be able to fix it.

I would use foremost to carve files from it, you can carve only image files if that is what you need.

mark9117 · 02-06-2012, 11:52 AM

Quote:

Originally Posted by syg00

- if this was a backup, your daughter still has the original disk .... right ?.

Actually, no. When this happened she got gunshy about using the disk and by the time I could get her to regroup to make a decision about just wiping it and starting over, her laptop was stolen. Timing is everything and this has taken place over the past 2 years. We are separated by 900 miles and trying to do it over the internet with my bandwidth is not practical.

The laptop was replaced and she copied everything off of the usb hard drive to the new laptop in an effort to preserve it and let me try to do the recovery. Now, the laptop that she copied those files to (A Dell Studio 1533 in case you're wondering) has failed and I have the hard drive from it sitting in a usb enclosure attached to my desktop.

We may not be able to get these images back, but I'd like to give it a serious and committed try before I give up.

Thanks for the attention here. I do appreciate it.

Mark

mark9117 · 02-06-2012, 11:54 AM

Quote:

Originally Posted by H_TeXMeX_H

From the file names, it looks to me like the FAT was corrupted. Testdisk may be able to fix it.

I would use foremost to carve files from it, you can carve only image files if that is what you need.

Thanks for the info TeXMeX. I am familiar with Testdisck but have not heard of Foremost. I will look into it. I don't think we can reconstruct the fat at this point unless I can get my hands on the original usb hard drive. The data is still there, but I'm not sure how intact it is and finding it among the cruft if proving to be difficult.

At any rate, I'll check out foremost and see what I can do.

Thanks again.

Mark

syg00 · 02-06-2012, 07:52 PM

Quote:

Originally Posted by mark9117

We may not be able to get these images back, but I'd like to give it a serious and committed try before I give up.

That's fair enough. Did you try my suggestion for the "file" command ?. Given that you have a list of filenames, you could run them through a loop. Then you can check for the images. Maybe something like ...

Code:

find . -size +4000k | while read name ; do  file $(basename $name) ; done

mark9117 · 02-07-2012, 09:01 AM

Quote:

Originally Posted by syg00

That's fair enough. Did you try my suggestion for the "file" command ?. Given that you have a list of filenames, you could run them through a loop. Then you can check for the images. Maybe something like ...

Code:

find . -size +4000k | while read name ; do  file $(basename $name) ; done

Well, I ran "foremost -T -v -o /mnt/spare/recovered -i image.dd" for about the last 21 hours and have nothing to show for it. Why not try a "find" command.

Umm, should there be some more quotes in there? I'm getting lots of this:

Code:

#hI: ERROR: cannot open `#hI' (No such file or directory)
#w#o: ERROR: cannot open `#w#o' (No such file or directory)
J#w: ERROR: cannot open `J#w' (No such file or directory)
X#c: ERROR: cannot open `X#c' (No such file or directory)
T#c: ERROR: cannot open `T#c' (No such file or directory)
8M: ERROR: cannot open `8M' (No such file or directory)
48: ERROR: cannot open `48' (No such file or directory)

I don't know.

Mark

H_TeXMeX_H · 02-07-2012, 09:14 AM

Try this instead:

Code:

foremost -T -k 500 -t jpg,gif,png,bmp -i image.dd -o /mnt/spare/recovered

syg00 · 02-07-2012, 08:51 PM

Quote:

Originally Posted by mark9117

Umm, should there be some more quotes in there? I'm getting lots of this:

My fault - too many assumptions. You're getting that because I stripped the directory structure off the filename (because of the leading "."), and you're recursing down. Replace the "." in the find command with a real path, and lose the "basename" call. Say (also added writing output to a file)

Code:

find ~/tmp/backup/ -size +4000k | while read name ; do  file $name >> list.saveit ; done

mark9117 · 02-08-2012, 09:09 AM

Quote:

Originally Posted by syg00

My fault - too many assumptions. You're getting that because I stripped the directory structure off the filename (because of the leading "."), and you're recursing down. Replace the "." in the find command with a real path, and lose the "basename" call. Say (also added writing output to a file)

Code:

find ~/tmp/backup/ -size +4000k | while read name ; do  file $name >> list.saveit ; done

Okay, that did get me a list of directories with "data" files in them. So far, it's data that I can't seem to do anything with. It just identifies as "octet-stream" and I can't cat it out or open it with with anything.

I appreciate the help with this and I'll keep kicking it around for a while.

Thanks again.

Mark

H_TeXMeX_H · 02-08-2012, 09:54 AM

I think the files you see aren't real files, they are artifacts cause by FAT corruption. I've gotten this before accidentally when I wiped the FAT of a USB stick with random data. The only way to recover any data is to fix the FAT or carve data from the disk.

mark9117 · 02-08-2012, 01:42 PM

Quote:

Originally Posted by H_TeXMeX_H

I think the files you see aren't real files, they are artifacts cause by FAT corruption. I've gotten this before accidentally when I wiped the FAT of a USB stick with random data. The only way to recover any data is to fix the FAT or carve data from the disk.

Okay, here's the deal on that. I am working on a second generation copy of this data. The original set is on a usb hd in Las Vegas, Nevada. She was supposed to bring it to me when she was down last month and she forgot it. I am working on the copy she made on her (now defunct) Dell laptop. I have removed that hard drive to a usb enclosure and have copied the files to my desktop.

I'm going to call this one good until I have the initial usb hard drive in hand.

Thanks for the assist on this. It's been most educational.

Later.

Mark

syg00 · 02-08-2012, 05:02 PM

If you are going to have to resort to data carving (and I agree it's looking like it) try to mount the drive internally, or get a ESATA card to allow the I/O to run at a decent speed. USB could (will) take forever.