Sector by sector compression of unused space - lossless or lossy?

David, sorry but that depth of information is not available to the users as far as I am aware, you will need to open a Support case with Acronis Support directly and see if they will give you a definitive answer to the question.

Thanks for the feedback, Steve.   I'll open a support ticket.

As an aside, I didn't receive an email when you replied to my post.  Is that feature broken in the forums?

David, on the forum email notifications, this seems to be intermittent at times, but may be caused more by ISP's blocking 'bulk' email senders more that the forum itself.  I have had to change my own email address to a different ISP to get round this issue with my normal ISP.

Hi Steve,

I use gmail, so unless google has blocked Acronis, it may have just been a temporary problem with the forum.  I did just get a notification of your most recent reply.

Thanks again,

David

David, my ISP also used Gmail (under the covers) as shown when looking at the email folders in their webmail service.  The ISP is VirginMedia and there have been numerous reports of them blocking legitimate emails that one of the other MVP's pointed out to me recently.  Since I changed to using my alternative 1&1 ISP for email I haven't noticed any missing notifications.

Hello,

I've been working on this off and on and have information to share.  First off, here is what I submitted to technical support asking if compression would affect the unused areas of the disk image and explained what I was trying to do.

My first response from technical support was as follows:

...

Hello David,

Thank you for contacting Acronis Customer Central. My name is Praveen. I will be happy to help you.

As I understand, you would like to know about the compression for the bad sector under the backup.

I would like to inform you that the when you create an backup using sector by sector each backup will be check the sectors and perform backup. In case the drive had any bad sector the backup would fail from the application. Sector by sector backup will be larger than the normal backup as it would check all the sectors.

When performing normal backup it would not check the sectors. Both the backup will contain all the data when performing the recovery without any changes. Acronis True Image 2017 by default will have compression level but the backup data will not be affected and when you perform recovery all the data would be available.

Please let me know if this answers your query. Feel free to get back to us if you have any difficulties . We are always here to help you.

I look forward to your response.

...

My response:

...

Thank you for the reply.  There may be a misunderstanding about my question.

I'm not asking about bad sectors.  I'm asking about sectors that do not have any files allocated to them by the file system, but *did* have files in the past that were deleted and the raw data is still in those sectors.

The question is, will sector by sector with compression store all the same bits in the non-allocated sectors as sector by sector without compression?

An example:

Sector 1 = File A
Sector 2 = File B
Sector 3 = No file, but raw data from File C

Sector by sector with compression -> image X
Sector by sector without compression -> image Y

Restore image X -> New drive M
Restore image Y -> New drive N

Will drive M and N have identical sectors after the images are restored?

Thanks,
David

...

Their response:

...

Hello David,

Thank you for your email.

My name is Sudeendra from Acronis Customer Central replying on behalf of Praveen.

I would like to inform if we choose sector by sector backup option from Acronis True Image 2017 program will copy the entire contents of disk to destination in as is format and after restore destination drive will contain the same data as it was during backup of source.

By default Acronis True Image 2017 uses compression technology to create backup. However after restore destination size will be equivalent to source.

Let me know if this resolves your query.

Please feel free to contact us if you have any further queries. We are always here to help you.

...

I just couldn't quite get them to address what they do with the data in the raw sectors.  Since then, I've been taking an empirical approach.  I imaged one of my source drives with True Image, both with compression enabled (normal level) and no compression.  I then ran various file recovery tools against the mounted images.  One piece of software did seem to find some of the missing files.  The other tools didn't seem to do as well.  After much testing, however, I found that the other tools did find files if they were pointed at the original disk rather than the image.  That right there tells me that the data that True Image presents is not the same as the original source disk.  

I then pointed the software that did have some luck on the True Image file to the physical disk and it found a lot more than it had found on the True Image file too.  Lastly, I used a different disk imaging tool to create a disk image and then scanned that disk image with some of the tools and compared what they found on the 3rd party disk image vs the physical disk.  They found the same number of files, exactly, on the 3rd party imaging tool's image vs the physical disk (what one would expect if a disk image is an exact replica of the source disk).

This leads me to draw the following conclusions:

1)  Either True Image's sector by sector disk images do not maintain the data in "unused" sectors (sectors that are not mapped to currently available file system files, but may have had data in them at some point in the past)

OR

2)  True Image's mounting software somehow presents raw sectors in a way that they can't be accessed the same as the original disk sectors.  *If* this is true, then the way to test it is to restore the image to a fresh disk and scan the disk with the recovery software to see if it sees any more data on the restored disk vs the image of the source disk.  If all the sectors are maintained bit by bit, then a restored disk should be identical, at the sector level, to the source disk.  I do have a disk on which I can conduct this test.  I'll see if I can find time this weekend to do it.

My best guess is that the software will find less data on a disk restored from a disk image than it does from the original source image.  If so, True Image can't be used to recover data from currently unused sectors, which is a shame.  It doesn't appear to be able to do that from mounted images, which would be much more convenient than restoring to another physical disk.  

I'm sure it does a fine job at restoring files that are actively being maintained by the file system, but if you have a drive that has had files mangled by malware, accidental processing or hard drive issues, it doesn't appear to be the tool to make an exact copy of all sectors of a disk in order to preserve the current state of the disk and allow for detailed recovery efforts.

I'll still be using True Image for its ease of scheduling the creation of images, allowing for incremental updates, etc.  But going forward I'll have to either manually create images with this 3rd party imaging tool or I'll have to find another imaging tool that allows for the easy scheduling *and* maintains the data at the sector level *and* allows the images to be mounted as logical drives under Windows.

I looked high and low for an image format that supports the above features and supports compression.  I only found a couple formats that match and one of them didn't work with the tools I was using.  The other did work.  The compressed images aren't nearly as compressed as the Acronis True Image images.  It would appear the reason is because True Image is throwing away unused sector data, so it is able to produce a more highly compressed image file.  To be clear, however, even an uncompressed True Image image does not appear to contain the same data as the source, so it isn't that the compression is throwing away the data -- rather, it seems the image creation process is doing it and this just allows the compression to reduce the size of the file further than it otherwise would if the data was maintained exactly as it is in the source.  

In my particular testing, a 1.84 TB source drive resulted in about a 191 GB "normal" level compressed True Image image file.  It also produced a 1.81 TB image file with compression turned off (it is unclear why an uncompressed image is still slightly smaller than the source disk).  The 3rd party imager I used produced a 589 GB image file for a level 6 compression (0 is no compression, 1-9 are varying levels of compression).  On level 9, it only saved an extra 0.5 GB of space in the resulting image file.  From all I have seen, I believe the reason the 3rd party image file is so much larger is because it contains all the original data from the unused sectors of the source disk.

I'm posting this to make other users aware of this in case they are trying to recover files from True Image image files.  If the source disk is still working and hasn't been modified, your best bet is to either scan the source disk or try to find another imaging tool.  If you are creating image files regularly and assume (as I did) that you can always scan them later if the source drive dies, then you'll need to rethink that plan of action.

I'd also encourage Acronis to provide an option for truly capturing an *exact* replica of a source disk even if the resulting image file will be larger.

To be clear, I'm not saying that regular files that show up in the file system are at risk.  I'm talking about data from files where the file system records have been damaged or destroyed.  I didn't try to determine whether files that have simply been deleted, where most of the file system information is still present, but just hidden, are available from a True Image image.

I'm happy to answer questions about all of this.

Thanks,

David

David, first of all, thank you for a very comprehensive investigation and report on your findings, I am sure that other users will find this to be of value.

I have never really thought of ATI as being a forensic recovery tool, which in essence is what you are looking for in terms of the capability of creating an exact duplicate of all sector data from one disk and storing this in an image container file.

I would hesitate at running recovery tools against an Acronis backup image file that is just mounted as a drive letter via File / Windows Explorer, as there may well be limitations to how faithfully that mounted image represents the original sector layout of a physical drive, but I would expect that doing a full sector-by-sector backup should produce a physical copy of the source disk when restored to a second drive of equal or greater capacity, but from your findings, it seems that this is not the case.

My own approach when dealing with problem drives and doing data recovery has been to take a backup image of the source drive and keep this to one side so as to be able to get back to my starting point, but then to work off the source drive with any recovery tools.  I guess that I have been 'lucky' that there has been nothing 'lost' in taking this approach.

An alternative approach to this issue may be to purchase a dual-drive dock that can perform offline cloning without the need for any PC or additional software.

See:  Inateck USB 3.0 to SATA 2-Bay USB 3.0 Hard Drive Docking Station with Offline Clone Function for 2.5 Inch & 3.5 Inch HDD SSD SATA (SATA I/ II/ III) Support 2x 8TB & UASP, Tool-free  for one such clone dock solution.

Hi Steve,

Thanks for the reply.

I'm not using ATI for a crime investigation, other than the fact that the malware someone unleashed on it was a crime!  Too bad they can't easily be prosecuted! :-)  I think I get what you mean though.  It isn't marketed for this type of data recovery.  Still, when something claims to do a sector by sector copy, one would think that it would do just that.  If not, then what good is a sector by sector copy?

These are the reasons I like working off images instead of the source drives (no particular order):

1)  A lot of times the source drives are older technology and running the scans against an image file stored on a newer drive is significantly faster than running on the source drive.  This is especially true if the old drive is failing.

2)  If a drive is failing, it is important to get the data off it as soon as possible.  Without keeping a bunch of spare drives around, the easiest way to do this is to image the drive.

3)  If the source drive needs to remain in service, then the data on it will continue to change.  In the case of trying to recover lost files, each time more data is written to the drive, the risk of destroying lost files increases.

4)  Images are more portable.  In much the way that virtual machines can be moved around, images can easily be copied around to larger, future drives, duplicated, etc.  I just find them easier to work with and more flexible than a physical drive.  Mounting as a drive letter when needed, to access files that exist in the image, is a nice feature.

5)  If the source drive completely fails and all you have is the last image of the drive *and* you need to try to find lost files, then you you can only use the image, obviously.  I realize this is a less common use case, but it can happen.  In my case, I do have older images of older drives that may have contained good copies of my files at one point in time.  Those files may have been copied to another drive and deleted from the original drive.  The target drive then got hit by malware.  Recovering files from an image of the original drive, where they were simply deleted, might have a better success rate than trying to recover them from the malware'd drive *if* the image of the original drive is a true, exact copy of all sectors.  I thought that's what I had with ATI, but it doesn't appear that way.

That's not to say there is anything wrong with the way you are doing it.  As long as the source drive doesn't fail and you don't mind the possibly slowness of working against an older drive and if you can ensure it isn't written to by anything until you are done with the recovery, then it will certainly work.

Thanks for the links to the cloning device.  I think I do have a viable solution with 3rd party imaging software.  That particular software just doesn't have all the scheduling built in like ATI has, since it *is* used in forensic science, not for general purpose data backups.  Because ATI images are so much easier to create, I'll probably still use ATI for normal backups and reserve the 3rd party imager to special situations like this.  The only problem with that is if I don't make true image copies with the other software and then I need to recover a deleted file or otherwise damaged file *and* the source drive has some sort of issue that prevents me from imaging it, I'm out of luck.  I'll probably look around for 3rd party imaging tools that have the scheduling ability as well.  I couldn't find many image formats that support compression, but if I had to go with full sized images, I'd be willing to do that as long as they could be scheduled and mounted as a drive letter for easy browsing and recovery.

I'll update this thread if I restore the ATI image to a fresh drive and run recovery on that drive.

Thanks!

David

Just providing a quick update on this...

I re-opened the ticket with Acronis and explained that the slack space/unused sector data is not being preserved in images.  I scheduled a call with technical support and explained it again over the phone.  They will be looking into what "Back up sector-by-sector" and "Back up unallocated space" are *supposed* to do and will get back to me on that.

In the meantime, they recommended I try the New Generation version of the product to see if that shows any different behavior.  I uninstalled the 2017 version I had of ATI and installed the new version (may not be exactly the same build as what is available to the general public on the website, because the filename was different and had a build number in it).  I imaged my logical G: drive using this version and it was still roughly 200 GB in size, the same size as it was for the old version and roughly 1/3 of the size of a compressed image from 3rd party imaging tools.  This tells me the new version is not storing all the data from the unused sectors.

On the off chance that this defect is only affecting imaging of logical partitions, I am currently running a backup (sector by sector image creation) at the physical disk level with ATI New Generation.  This will include my F: and G: partitions, but I did not select just the partitions, I selected the whole disk.  A previous image of F:, with ATI 2017, with Normal compression, resulted in a file about 388 GB in size.  If the whole disk image is larger than 388 GB + 200 GB = 588 GB, then there is a chance it contains the data from unused sectors.  If so, I will run the 3rd party file recovery tool against it to see if it is able to find the data on those currently unused sectors (it is able to do this with images from 3rd party imagers).  I'll report back with my findings.

Technical support also asked if I was configuring the backup to ignore bad sectors.  I am *not* telling it to ignore bad sectors.  The theory was that the data I'm looking for might reside in bad sectors and if I told it to ignore bad sectors, then that might be why I'm not able to recover my files.  There would have to be a LOT of bad sectors for this theory to be true, but the fact that I'm not telling it to ignore bad sectors should mean that the drive is free from bad sectors, as the backup would fail otherwise.  The backup completes fine without ignoring bad sectors, hence no bad sectors, hence the data *should* be in the image if the image was truly backing up all data in all sectors.

As an aside, I had an issue yesterday where I inadvertently deleted a bunch of subfolders and files in my users folder in Windows 7.  I had an image of the C: drive from this past fall, so I decided to mount the image and copy the deleted files (at least those that existed back at that point in time, which would have been most of them) back onto the C: drive.  I wasn't able to do this, because of Windows permissions and the fact that Acronis no longer supports write operations on images, as of, apparently, 2015!  Opening the .tib file with Windows Explorer gets around this limitation, but it didn't show most of the folders that had been deleted.  These happened to be named starting with a period, but at least one folder named this way was present in the image.  I couldn't use this method to recover the files.  Lastly, I used the "recover files" feature in the Acronis UI to restore the user folder in question.  The end result looked the same as the browsed-in-Explorer results that I saw -- many of the folders were missing.  Luckily, I remembered that I had restore points enabled on that drive and I was able to get the files back that way.

Although this isn't directly related to the unused sectors issue (and I'll be opening a separate ticket for this issue), it is another example where ATI is not saving all the information it should in backup images of partitions -- backups that are set to use the sector-by-sector feature.  This is troubling.  It seems as if quality control (and quality) has gone down significantly in the product in the past few years.  That's a shame, because it has always been a top product.  I'm not sure if there is anything better in the marketplace, but I'm forced to start looking at what else is out there.  I'd much rather that quality control be stepped up so that I can just stay with the same product I've used and trusted for several years.

Thanks,

David

David, thank you for your further comprehensive update and feedback on the results of your further tests with ATIH 2017 NG - the common release build of which is 6116.  Please continue to let us know how this goes as you work further with Acronis support.

Hi Steve,

Thanks for the build number of the common release.  6116 is the same build I was given by technical support.

Thanks

David

Update...

Testing with ATI New Generation failed as well.  I imaged the physical drive, which included the two partitions.  The total size of the image was about 594 GB.  That's just a little bigger than the size of both partitions individually from ATI 2017, which is 588 GB.  Not nearly enough to make up for the many GB of data that resides in the unused sectors.

To be sure, I ran a file recovery and it only found under 3 million on the G: partition and under 8 million files on the F: partition, so under 11 million total.  Recovery against the source drive (and against images from a 3rd party imager) found over 20 million files.

In my situation ATI 2017 and ATI New Generation both fail to copy all data in all sectors at the disk and partition level.

I will be running the image creation again with some logging turned on so that I can supply it to technical support.

David

David, thanks again for the further update.  I suspect that the product is optimised to achieve the best compression and data integrity for those sectors which are recorded as used by the file system in use, rather than being 100% faithful to mapping every sector on the drive that may be considered as being 'dirty' in the sense that they have at some point held data but are now marked as free / available by the file system.

I would suggest that going for a hardware disk dock / clone station solution is more likely to provide the way forward for what you are wanting to achieve, and at a reasonable cost.  I recently purchased such a device:  ORICO Aluminium 2.5" 3.5" 2-Bay Hard Drive Docking Station Duplicator, USB 3.0, SATA III 6Gb/s, with Offline Clone Backup Function, for 2.5- and 3.5-Inch Desktop Laptop HDD and SSD, High-Speed, Supports UASP Speed-Up and 2 x 8 = 16 TB

One of the user reviews for this clone dock device wrote:  

9) Offline clone will not work if the destination is smaller than the source, even if there's only a tiny amount of data being copied that the destination is more than free to hold. Example, your 1TB source drive has only 100mb of data on it. The station will not clone it to a 200GB destination drive, even if it's empty since 500GB<1TB. However you can still do this through your operating system, ie windows explorer.
10) Partitions will be cloned as will any empty space, the copy method is Disk-Disk copy.

Hi Steve,

I have a way to image the drives and get the information off the images.  However, those tools aren't as user friendly as ATI.  I'm hoping that by working with Technical Support we can get a true sector-by-sector feature added (put back into?) the product.

Thanks,

David

Hello David,

I wonder whether images created with third-party programs are mounted in disk or partition mode? Could it be that when you scan the physical disk and these images, the bigger number of found items compared to Acronis is due to the fact that the entire disk is scanned, including unallocated space, former partition boundaries and perhaps something else that is missing in partition-only mounting that Acronis True Image offers? Maybe you have noticed, scan results from undelete tools can include multiple entries, actually pointing to the same file. Maybe in your case that is what is happening, and the image created with Acronis actually contains the data you need, it is just counted once?

I mean, when comparing Acronis True Image and other imagers, did you only look at the number of found items? Was there a situation when you could find and restore data from third-party imagers' files (mounted in partition mode, not disk mode), and that raw data was missing in Acronis backups?

Sector-by-sector backup in Acronis True Image is supposed to include everything within partitions borders. I will try to get more information about how the compression setting relates to such backups and then get back to you.

Regards,

Slava

Hi Slava,

I appreciate your well formulated response.  It is obvious you gave this some thought.

I have created images with Acronis at the partition level and the disk level.  I have created images with the 3rd party programs at the partition level and the disk level.  In all cases, the Acronis images do not contain anywhere close to the missing data that the 3rd party program images contain.  The sizes of the Acronis images are significantly smaller than the 3rd party programs (with both doing some compression) (roughly 200 GB for Acronis vs 600 GB for 3rd party, in one partition example).  And I have tried Acronis with no compression vs Acronis with compression with the same results.

It is not only the number of recovered files that are different.  By using the same recovery program and scanning Acronis mounted images vs pointing right at the real partition vs pointing at the 3rd party mounted images, and then taking the resulting found photos, for example, and sorting them by size, I can see that there are hundreds or thousands of files that are found on the real partition and 3rd party mounted images that are not found in the Acronis images.  There is no comparison.  Acronis is missing data.

I certainly would have thought that sector-by-sector would include every bit in every sector in the partition, but the empirical results do not agree with that assumption.  I would love to be proven wrong, however. :-)

Thanks,

David

Hello David,

I have got some information from the Development Team for you.

You need to create a new backup job and change the snapshot method under Options - Advanced settings - Performance, from the default value "VSS" to "Acronis Snapshot". VSS is the layer between Acronis application and the underlying disk that prevents proper reading of free disk space in sector-by-sector mode. Acronis Snapshot secures the required level of access to disk sectors to create a sector-by-sector backup.

If you create a backup in sector-by-sector mode when computer is booted from Acronis bootable media, this will also create a proper sector-by-sector image, because there is no VSS in Acronis bootable environment.

When comparing to 3rd party imagers remember to mount their images in partition mode. Like I mentioned earlier, Acronis allows mounting of partitions, but not unallocated space outside of partitions. Unallocated space could be scanned with "undelete" tools after restoring a backup, made with enabled option "backup unallocated space", to some disk.

Compression is loseless, you can leave compression enabled and enjoy scheduled backups in sector-by-sector mode, including the data from the free space on the partition.

Hope this helps and you will be able to get the expected from the software.

Regards,

Slava

Hi Slava,

I attempted to perform this test, but I'm unable to find the option you mention for setting the backup to use "Acronis Snapshot".  My options are as I have attached in a screenshot.

This is Acronis True Image 2017.

Thanks,

David

David, what build for ATIH 2017 are you using?  This needs to be build 8029 for the standard version, or else build 6116 for New Generation to have these settings.

See KB 59440: Acronis True Image 2017: 'Snapshot for backup' option overview

I would think that any backup from windows - using VSS or Snapapi, is not technically an exact copy of the original disk since these are snapshot tools.  David, have you tried taking a full, sector-by-sector backup of the original disk using the offline media and workign with that instead?  I'd also think the mounting of the backup .tib would be different as well since it's a representation of what lives in the backup as bundled in the backup .tib file.  Perhaps, if you then restored the backup to another disk using the offline media adn then attempted to check for recoverable content, it might have better results?

Ultimately, for exacty duplication, I'd go with a hardware clone - even the $30-ish dual bay offline clone drives can handle this - so long as the new disk is the exact same size as the original.  

As for recovery software, not sure what you're using, but have had pretty good luck with the paid version of Active@fileRecovery.  The Pro version even helped to save a couple of RAID sets.  I haven't had good luck with free tools like Recuva. 

Hi Steve,

I'm not sure what version I had, but I did an update and that brought me to 8029.  I am able to see the settings now.  I've set it to Acronis Snapshot and will attempt a partition level backup to see if it includes the data in the unused sectors.

I've attached what the new screen looks like.

Thanks,

David

Hi Bobbo,

Good point about snapshots.  I'm not sure how that would affect the unused space.  I guess if the OS writes some data to some unused space (for either the file data or the snapshot version of the file), then lost data in that unused space might be destroyed.  However, in my case, the disks in question aren't being written to for that very reason -- preserving the unused space data -- so it shouldn't even come into play.

I have not tried doing it offline.  Although it would technically work (in theory anyway), it isn't how I would use Acronis for day-to-day operations.  I guess, in a special case like mine, where I am trying to recover from a bad event, it would be okay.  But in this situation, I might as well use the forensic tools to create images, since I know those work and they are free and they work without having to boot the system into a special mode.  The downside to these tools is that they can't be set up to do scheduled backups, incremental backups, etc.  And restoring a working/bootable OS might be problematic as well.

The ideal, however, is to have a periodic backup (of all sectors and all unused data in all sectors) so that a person could have a copy as close to the time of a bad event, such that the lost data exists in a state before other write operations have destroyed it.  There are a number of ways to look at this.  If a person has periodic backups, then they shouldn't *need* to recover data from unused sectors, since they can just get the unmolested files out of the backups.  The gotcha to that is if the bad event damages the backups themselves.  Keeping backups away from the system might reduce this risk, but then it means the person has to manually place the backups somewhere off the system.  Having a *pull* mechanism that can be triggered when a backup is created and can copy the backups to another system that is not accessible *from* the source system (meaning the source system can't push any changes so that malware can't affect the external system) seems like the best way to handle that.  There is also the risk that something bad happened back in time that went unnoticed and all versions of the backups that exist when the problem is realized have been affected.  Without some really elaborate rotational systems, there is always a risk of this.  And one bad incremental in the mix is also a risk.

Personally, I'm going to aim for a system where I use file level replication to reduce risk of important files and try to implement automation of that replication.  Acronis disk images are great for recovering a working operating system and installed programs and seldom touched less important files, but I'm not planning on using them for my main safety mechanism going forward.

As for the .tib representation of the sectors, when mounted, I took Slava's response to mean that it would be represented the same way as the physical disk (well, logical partition in the physical disk).  I'll know sometime in the next day or so when I'm able to create the image and process it with the recovery tools.

If a person has the hardware ahead of time and waiting, it certainly won't hurt to do hardware clones.  Better is to just have your act together and have things backed up *and* off the system, so that a system-wide event can't mess you up.  I failed on that one. :-)  I had it on my to-do list for far too long and it finally caught up with me.

As it is, I think I'll be able to recover *most* of what I lost.  A big chunk of it will come from old Acronis images (just copying the files out of them).  Another chunk will come from an *ultra* laborious process of using recovery tools and then wading through 10s of thousands of files.  Even with specialized tools to automate de-duping, exif searching, etc., it will take a long time for that process to be completed.

I think I lucked out in that Windows 7 had automatically enabled the defragmentation program to run weekly on each disk.  I wish I would have known that at the time that the event happened so that I could have disabled it from running from then on.  As it is, I'm hoping/assuming that files were already defragmented from earlier runs, hence the defragmenting process analyzed the disks and decided not to do anything.  I only recently found that it was enabled.

The reason why I was lucky that it *did* run in the past is that the recovery programs would not have been able to recover the files if they were fragmented.  The data has to be in contiguous sectors to be found properly by today's class of programs.

There are a couple years worth of videos and pictures from my phone that I don't think I'll be able to recover.  At first I thought it was because they were fragmented, but after doing a lot of hex searching on the disk for exif date fields that should be in the files in question, I think the data is just gone for some reason.  It is possible that the defragger did do some amount of rearranging on the first run after the malware hit.  It is also possible that the malware truly zeroed out the bytes of those particular files.  I don't think it did this, however, since it didn't do that with other files that it messed with (it just marked them as size zero and left the data intact).

I haven't mentioned product names so that people wouldn't think I was pushing something.  I think some of the free tools do get a lot of the files nowadays, but I will be using a paid tool, since it does seem to do a better job overall in my testing.  I actually have 2 paid tools.  Early testing seems to point to them being very close in ability, but I'm leaning toward one.  If I can get by with just using one and not having to go through a lot more de-duping and sifting, that will safe some time.

Thanks for the post.  I'll post with my findings on the snapshot testing.

David

Update:

The "Acronis Snapshot" option of the latest version seems to have solved the problem.  The image isn't an *exact* replica of the source drive partition, but it is close enough.  By that, I mean that the size of the Acronis image is simliar to the size of the forensic tool image -- Acronis = 622 GB, other = 598 GB.  (and the difference in sizes could just be a difference in compression algorithms/levels too)  The other tool's image provided almost the same number of files when scanned with the recovery software vs scanning the original partition directly.  The variance is much higher with the Acronis image vs the original partition scan.  It takes a lot of effort to see exactly what is different, but I looked into some types of files and it appears that the Acronis image caused the recovery software to create more duplicates than the original disk or the 3rd party imaging software's image.  There may be cases where some files weren't found in the Acronis image that were found in the other image or original disk, but I didn't find any in the little research I did.  The main thing is that the Acronis image, with "Acronis Snapshot" enabled, is reasonably close to the 3rd party image and the original disk partition.

I'll be using the 3rd party disk imager for this process anyway, but it is good to know for future Acronis imaging that you need to have "Acronis Snapshot" enabled in order to undelete files or recover other lost data in the partition.

David

David, thanks for the update and glad that you were able to achieve satisfactory results for your testing.

Thanks for your help Steve.

I do think I'll mention to technical support that they should disable "sector by sector" and "unused sectors" options if/when the user picks VSS instead of "Acronis Snapshot," because it isn't truly doing a sector by sector copy when VSS is picked.

David

David, there is a corresponding change request in our system, but it has not been decided when to implement the change.

Regards,

Slava

Hi Slava,

Thanks for the update.

David