by abolibibelot » Sat Jul 20, 2019 1:02 pm
Alt wrote: Fri Jul 19, 2019 9:46 am
abolibibelot wrote: Thu Jul 18, 2019 8:32 pm
Another suggestion : ddrescue (Linux) allows to write a volume image in “sparse” mode, meaning that empty sectors are not allocated, which can be almost as efficient at reducing the size of the image as an actual compression if most of the files are binary files in compressed format (JPG, MP4, MP3...).
"Sparse" imaging has a very serious drawback - you won't be able to retrieve info from such empty sectors. They may contain raw files.
Are you sure about that ? As far as I know, “sparse” writing only results in sectors which are
totally empty in the source being unallocated on the image, but they are still there, referenced in the MFT record(s) (I don't know exactly how yet), and kind of “emulated” by the system when any program is accessing them. Normally the checksum of the source and the image should match, so a regular image and a “sparse” image should be identical for all intents and purposes. Recently I created (with ddrescue) a ~500GB sparse image from a 4TB HDD containing about 550GB of data (a healthy drive which had been painstakingly cloned from a defective drive – details on
this thread if curious), then I compared the image and the source HDD with WinHex in “synchronize and compare” mode, they were identical (I didn't go to the trouble of computing the checksums, which would have required 7-8 more hours, but I'm pretty sure that they would have matched, since I had disabled the MBR on the HDD to prevent Windows from writing on it, and the ddrescue copy went flawlessly).
There is however a (free) tool which allows to skip sectors which are unallocated in a NTFS partitioned source, even if they are not actually empty (and may therefore contain files recoverable by the “raw carving” method) : ddru_ntfsbitmap, included in ddr_utility. It parses the $Bitmap file and generates a mapfile for ddrescue, restricting the subsequent image creation (or cloning) to the areas which are actually allocated (i.e. not considered as “free space” by the file system). It also allows to recover the MFT first, which can save a lot of trouble in
some situations.
[quote=Alt post_id=16038 time=1563547565 user_id=59]
[quote=abolibibelot post_id=16037 time=1563499970 user_id=4229]
Another suggestion : ddrescue (Linux) allows to write a volume image in “sparse” mode, meaning that empty sectors are not allocated, which can be almost as efficient at reducing the size of the image as an actual compression if most of the files are binary files in compressed format (JPG, MP4, MP3...). [/quote]
"Sparse" imaging has a very serious drawback - you won't be able to retrieve info from such empty sectors. They may contain raw files.
[/quote]
Are you sure about that ? As far as I know, “sparse” writing only results in sectors which are [i]totally empty[/i] in the source being unallocated on the image, but they are still there, referenced in the MFT record(s) (I don't know exactly how yet), and kind of “emulated” by the system when any program is accessing them. Normally the checksum of the source and the image should match, so a regular image and a “sparse” image should be identical for all intents and purposes. Recently I created (with ddrescue) a ~500GB sparse image from a 4TB HDD containing about 550GB of data (a healthy drive which had been painstakingly cloned from a defective drive – details on [url=https://forum.hddguru.com/viewtopic.php?f=1&t=38446]this thread[/url] if curious), then I compared the image and the source HDD with WinHex in “synchronize and compare” mode, they were identical (I didn't go to the trouble of computing the checksums, which would have required 7-8 more hours, but I'm pretty sure that they would have matched, since I had disabled the MBR on the HDD to prevent Windows from writing on it, and the ddrescue copy went flawlessly).
There is however a (free) tool which allows to skip sectors which are unallocated in a NTFS partitioned source, even if they are not actually empty (and may therefore contain files recoverable by the “raw carving” method) : ddru_ntfsbitmap, included in ddr_utility. It parses the $Bitmap file and generates a mapfile for ddrescue, restricting the subsequent image creation (or cloning) to the areas which are actually allocated (i.e. not considered as “free space” by the file system). It also allows to recover the MFT first, which can save a lot of trouble in [url=https://superuser.com/questions/1267818/rebuild-massively-fragmented-files-with-a-partial-image-and-a-list-of-their-sect]some situations[/url].