Status info freeze and photorec.se2 not updated

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 https://www.cgsecurity.org/testdisk.pdf
Post Reply
Message
Author
abiyi
Posts: 8
Joined: 12 Oct 2018, 18:50

Status info freeze and photorec.se2 not updated

#1 Post by abiyi » 31 Oct 2018, 23:48

I've run PhotoRec many times but now seems like is doing it fine recovering my files from a Samsung Story Station 2TB, but some reason the status it got freezed since a couple of days with the next info:

Code: Select all

Reading sector   47400447/3907029168, 191211 files found
Elapsed time 23h23m58s - Estimated time to completion 1905h19m23
I only can see the used blocks in the destination device (four hard disks in a LVM2 volume) and inode folder recovered.

Code: Select all

root@sysresccd /root % df                    
Filesystem                          1K-blocks       Used Available Use% Mounted on
udev                                    10240        168     10072   2% /dev
/dev/sdi1                             3958784     560528   3398256  15% /livemnt/boot
/dev/loop0                             493312     493312         0 100% /livemnt/squashfs
tmpfs                                 7833192     199524   7633668   3% /livemnt/memory
none                                  7833192     199524   7633668   3% /
tmpfs                                  524288         24    524264   1% /livemnt/tftpmem
none                                   524288         24    524264   1% /tftpboot
tmpfs                                 1566640       1116   1565524   1% /run
shm                                   7833192      20580   7812612   1% /dev/shm
tmpfs                                 7833192       2864   7830328   1% /tmp
none                                  7833192          4   7833188   1% /run/user/0
/dev/mapper/samsung--restored-data 2112729008 2104406276         0 100% /var/restored-data
/dev/sda5                          1425622012 1272784504 152837508  90% /media/windows
So, I don't know how much it gonna take for PhotoRec to finish the job.

What it seems worst is that the photorec.se2 file hasn't been updated since Octuber 28 at 18:34 and photorec.log hasn't been written in the last hours, in case of electrical failure (as happen the last weekend) all the recovery process will be gone and it should be executed from the beginning.

The probably cause is a damage sector in one of the hard disks, reported in /var/log/messages:

Code: Select all

Oct 31 18:34:34 sysresccd kernel: ata8: EH complete
Oct 31 18:34:37 sysresccd kernel: ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
Oct 31 18:34:37 sysresccd kernel: ata8.00: irq_stat 0x40000001
Oct 31 18:34:37 sysresccd kernel: ata8.00: failed command: READ DMA EXT
Oct 31 18:34:37 sysresccd kernel: ata8.00: cmd 25/00:08:00:30:b7/00:00:11:00:00/e0 tag 14 dma 4096 in\x0a         res 51/40:00:00:30:b7/00:00:11:00:00/e0 Emask 0x9 (media error)
Oct 31 18:34:37 sysresccd kernel: ata8.00: status: { DRDY ERR }
Oct 31 18:34:37 sysresccd kernel: ata8.00: error: { UNC }
Oct 31 18:34:37 sysresccd kernel: ata8.00: configured for UDMA/133
Oct 31 18:34:37 sysresccd kernel: sd 7:0:0:0: [sdc] tag#14 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 31 18:34:37 sysresccd kernel: sd 7:0:0:0: [sdc] tag#14 Sense Key : Medium Error [current] 
Oct 31 18:34:37 sysresccd kernel: sd 7:0:0:0: [sdc] tag#14 Add. Sense: Unrecovered read error - auto reallocate failed
Oct 31 18:34:37 sysresccd kernel: sd 7:0:0:0: [sdc] tag#14 CDB: Read(10) 28 00 11 b7 30 00 00 00 08 00
Oct 31 18:34:37 sysresccd kernel: print_req_error: I/O error, dev sdc, sector 297218048
Oct 31 18:34:37 sysresccd kernel: ata8: EH complete
Oct 31 18:34:37 sysresccd kernel: EXT4-fs error (device dm-0): ext4_wait_block_bitmap:524: comm kworker/u8:0: Cannot read block bitmap - block_group = 10832, block_bitmap = 354942976
So, sum up: how can I know how much is gonna take to PhotoRec to get the job done? and another not least important question: what can I do if the LVM2 volume gets full before the recovery process finish? does photorec.se2 will work to PhotoRec in order to resume...?

Sponsored links

abiyi
Posts: 8
Joined: 12 Oct 2018, 18:50

Re: Status info freeze and photorec.se2 not updated

#2 Post by abiyi » 01 Nov 2018, 17:08

After moving up about 145 GB of MKV files away from the LVM2 volume, the PhotoRec reading status has changed to this:

Code: Select all

Reading sector   47441087/3907029168, 198930 files found
Elapsed time 79h58m59s - Estimated time to completion 6507h03m09
As far as I can understand, the sector reading is far to finish, and the estimated time to completion has triplicated... and seems like the LVM2 volume is running out of space...

Code: Select all

root@sysresccd /var/restored-data/recup_dir.1 % df /dev/mapper/samsung--restored-data                                      
Filesystem                          1K-blocks       Used Available Use% Mounted on
/dev/mapper/samsung--restored-data 2112729008 2103722720         0 100% /var/restored-data
root@sysresccd /var/restored-data/recup_dir.1 % 

User avatar
cgrenier
Site Admin
Posts: 4506
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: Status info freeze and photorec.se2 not updated

#3 Post by cgrenier » 02 Nov 2018, 06:47

As they are bad sectors, you should clone the disk to a new empty one using ddrescue, see https://www.cgsecurity.org/testdisk.pdf
Once it's done, remove the original disk and try again PhotoRec on the clone.

abiyi
Posts: 8
Joined: 12 Oct 2018, 18:50

Re: Status info freeze and photorec.se2 not updated

#4 Post by abiyi » 02 Nov 2018, 15:54

Just to clarify the situation: the disk with bad sectors is NOT the source device, the disk reported with bad sectors is (as far as I know) just one of the destiny devices (mounted in a LVM2 volume), so once ddrescue finish up the image copy, all the recovered data should go back to the source device (which is physically perfect).

The thing is having 2 terabytes of free (and healthy) disk space to transfer the data... now I think is not case and suddenly PhotoRec will stop reporting something like "not enough free space to restore files".

My question now (after four days): is it worth to stop the PhotoRec recovery process, delete all the recovered data and start all over again with ddrescue...?

User avatar
cgrenier
Site Admin
Posts: 4506
Joined: 18 Feb 2012, 15:08
Location: Le Perreux Sur Marne, France
Contact:

Re: Status info freeze and photorec.se2 not updated

#5 Post by cgrenier » 04 Nov 2018, 09:06

"df /var/restored-data" has show that no free space was available on the destination.
When PhotoRec stops because of missing space, it deletes the files it was recovering, so there may be some free space.
It's recommended to use a destination at least as large as the source.

abiyi
Posts: 8
Joined: 12 Oct 2018, 18:50

Re: Status info freeze and photorec.se2 not updated

#6 Post by abiyi » 04 Nov 2018, 14:05

Interesting behavior, the destination device (a LVM2 volume) has a little more space than the source device (it's supposed to be 2 Terabytes, but GParted reported 1.8 Terabytes, while the LVM2 volume got 2.0 Terabytes), but considering the damage sectors in one of the destination disks, is most than probably than the destination size is lower than what is reported.

I've haven't notice any automatic deletion (the first folder recovered it's still there), the only deletion has been because of me (PhotoRec has recovered A LOT of files I deleted, on purpose, many weeks ago and others I should deleted but I just forgot it), but one thing I'm wondering is why there's lot of duplicate files (same name, same size) in different folders (obviously with different inode numbers). I'm using fdupes for that matter but is gonna take days to read the whole volume and give a report.

abiyi
Posts: 8
Joined: 12 Oct 2018, 18:50

Re: Status info freeze and photorec.se2 not updated

#7 Post by abiyi » 02 Dec 2018, 23:31

After many tries I think finally recovered all my files: I changed one of the hard disk with many bad sectors, replaced it with another one with the same size and resized one partition of another one (out of four disks in the LVM2 partition) in order to obtain a lot of free GB... but I noticed some things (and seems like many others) still don't get about PhotoRec: after the scanning and recovering, why there's not recovered files report?

This all I get (after days of waiting anything from PhotoRec):

Code: Select all

PhotoRec 7.1-WIP, Data Recovery Utility, March 2018
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org

Disk /dev/sdj - 2000 GB / 1863 GiB (RO) - Samsung STORY Station
     Partition                  Start        End    Size in sectors
   P Unknown                  0   0  1 243201  80 63 3907029168















  Stop  
I'm aware that I only have to press Enter to Stop it, but it doesn't work anyway... the only way to really stop it is pressing Control-C or execting killall photorec in the console. Why can't I stop the

As the photorec.ses was created I can resume the session, but after one day of scanning it gets to the same screen without recovered files report, and more important yet: no more recovered files.

According the last lines of photorec.ses, PhotoRec hit the recovered device last sector:

Code: Select all

3892120447-3892122494
3892133311-3893130366
3893139135-3893140350
3893154495-3893808702
3896588095-3899966526
3899994943-3900009918
3900027647-3900081662
3900098943-3900114750
3900130559-3900165822
3900202879-3905138750
3905651839-3906797246
3906867839-3906921534
3906974655-3907029182
(Why the last sector reported is greater than the size in sectors of the device is something beyond of my understanding).

photorec.log report the very same thing (beside the SIGNIT detection)

Code: Select all

3892120447-3892122494: (null)
3892133311-3893130366: (null)
3893139135-3893140350: (null)
3893154495-3893808702: (null)
3896588095-3899966526: (null)
3899994943-3900009918: (null)
3900027647-3900081662: (null)
3900098943-3900114750: (null)
3900130559-3900165822: (null)
3900202879-3905138750: (null)
3905651839-3906797246: (null)
3906867839-3906921534: (null)
3906974655-3907029182: (null)
784776576 sectors contain unknown data, 0 invalid files found and rejected.
SIGINT detected! PhotoRec has been killed.
The same message appears when the application has been killed, run again and the session is restored.

Interesting strange fact: the size of the recovered files is greater than the size of the device. From a 2.0 GB external disk (1.8 TB for user files) PhotoRec has recovered 2.6 TB of files, and it must have been a lot more, because in the session.log there's a lot of "Can't create file" messages, after many "fat_copy_file: no space left on destination." messages.

By the way, this is the disk free report of the LVM2 partion used to restore the files:

Code: Select all

root@sysresccd /root % df /media/samsung
Filesystem                          1K-blocks       Used Available Use% Mounted on
/dev/mapper/storystation-recovered 2810276216 2788045368         0 100% /media/samsung
(Even if the percentage of used space is 100%, the count of block numbers is less than the total count of blocks).

I noticed that PhotoRec is not only restoring files I have deleted (to have more free space on disk), it has been restoring a bunch of files in different inode folders, all of them with the same size. I'm not sure if that behaviour is caused by the lack of free space in the destiny device (so, once PhotoRec notice there's enough free space, restore the files with another inode folder name).

The final question is: Can I consider the recovering process done...?

Post Reply

Who is online

Users browsing this forum: No registered users and 4 guests