Re: Trying to rescue data from a failed NTFS HD

[kenadinka hrustic]

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 <MartinBittermann@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
>
>