Benefits to running photorec multiple times?

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
apb1963
Posts: 1
Joined: 04 Oct 2018, 19:42

Benefits to running photorec multiple times?

#1 Post by apb1963 » 04 Oct 2018, 21:13

<r>Hello and thanks in advance for any help.<br/>
<br/>
I'm running ubuntu 16.04 with ext4 file system and was trying to transfer my files from one disk to another using rsync. It transferred the files but failed to transfer some hidden files, so I rewrote the expression for just hidden files and ran it again. This time it transferred the hidden files - and<U><s></s><B><s></s> deleted all the other files it had already transferred to the target 3TB disk<e></e></B><e></e></U>. Since I had told it to delete source files it deleted the original files too. I tested several times with a dry run and test files to confirm files were transferring correctly before adding the delete source files flag; it never said it was going to delete files during the dry run. <br/>
<br/>
And so that brings us to photorec. First, I"m not sure of the difference between undeleting a file such as testdisk does and recovering a flie but I opted for photorec.<br/>
<br/>
I ran it on the original partition and have posted the (abridged) log below. However, here are my questions along with additional info:<br/>
<br/>
I ran it on /dev/sdc3, i.e. "/data". After several days I came to realize that there was actually a second copy of the deleted files on the target 3TB drive, which is actively running a freshly installed ubuntu 16.04 (rsync was run after fresh installation obviously). <br/>
<br/>
1) The log contains "377648904 sectors contains unknown data, 46371 invalid files found and rejected." That's a lot of unknown data and invalid files. Any comments/info/knowledge on what that's all about? Keep in mind, this is a partition on a second disk, normally mounted on the root (/), and after the rsync nothing else wrote to that partition that I know about.<br/>
<br/>
2) Is there any benefit to running photorec multiple times? Maybe using alternative superblocks? I wouldn't think so, but if I knew for sure I wouldn't ask.<br/>
<br/>
3) Is there any benefit to attempting to recover the files from the target system? While the target has been written to fairly extensively, there very well could be files still recoverable that are different from the ones recovered from the source disk. Right? So how to deal with that? Recover to a separate directory and then run some other tool to compare directories? Better ideas? Suggestions for tools to use?<br/>
<br/>
Thank you most kindly in advance! Log follows as mentioned above.<br/>
<br/>
<br/>
PhotoRec 7.0, Data Recovery Utility, April 2015<br/>
Christophe GRENIER <<EMAIL email="grenier@cgsecurity.org">grenier@cgsecurity.org</EMAIL>><br/>
<URL url="http://www.cgsecurity.org">http://www.cgsecurity.org</URL><br/>
OS: Linux, kernel 4.15.0-34-generic (#37~16.04.1-Ubuntu SMP Tue Aug 28 10:44:06 UTC 2018) x86_64<br/>
Compiler: GCC 5.3<br/>
ext2fs lib: 1.42.13, ntfs lib: libntfs-3g, ewf lib: none, libjpeg: libjpeg-turbo-1.4.2, curses lib: ncurses 6.0<br/>
/dev/sda: LBA, HPA, LBA48, DCO support<br/>
/dev/sda: size 488281250 sectors<br/>
/dev/sda: user_max 488281250 sectors<br/>
/dev/sda: native_max 488281250 sectors<br/>
/dev/sdb: LBA, HPA, LBA48, DCO support<br/>
/dev/sdb: size 5860533168 sectors<br/>
/dev/sdb: user_max 5860533168 sectors<br/>
/dev/sdb: native_max 5860533168 sectors<br/>
/dev/sdc: LBA, LBA48, DCO support<br/>
/dev/sdc: size 976773168 sectors<br/>
/dev/sdc: user_max 976773168 sectors<br/>
/dev/sdc: dco 976773168 sectors<br/>
Warning: can't get size for Disk /dev/mapper/control - 0 B - 0 sectors (RO), sector size=512<br/>
Hard disk list<br/>
Disk /dev/sda - 250 GB / 232 GiB - CHS 30394 255 63 (RO), sector size=512 - Hitachi HDT721025SLA380, S/N:STABD7MT2AX9WF, FW:STBOA38E<br/>
Disk /dev/sdb - 3000 GB / 2794 GiB - CHS 364801 255 63 (RO), sector size=512 - WDC WD30EZRZ-00GXCB0, S/N:WD-WCC7K6CFZY8J, FW:80.00A80<br/>
Disk /dev/sdc - 500 GB / 465 GiB - CHS 60801 255 63 (RO), sector size=512 - WDC WD5000AAKS-65YGA0, S/N:WD-WCAS83962651, FW:12.01C02<br/>
<br/>
Can't open photorec.ses file: No such file or directory<br/>
Partition table type (auto): Intel<br/>
Geometry from i386 MBR: head=255 sector=63<br/>
No partition 0 0 1 60801 80 63 976773168 [Whole disk]<br/>
1 * Linux 0 32 33 7661 5 34 123072266 [ubuntu 16]<br/>
ext4 blocksize=4096 Large_file Sparse_SB Recover, 63 GB / 58 GiB<br/>
2 P Linux 7661 9 29 15727 119 8 129587200 [home_ubuntu14]<br/>
ext4 blocksize=4096 Large_file Sparse_SB Recover, 66 GB / 61 GiB<br/>
<B><s></s> 3 P Linux 15727 119 9 60801 80 15 724111360 [data]<e></e></B><br/>
ext4 blocksize=4096 Large_file Sparse_SB Recover, 370 GB / 345 GiB<br/>
ext2/ext3/ext4 mode activated.<br/>
623 first-level signatures enabled<br/>
<br/>
Analyse<br/>
3 P Linux 15727 119 9 60801 80 15 724111360 [data]<br/>
ext4 blocksize=4096 Large_file Sparse_SB Recover, 370 GB / 345 GiB<br/>
Pass 0 (blocksize=512) STATUS_FIND_OFFSET<br/>
blocksize=512, offset=0<br/>
Elapsed time 0h00m02s<br/>
Pass 1 (blocksize=512) STATUS_EXT2_ON<br/>
/home/apb/recoverd/recup_dir.1/f0000002.ext 252661762-252661762<br/>
<br/>
[..snip...]<br/>
<br/>
/home/apb/recoverd/recup_dir.3794/f723955688.txt 976617448-976617545<br/>
/home/apb/recoverd/recup_dir.3794/f723958258.mbox 976620018-976624712<br/>
/home/apb/recoverd/recup_dir.3794/f723963531.mbox 976625291-976631925<br/>
/home/apb/recoverd/recup_dir.3794/f723970407.mbox 976632167-976728808<br/>
/home/apb/recoverd/recup_dir.3794/f724070627.mbox 976732387-976768178<br/>
/home/apb/recoverd/recup_dir.3794/f724107264.gz 976769024-976771526 (976771527-976771527) 976771528-976773119<br/>
Elapsed time 3h02m21s<br/>
Pass 1 +1896853 files<br/>
txt: 1668437/1707900 recovered<br/>
png: 58721/59609 recovered<br/>
tx?: 40687/40736 recovered<br/>
jpg: 36702/39520 recovered<br/>
elf: 17426/18164 recovered<br/>
mpg: 16943/16943 recovered<br/>
gz: 16369/16369 recovered<br/>
exe: 9213/9847 recovered<br/>
gif: 6072/6311 recovered<br/>
tz: 3524/3524 recovered<br/>
doc: 3183/3921 recovered<br/>
class: 3079/3079 recovered<br/>
zip: 2971/3214 recovered<br/>
pyc: 2689/2689 recovered<br/>
tar: 2167/2167 recovered<br/>
pdf: 1848/1925 recovered<br/>
xz: 1040/1170 recovered<br/>
MYI: 700/700 recovered<br/>
chm: 566/586 recovered<br/>
ttf: 493/498 recovered<br/>
mp3: 441/450 recovered<br/>
riff: 395/463 recovered<br/>
a: 364/364 recovered<br/>
sqlite: 356/356 recovered<br/>
ps: 317/317 recovered<br/>
cab: 303/315 recovered<br/>
bmp: 298/306 recovered<br/>
cp_: 239/239 recovered<br/>
woff: 207/207 recovered<br/>
bz2: 172/172 recovered<br/>
swf: 127/140 recovered<br/>
lnk: 120/187 recovered<br/>
tif: 118/141 recovered<br/>
reg: 87/87 recovered<br/>
skp: 56/56 recovered<br/>
ico: 53/58 recovered<br/>
ogg: 53/53 recovered<br/>
apple: 40/40 recovered<br/>
dat: 36/37 recovered<br/>
icc: 24/24 recovered<br/>
db: 23/23 recovered<br/>
edb: 17/17 recovered<br/>
pnm: 16/16 recovered<br/>
mov: 15/100 recovered<br/>
xcf: 14/14 recovered<br/>
xpt: 14/14 recovered<br/>
asf: 13/18 recovered<br/>
au: 11/11 recovered<br/>
rpm: 9/9 recovered<br/>
evt: 7/7 recovered<br/>
mdb: 7/7 recovered<br/>
emf: 6/7 recovered<br/>
kdbx: 6/6 recovered<br/>
pfx: 6/6 recovered<br/>
flac: 4/4 recovered<br/>
plist: 4/4 recovered<br/>
pst: 4/4 recovered<br/>
vdi: 4/4 recovered<br/>
gpg: 3/4 recovered<br/>
mid: 3/4 recovered<br/>
mkv: 3/25 recovered<br/>
pap: 3/3 recovered<br/>
pcap: 3/3 recovered<br/>
pcx: 3/3 recovered<br/>
rar: 3/3 recovered<br/>
wks: 3/3 recovered<br/>
7z: 2/3 recovered<br/>
cdt: 2/2 recovered<br/>
mdf: 2/2 recovered<br/>
iso: 1/5 recovered<br/>
psd: 1/1 recovered<br/>
rdc: 1/1 recovered<br/>
res: 1/1 recovered<br/>
rm: 1/1 recovered<br/>
torrent: 1/1 recovered<br/>
vmdk: 1/1 recovered<br/>
dad: 0/2 recovered<br/>
veg: 0/1 recovered<br/>
Total: 1896853 files found<br/>
<br/>
377648904 sectors contains unknown data, 46371 invalid files found and rejected.<br/>
New options :<br/>
Paranoid : Yes<br/>
Brute force : No<br/>
Keep corrupted files : No<br/>
ext2/ext3 mode : Yes<br/>
Expert mode : No<br/>
Low memory : No<br/>
<br/>
Interface File Select<br/>
<br/>
PhotoRec exited normally.</r>

Sponsored links

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

Re: Benefits to running photorec multiple times?

#2 Post by cgrenier » 05 Oct 2018, 05:52

There is no benefit to running PhotoRec several times but running latest 7.1-WIP version may give you better results.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests