Hello Antonio and Martin, First of all, thank you for your answers.
They helped me a lot in understanding what to do. I tried all your advice and kept searching the web for other tools. I found ddrescuereview and recuperabit. With both those tools and a lot of time, I managed to copy more data from the HD and recuperabit helped me extract most of the files. It's still a big mess, and there's still a lot of files missing. ATM ddrescureview tells me : - Rescued: 797 GB - Bad Sectors : 12.29 KB (3 sectors, as you guessed), - Non tried: 1.10 TB - Non-trimmed 101 GB Everytime I run ddrescue, it ends with the same error : ddrescue: /dev/sde: Unaligned read error. Is sector size correct? I tried to skip the first sectors and currently it's running with : % sudo ddrescue -n -b4096 -K 110592000 /dev/sde /home/quentin/nfs/data/forensic/ntfs_data.img /home/quentin/ntfs/ddrescue_data.data and it's really slow : GNU ddrescue 1.26 Press Ctrl-C to interrupt Initial status (read from mapfile) rescued: 797286 MB, tried: 100753 MB, bad-sector: 12288 B, bad areas: 3 Current status ipos: 898794 MB, non-trimmed: 100753 MB, current rate: 3971 B/s opos: 898794 MB, non-scraped: 0 B, average rate: 1238 kB/s non-tried: 1101 GB, bad-sector: 12288 B, error rate: 0 B/s rescued: 798044 MB, bad areas: 3, run time: 10m 12s pct rescued: 39.89%, read errors: 1, remaining time: 2d 21h 32m time since last successful read: 0s Copying non-tried blocks... Pass 5 (forwards I'll let it run for a while, since ddrescuereview is showing some progress... I managed to understand how to use recuperabit and I can try to extract THE IMPORTANT FOLDER after every ddrescue run. Not a lof of success yet but I think the data should be very deep in the partition. Most of the important files are extracted and they seem to be ok. I can't test them yet, but it's another problem :) Unfortunately, I couldn't install ddrutility. I tried the AUR package (I'm running manjaro) and the source files, but it won't compile. I'll try again but I won't bother you with the details. I'll try Martin's suggestions as soon as this ddrescue run ends. Once again, I'm astonished by both of your answers. Thanks a lot, Quentin Le dim. 27 févr. 2022 à 19:18, Martin Bittermann <martinbitterm...@gmx.de> a écrit : > Hello Quentin, > > I hope your data rescue is going well. > Perhaps I can help with some suggestions to speed it up. > > From your ddrescue output I can see that > > * The average read rate is low, about 1 MB/sec > * ddrescue skips a lot over slow areas (non-trimmed: 10327 MB) > > In such cases I find it helpful to limit the operation of ddrescue to > the most important sectors. > This is possible with the feature called 'Domain Mapfiles'. > From the ddrescue manual: > > > |-m |file > > |--domain-mapfile=|file > > Restrict the rescue domain to the blocks marked as finished in the > > mapfile file. This is useful for merging partially recovered > > images of backups, or if the destination drive fails during the > > rescue. Use '-' as file to read the domain mapfile from standard > > input. Specialized tools like ddrutility or partclone can produce > > a domain mapfile listing all the used blocks in a partition, > > making the rescue more efficient. > > > To use a domain mapfile, you would simply interrupt the rescue, then > invoke ddrescue again with the additional parameter '-m domainfile', > like e.g. > > % sudo ddrescue -n -b4096 -m /home/quentin/ntfs/ddrescue_part2_dom > /dev/sde > /home/quentin/nfs/data/forensic/ntfs_data.img > /home/quentin/ntfs/ddrescue_data > > Here I have prepared a domain mapfile that excludes your first partition > (48GB) which is not important to you: > > # Rescue Domain mapfile for partition 2 > # Command line: > # current_pos current_status > 0x00000000 + > # pos size status > 0x00000000 0x00100000 + > 0x00100000 0x0C35000000 ? > 0x0C35100000 0x01C58C016000 + > > This is of course of limited use, for all we know ddrescue might have > already copied the whole first partition. > > To gain a better overview of the rescue status, you could use my program > ddrescueview, which visualizes ddrescue mapfiles. > See https://sourceforge.net/projects/ddrescueview/ > There is a Debian package as well, but it has not yet been updated to > the latest version. > For usage with ddrescue 1.24 and later, I recommend you use the latest > version 0.4.5 . > > So after trying out the domain mapfile above, stop ddrescue again and > let's continue to reduce the rescue domain. > As the manual says, we can use ddrutility or partclone to create a > domain mapfile which includes only the used space on one partition. > The emptier your partition, the more useful ;-) > I've always used ddrutility when dealing with NTFS. It is a collection > of tools to supplement ddrescue. > See https://sourceforge.net/projects/ddrutility/ > Especially read the whole manual section about ddru_ntfsbitmap. > Now you would run (in a separate directory, because ddru_ntfsbitmap > creates a bunch of files in the working directory) > > % ddru_ntfsbitmap /dev/sde > /home/quentin/ntfs/ddrescue_part2_dom_usedspace -m > /home/quentin/ntfs/ddrescue_part2_dom_mft -i 52429848576 -o "-n -b4096" > > Now ddru_ntfsbitmap will invoke ddrescue a few times to recover the MBR, > MFT header and volume bitmap. > With some luck, this should yield two domain mapfiles which you can use > with your main rescue: > > /home/quentin/ntfs/ddrescue_part2_dom_mft > -> marks only the clusters which hold the Master File Table, i.e. the > most essential file system index. Start with this one and let it finish. > > /home/quentin/ntfs/ddrescue_part2_dom_usedspace > -> marks all space occupied by files, folders, metafiles according to the > volume bitmap. After the MFT is rescued successfully, use this domain. > > Now it all depends on whether your disk plays nice... > I'm just assuming the best case scenario (Not much used space, HDD > copies all data in domain eventually). > > The next logical thing to do is: > > try to scrap some files from the .img ? (how ?) > In the best case scenario, ddrescue has already copied all essential > filesystem structures (not only the MFT) such that the image, > or more precisely: the partition inside the image, is mountable with > ntfs-3g (as you already tried, but please read-only): > > % sudo losetup -P -r /dev/loop0 > /home/quentin/nfs/data/forensic/ntfs_data.img > % sudo mkdir /mnt/ntfs_data > % sudo mount -o ro /dev/loop0p2 /mnt/ntfs_data > > However, Linux is very picky. It won't mount a defective NTFS volume, > not even read-only. > > That means you will most likely need to > a) prior to mounting, repair the filesystem on a COPY of your rescue > image (using ntfsfix or chkdsk) -or- > b) prior to mounting, repair the filesystem in your image while > diverting the changes done by ntfsfix to a buffer (using xmount) -or- > c) do not mount the image, but use a file recovery software on the image > and restore your files (testdisk or others) > > I hope this helps with your rescue. > > Best regards, > Martin > >