cgsecurity.org

Hello,

I am using PhotoRec 7.1-WIP, to recover files from a 1TB Western Digital SATA HDD. I booted off of a LiveCD (https://en.altlinux.org/Rescue), and I am using a Dell Optiplex 780. It is currently on Pass 1, Reading sector 121555852/1944492032, 9170 files found. It has been running for 62 days, and says it has 20000 hours remaining (but it is going down). So, just over 2.5 years to go? Ha. This is taking too long, correct? Should I kill it? I mean, it does look like it is working, but it is taking FOREVER... But beggars can't be choosers! Just want to know if I am really going to be waiting another 2 years.

Thanks,


P.S. - So, I just noticed that it went backwards... now it is on Reading sector 93006667/1944492032. That is one digit less than before. So, there must be something wrong here, correct? Thanks everyone...

Are the recovered files valid files ?
The recovery may be very slow if the source disk contains bad sectors.
Sometimes to complete a fragmented file PhotoRec goes backward after recovering a new file.
It's possible to avoid this problem by stopping PhotoRec and manually editing the photorec.ses file (ie. using vim, do not forget to backup the file) to remove old sector ranges. After that, resume the recovery.

I don't know a good way to check and see if the files are valid, without first stopping PhotoRec. I guess I could resume it afterward, yes?

We created a backup of the disk prior, using dd. It is stored in an .img file. Should I try mounting this, and running PhotoRec on that instead? The .img file is stored on another HDD.

Thanks,

P.S. - Now it says it has 26351 hours remaining, which is 3 years. It keeps changing wildly. This disk must be in really bad shape.

So, I stopped the recovery and checked the files, and they seem to be good/valid files. Good JPGs, MPGs, and some PDFs. However, it is nowhere near complete. As you say, the drive must be in really bad shape. I will attempt a few other things, including editing the photorec.ses file. Any advice for editing the file properly? Or is it all in the user guide...

Thanks,

It's better to use ddrescue than dd to create an image of a disk. By default dd stops at the first bad sector.
If the disk was containing bad sectors, it's better to work on the disk image than from the source disk.
The current location will be listed at the end of the second line. Remove all old sector range, this way PhotoRec will not jump backward.
You can use vim to edit the photorec.ses file.

cgrenier wrote: ↑06 Dec 2017, 07:28 The current location will be listed at the end of the second line. Remove all old sector range, this way PhotoRec will not jump backward.

What do you mean by this? I thought it is okay for PhotoRec to jump backward when it finds a new file.

I am recovering data from QNAP TS412 6TB Raid 5 with the latest version of Photorec 7. I am very pleased that Photorec is recovering files despite QNAP Technical Support maintaining that they were irrecoverable! When I commenced Photorec, I left all the file recovery options selected and chose to scan only blank areas of the NAS (the areas that were deleted by accident from the NAS after file system errors). The files that were deleted were exclusively photos and video files.

I have had Photorec running for about a week on and off but it still says I have another 1200 hours to go and this figure is growing all the time!

Should I abort this scan and restart unchecking all the file types at Photorec startup (none as I recall were photo/video) and is there any way of scanning ONLY for photo/video files. Obviously I don't want to wait another 50 days if I'm going about this the wrong way! Any help/advice to speed this recovery up would be greatly appreciated!

Try latest 7.1-WIP instead of 7.0. In FileOpts, you can disable file format like txt, tx?, ecryptfs but disabling other file families will not speedup the recovery

Thanks very much for your reply! I have had PhotoRec running for 400 hours now and it is slowly but surely lifting off deleted files from my NAS. Unfortunately, whilst the original Estimated Time to Completion was about 1200 hours which was ok (sort of) the figure climbed up to 15000 and is now coming down again and is currently 11000 which is 1.25 years! Should I stick with this or is the figure likely to come back down to 1200 which is a doable 50 days? Interestingly, a local data recovery firm reckon they can get this back within 48 hours but want $1000 USD!