#DDRESCUE GUI WINDOWS UPDATE#
#DDRESCUE GUI WINDOWS SOFTWARE#
#DDRESCUE GUI WINDOWS WINDOWS#

Maybe I'm just getting lucky and it is physically damaged. One would think that with all that this drive has been through, if it was failing, it would take a long time to read from/write to and the number of errors would increase. I've cloned with it Clonezilla (which claims it's physically damaged), and then I imaged it twice with GNU ddrescue with one parameter value increased and the image results are exactly the same. This SSD drive has been slaved quite a few times to analyze and also attempt decryption.

#DDRESCUE GUI WINDOWS SOFTWARE#

I'm assuming data recovery services have vastly superior software and hardware tools that could read bad blocks from an SSD, however. But perhaps they differ from mechanical disks in that if you can't read a bad block, most likely you won't be able to, no matter how many times you retry. I wanted the errors to go down, which is why I tried imaging again. If there was, wouldn't the error count and error size go UP the 2nd time I imaged the drive, especially with increasing the read retries to 20? I still don't know if 116 errors is a lot, but here's why I think there's no physical damage. What could that mean? Put a gun to my head, I'd say this SSD drive is not physically damaged. Yes, the error count and error size (still don't understand their relationship or what an error means in this program) are 116 and 470 kB, exactly the same as the first time I imaged with this program. Everything else is the same, including the results (it took slightly longer to image than the first time, because of the read retry increase). I ran GNU ddrescue once more, with read retries increased from 5 to 20.

#DDRESCUE GUI WINDOWS UPDATE#

I got no reply so I'll update and hope someone out there smarter than me will reply with some answers. But is this drive physically damaged based on 116 errors totaling 470 kB? I know there are logical errors on the drive. Yet, while GNU ddrescue reported 116 errors, at least most of the data was imaged. So, I'm really not sure.Ģ) Is 116 errors considered to be a lot and indicative of physical damage?įor the moment, I can confirm that, at the very least, over 99% of data was transferred. I attached a screenshot so I hope it displays properly.ġ) Are the results saying that 116 errors (sectors or blocks?) totaling 470 kB were found and transferred or found and not transferred? If you notice, the program says it's about to copy 256052 MB and it says it rescued 256052 MB. For the record, the program lists 'Sector size: 512 bytes' and 'Copy block size: 128 sectors'. It also lists 'errors: 116' and 'errsize: 470 kB'. The average transfer rate was around (25.88 MB/s) (I used eSATA and SATA, respectively, to transfer data). (retries bad sectors 5 times verbose output to screen direct access mode to skip kernel cache). I created an image of the SSD drive using the following syntax: I wanted a better image/clone so I found Ubuntu Rescue Remix Live CD and ran GNU ddrescue. I then checked off -rescue (skips bad sectors) and it cloned. I first ran Clonezilla to clone the drive with -q1 (sector clone) and Clonezilla could not start the clone process because it said the drive is physically damaged (does it determine this by using SMART or looking at the G-List?). The file system is corrupt and unreadable.

#DDRESCUE GUI WINDOWS WINDOWS#

It's an 256 GB SSD drive with Windows SP3 32-bit and it's encrypted with PGP Whole Disk Encryption.

Ddrescue gui windows