1) Why is the size of the data on disk (/share/cachedev1) 1.9TB but the size of the recup1 directory (backup) created by photorec only 1.2TB? The whole disk was marked for backup in the recovery proccess, but it seems to me that there is lots of data missing in the backup. I cannot compare it though, because of the special naming and ordering of the recovered data and because restore proccess fails (see point 3). What are possible reasons for photorec not copying all data while doing a backup operation? The process is finished without errors.
2) The restore script is a compiled python script (qrescue.pyc), hence i have little insight in what it is doing in detail. But from the logs I can see that many JPG files are skipped during restore proccess. They do not seem to differ noticeably from the ones that are restored successfully in size, metadata,... and I can see the decrypted files in the correct folder on the disc, so why are they skipped during restore proccess and is there a possibility to get these files also converted into original name+metadata? Has anyone experience in success rate of testdisk vs. qrescue?PhotoRec 7.2-WIP, Data Recovery Utility, May 2021
Christophe GRENIER <grenier@cgsecurity.org>
https://www.cgsecurity.org
Disk /dev/mapper/cachedev1 - 2418 GB / 2252 GiB (RO)
Partition Start End Size in sectors
P ext4 0 0 1 429391871 0 1 4724359168 [DataVol1]
714213 files saved in /share/rescue/recup1/recup_dir directory.
Recovery completed.
3) The script exits with error each time it hits a certain file containing the german letter "Ö" in its filename. The exact error message is "OverflowError: mktime argument out of range", which I identified as time error - argument mtime is too far from current time. Since i can check the metadata of encrypted file on NAS and it seems to be okay, I wonder if the file name (that cannot even be displayed correctly) causes the strange date and leads to error. See below:from qrescue_trace.log:
2022-05-04 07:16:05,629(DEBUG) [qrescue(1240):recup_all_7z_files()] handling 7z meta={
"attr": "A_ -rwxrwxrwx",
"crc": "A2C9CA04",
"ext": "JPG",
"file_name": "2019-03-03_BEGI_HANDY_021.JPG",
"mtime": "2019-03-03 18:54:28",
"path": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG",
"size": 5962476
}
2022-05-04 07:16:05,980(DEBUG) [qrescue(1241):recup_all_7z_files()] handling 7z file=/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z
2022-05-04 07:16:07,124(DEBUG) [qrescue(1253):recup_all_7z_files()] matched info={
"error": 2,
"filepath": null,
"same_size": 0
}
2022-05-04 07:16:07,124(ERROR) [qrescue(1258):recup_all_7z_files()] "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z" NOT FOUND !
2022-05-04 07:16:07,125(INFO) [qrescue(790):print_progress()] {
"act": "skip",
"act_7Z": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2019/2019-03-03_BEGI_HANDY_021.JPG.7z",
"proceeded_7Zs": 71493,
"proceeded_%": "33.42%",
"total_7Zs": 213919,
"total_recap": 724187,
"fix": 19093,
"skip": 52400,
"fix%": "26.71%",
"start_time": "2022-05-03 10:20:21",
"elapsed": "20:55:45.32",
"estimated total time": "62:37:25.77",
"estimated remaining time": "41:41:40.46"
}
2022-05-04 07:16:07,128(DEBUG) [qrescue(366):get_file_info_from_7z()] cmd = "/usr/local/sbin/7z.orig l -slt /usr/local/sbin/7z.orig"
May the special character be responsible for the error? If so, is there a way to ignore it (all files containing äöü case-insensitive)? Or what other reason could lead to this error?2022-05-04 13:17:38,437(DEBUG) [qrescue(366):get_file_info_from_7z()] cmd = "/usr/local/sbin/7z.orig l -slt /usr/local/sbin/7z.orig"
2022-05-04 13:17:38,616(DEBUG) [qrescue(1240):recup_all_7z_files()] handling 7z meta={
"attr": "A_ -rwxrwxrwx",
"crc": "E24CA280",
"ext": "JPG",
"file_name": "2008-08-20_TAT\u00d6_004.JPG",
"mtime": "2104-11-19 00:42:24",
"path": "/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TAT\u00d6_004.JPG",
"size": 956991
}
2022-05-04 13:17:38,617(DEBUG) [qrescue(1241):recup_all_7z_files()] handling 7z file=/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TATÖ_004.JPG.7z
2022-05-04 13:17:40,097(DEBUG) [qrescue(1253):recup_all_7z_files()] matched info={
"error": 0,
"filepath": "/share/rescue/recup1/recup_dir.338/f616537072.jpg",
"same_size": 1
}
2022-05-04 13:17:40,097(DEBUG) [qrescue(1274):recup_all_7z_files()] matched={
"error": 0,
"filepath": "/share/rescue/recup1/recup_dir.338/f616537072.jpg",
"same_size": 1
}
2022-05-04 13:17:40,124(DEBUG) [qrescue(1279):recup_all_7z_files()] copp recup file:"/share/rescue/recup1/recup_dir.338/f616537072.jpg" to "/share/rescue/restore1/share/CACHEDEV1_DATA/Data/Bilder/Privat/2008/2008-08-20_TATÖ_004.JPG"
# proccess quit here. No more lines in log.
4) In terms of data recovery, I have learned the rule "do not touch the crime scene" which means afaik "do not overwrite or change data". But do I limit my recovery chances by renaming files on the affected disks but letting the file contents as-is and where-it-is? And in addition, do I limit my recovery chances by cutting files to another backup hard disk and copy it back later in the same location on the affected hard disk?
5) Do I have extended chances to get data back using the single hard disks during recovery proccess instead of selecting share/CACHEDEV1/ (which is recommended approach)?
Unfortunately i got no help from QNAP support besides the recovery instruction (quick how-to use qrescue). I am familiar with Linux and have lots of (backup-) disc space available. Any help would be greatly appreciated!