Using PhotoRec to recover lost data
Forum rules
When asking for technical support:
- Search for posts on the same topic before posting a new question.
- Give clear, specific information in the title of your post.
- Include as many details as you can, MOST POSTS WILL GET ONLY ONE OR TWO ANSWERS.
- Post a follow up with a "Thank you" or "This worked!"
- When you learn something, use that knowledge to HELP ANOTHER USER LATER.
Before posting, please read
Posts: 1
Joined: 27 Jun 2012, 08:36


#1 Post by stefan112 »

Here is how I used photorec to destroy what was left of my data. I post this confession that others may learn.

I attempted to upgrade the OS of a linux machine. Unfortunately, the installation procedure didn't upgrade the OS,
but rather rebuilt the entire disk. The incremental backups were found to have failed leaving the last full backup
and whatever could be got from the overwritten disk. Darn.

I bought a new, larger disk drive and installed a new linux OS. Significantly, I chose the same host name as the machine had before, as I was trying to rebuild the server as it had been.

Installed testdisk and photorec.

Halted the machine, attached the overwritten disk drive, rebooted.

Observed the mounted disks with df and mount to verify that the new, larger disk was mounted.

Started testdisk to try to recover the overwritten lvm partition.

Gave up, started photorec to at least try to get back some of the files.

Started a disk scan, let that run overnight.

Found, to my surprise, in the morning, that the scan had stopped because the hard drive was full.

Upon investigation, I found the scan operation had written many thousands of files to the older, smaller
disk, no doubt overwriting much of the data that might have been recovered.

Since this compounded disaster, I have learned more about how the linux lvm works. Basically, you do not
want two volume groups with the same name, it confuses the lvm completely. Unfortunately, with my distro,
the vg's are named using the hostname given at install time, making it easy in such a case to get into trouble.
I believe the kernel was itself confused about which disk drive it had mounted. I might have detected the
problem using the vg tools if I had been smarter, however.

Photorec wrote data when I thought it was doing a read-only scan. Had I understood it was going to write,
I would have been more careful about the drives. Obviously my inexperience with this otherwise
remarkable utility was a factor here.

In my opinion, photorec should take a command flag, say -w, that authorizes write operations, and should be
read-only by default. This would more clearly distinguish investigation from recovery.

If would also be nice if it could specifically look for multiple drive units with the same logical volume names
and emit a warning, though I don't know if this is possible. If, as the man page states, photorec will never
write to the unit being recovered, then it was itself confused, no doubt by the lvm, whose job it is to
trick higher level components about where exactly data lies.