Data recovery solutions

bolshevik · 2012-04-18 15:50:33

My job is to work as a computer tech in an electronics retail store. As you'd expect, most of our work is done on Windoze and Mac machines, but we do have a linux box. It was running Linux Mint because it's easy to use for everyone and requires no hand-holding, and not all my colleagues are familiar with linux. Yesterday at the end of our work shift, another tech wanted to wipe a HDD clean for a client and tried to use Darik's Boot and Nuke on it. He did it on the linux box, and accidentally hit the linux HDD instead of the one he connected via USB...

So I was looking through the arch wiki for a solution. Note that he only allowed Boot and Nuke to go through 0.16% of the disk before realizing his mistake, so there has to be some recoverable data on it. It contained critical data belonging to some of our clients who had us back it up before sending their computers in for repair, so it MUST be recovered. Before leaving I had time to connect the HDD to my laptop (which runs arch) and through GParted I saw that the disk was detected but contained no partitions, with all it's space being "unallocated". According to the wiki, TestDisk is primarily designed to help recover lost partitions and/or make non-booting disks bootable again when these symptoms are caused by faulty software, certain types of viruses or human error (such as accidentally deleting a Partition Table). This seems to be pretty much what I need. My next work shift is tomorrow, so if there are any other tools you guys could recommend in the meantime I'd be happy to try them as well. Has anyone ever had a similar problem before?

Thank you for your help.

alphaniner · 2012-04-18 17:02:34

My one suggestion from experience is to use read-only methods of recovery and/or make an image of the disk before attempting recovery (dd from the disk to an image file on another disk). In other words, try to avoid any writing to the disk until after the data is recovered, preferably copied onto another medium.

OTOH, it may be that you just need to rebuild the partition table, and writing a new table won't risk data loss*. If the partition containing the data didn't start at the beginning of the HDD, the data is probably completely intact**.

* After writing a table, mount the 'recovered' partitions ro until you are 10^9% sure everything is intact.
* This is assuming B&N works sequentially from the beginning of the drive to the end.

Gcool · 2012-04-18 17:05:46

Have a look at this wiki page.

I personally have had fairly good experiences with foremost.

bolshevik · 2012-04-19 21:40:09

Thanks. I'm cloning the disk with dd at the moment. Not sure how long this will take... I'll be attempting recovery with testdisk afterwards.

parintachin · 2012-04-19 23:14:55

just wanted to mention that at least photorec which is a part of teskdisk can recover files of ext3 dispite the manpage only saying ext2, haven't tried on ext4 tho
good luck

bolshevik · 2012-04-23 07:44:30

After several attempts with testdisk I still haven't managed to salvage anything. I can find the ext4 partition i'm looking for, but it says "Filesystem is damaged" when I try to list the files it contains. Next time I'll try photorec, but I'm not particularly hopeful.

alphaniner · 2012-04-23 13:16:30

If you're sure it's the partition you're looking for, why not rebuild the partition map on the image and fsck it?

bolshevik · 2012-04-23 19:14:10

Don't have access to the hardware right now, so I can't test anything, but so far I have been unable to use the "write partition table" function in testdisk, it throws an error every time. How would I go about rebuilding it if testdisk fails? I thought about fsck'ing it, but I need to restore the partitions first.

alphaniner · 2012-04-23 19:16:47

I assumed testdisk would give you the information necessary (sector start/end) to manually set up the partitions with fdisk.

bolshevik · 2012-04-24 15:10:45

alphaniner wrote:

I assumed testdisk would give you the information necessary (sector start/end) to manually set up the partitions with fdisk.

Actually, it does. I manually wrote the partition table using fdisk, with the sector start/end values gathered from testdisk. When trying to fsck it, I get the following error :

The superblock could not be read or does not describe a correct ext2
filesystem.  If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>

Running e2fsck throws up the exact same error. I'm not quite sure where to go from here. I'm starting to think this crap may be impossible to recover.

alphaniner · 2012-04-24 15:26:45

Did you just copy the e2fsck command verbatim, or did you give it a valid backup superblock?

To get a list of backup superblocks, use the command originally used to format the partition plus the -n flag. For example:

mkfs.ext4 -n <device>

Don't forget or fat-finger that -n flag, it tells the command to 'pretend' and not actually write anything to the disk.

Arch Linux

#1 2012-04-18 15:50:33

Data recovery solutions

#2 2012-04-18 17:02:34

Re: Data recovery solutions

#3 2012-04-18 17:05:46

Re: Data recovery solutions

#4 2012-04-19 21:40:09

Re: Data recovery solutions

#5 2012-04-19 23:14:55

Re: Data recovery solutions

#6 2012-04-23 07:44:30

Re: Data recovery solutions

#7 2012-04-23 13:16:30

Re: Data recovery solutions

#8 2012-04-23 19:14:10

Re: Data recovery solutions

#9 2012-04-23 19:16:47

Re: Data recovery solutions

#10 2012-04-24 15:10:45

Re: Data recovery solutions

#11 2012-04-24 15:26:45

Re: Data recovery solutions

Board footer