Cant read SSD

[johnrobert]

480 Kingston SSD can't access data it tries to boot, goes to repair and recycles in a loop
I connected as a slave, in Disk Manager show 4 partitions, and it mounts as D but can't open file, tried it in Linux
Can anyone suggest a free data recovery app maybe 1% chance of recovering any data give a last chance

.
I know your supposed to clone it first, cant spend any more time they don't have funds, just want to give it a try being an SSD it might be an electronic problem.
I think in the past someone suggested photo recover, think it was called.

 

[GTP]

If you're looking for "free" data recovery programs there are plenty out there. Disk Drill, Recuvva (but beware using this "Avast owned" program), Filerecovery, Undelete360, PhotoRec, FATWalker and plenty of others.

I use GetDataBack personally (paid license).

You know the warnings about data recovery though? If the data is not yours or it's important don't use "free" recovery tools.

Send it out to someone who knows what they're doing.

 

[lan101]

I've had good luck with this program.

Find and Restore Lost Files: Undelete deleted files and recover damaged disks

Active@ File Recovery provides ability to detect and recover lost files and damaged disks.

www.file-recovery.com

Just get a decent usb to nvme box and it should be decent if no electronic issue etc. with the ssd.

I got this one a while back based on a suggestion here.

Amazon.com

 

[Diggs]

If you run Linux then ddrescue is hard to beat when recovering hard drives. I don't know how it does when used on SSDs though.

 

[Markverhyden]

Can open file? What file? The partition D? Or some file on D:? Either way you should prep your customer with the bad news that when solid state storage devices fail it's usually catastrophic. Meaning nothing can be recovered using conventional tools.

 

[Joep]

I'm surprised there's shops that didn't even spend $100 once for a perpetual license for a very decent, pro grade data recovery tool.

 

[lcoughey]

99 times out of 100, it is faster to clone the drive, working around the bad sectors with a program like ddrescue, or, better yet, a RapidSpar or R-Studio with a USB stabilizer. Once you have it cloned, the file system recovery is done quickly.

In short - lazy way usually takes days or weeks and following best practices could cut it down to hours or a few days and have much better results

 

[ell]

99 times out of 100, it is faster to clone the drive, working around the bad sectors with a program like ddrescue, or, better yet, a RapidSpar or R-Studio with a USB stabilizer. Once you have it cloned, the file system recovery is done quickly.

In short - lazy way usually takes days or weeks and following best practices could cut it down to hours or a few days and have much better results

plus with a ssd it shouldn't take that long to image

 

[Joep]

plus with a ssd it shouldn't take that long to image

A sick SSD, which is what we have here, can take ages to clone. That's the thing with sick drives in general, "should" goes out the window.

 

[britechguy]

A sick SSD, which is what we have here, can take ages to clone.

And the key word in your message is can. There's a big difference between can and definitely does/will. One always tries to image a bad drive as step 1 and work with the cloned image. If that doesn't work, then one moves to options B, C, D, etc.

 

[Joep]

And the key word in your message is can. There's a big difference between can and definitely does/will. One always tries to image a bad drive as step 1 and work with the cloned image. If that doesn't work, then one moves to options B, C, D, etc.

Nope, key in my message is "with sick drives in general, should (be faster) goes out the window", and cloning/imaging may take a long time. It often does take more time that you'd expect with a healthy drive. Can, may, whatever. But in context if sick SSD "plus with a ssd it shouldn't take that long to image" is nonsense / noise.

 

[Sky-Knight]

Imaging a bad drive has a time delay adjustable by how you have the software handle read errors. By default it'll keep attempting until it gets data, giving up only after many attempts, this is where the time delay comes from.

This is a skill related to data recovery, configuration of the imaging tool, this process isn't push button watch work. You need to learn the tools.

But I too recommend imaging the drive first, and working from the image. Defective disks degrade with further use, the more you muck with them the worse things get and the less opportunity someone better trained will have at completing the task.

Bill the customer for the attempt, this is a valuable service even in the attempt.

 

[Joep]

Imaging a bad drive has a time delay adjustable by how you have the software handle read errors. By default it'll keep attempting until it gets data, giving up only after many attempts, this is where the time delay comes from.

This is a skill related to data recovery, configuration of the imaging tool, this process isn't push button watch work. You need to learn the tools.

No, I don't I agree at all. "By default it'll keep attempting until it gets data" isn't my approach at all and I'd advise very much against it.

EDIT: I am sorry I misread this!! It will keep trying, I misread that you kept trying. My mistake, apologies.

Ideally you figure out time is needed a non problematic sector gives data, and that (+ some) will be your read timeout threshold. Anything that doesn't give data within threshold you skip (+ some skip factor to avoid patches of bad sectors) for a further pass.

And even from that I sometimes deviate depending on what initial diagnostics and tests give. SSDs may appear to suffer from bad sectors while it's more a firmware issue than bad sector issue. Handling that as classical bad sector is nonsense and so is saving it for a further passes.

But I too recommend imaging the drive first, and working from the image. Defective disks degrade with further use, the more you muck with them the worse things get and the less opportunity someone better trained will have at completing the task.

It depends. Say a drive is only 15% occupied and I need 10% or 20% of that. May sound far fetched (but it isn't), but even if so "always image first", specially when it comes to NAND flash based drives isn't some universal truth.

Why put a drive through reading 1 TB while in the end I need 30GB of data? What would be most stressing to the drive? This is what you should ask yourself and not mindlessly image the whole thing because "that's how this is done".

Then once I have the 30GB (and preferably have a runtime image running at the same time) I can try get data less important or even try image the whole thing.

Anyway, "one fits all approach" isn't the professional way IMO.

 

[britechguy]

Anyway, "one fits all approach" isn't the professional way IMO.

One can only speak of generalities generally. I would presume that most of us here know how "the fine tuning" works and when it's necessary.

You are playing an endless game of, "Yeah, but what about?." It's not helpful, and it's insulting to other professionals here.

This discussion is not a tutorial on all the fine points of data recovery. But one of the basic ones is that you image (whether partially or entirely) the failing drive, because you may only get one shot, and work with the result. Repeatedly hitting the source media, which is failing, is just not done. You know that, I know that, and that's the general principle being discussed.

And regardless of your assertions, it's generally much faster to do whatever imaging you need to do from a failing SSD than a failing HDD. But copying from a perfectly intact SSD is much faster than doing so from an perfectly intact HDD. The general principle applies. It's presumed that someone doing imaging on a failing drive knows not to let the software (or hardware) doing same to take an insane number of tries at getting something it couldn't get on the first attempt.

 

[Joep]

One can only speak of generalities generally. I would presume that most of us here know how "the fine tuning" works and when it's necessary.

I very much doubt it, in general, exceptions aside.

You are playing an endless game of, "Yeah, but what about?." It's not helpful, and it's insulting to other professionals here.

Exactly my point, this is what separates a pros from an amateurs. A pro looks what's needed an amateur does what he always does.

This discussion is not a tutorial on all the fine points of data recovery. But one of the basic ones is that you image (whether partially or entirely) the failing drive, because you may only get one shot, and work with the result. Repeatedly hitting the source media, which is failing, is just not done. You know that, I know that, and that's the general principle being discussed.

And it's exactly that: "because you may only get one shot,", that I am addressing. Because you may only have one shot, you better do what's right. Imaging the whole thing may not be.

And what's against discussing fine points if we actually learn a thing or two from that?

And regardless of your assertions, it's generally much faster to do whatever imaging you need to do from a failing SSD than a failing HDD.

I don't know what you're exactly saying, but regardless your assertions, imaging failing SSDs can take just as long as it's not only sector access times that matter, it's what the firmware is doing that often matters.

 

[britechguy]

SSDs can take just as long as it's not only sector access times that matter, it's what the firmware is doing that often matters.

And you just don't seem to get that "exceptional can" is not equal to "typically does." This is a simple concept, really simple. Typical versus exceptional matters, in all things. I don't choose to focus on the tails of the bell curve, but what is generally experienced near the mean when I'm speaking in broad general terms.

Everything you've said, I actually acknowledge, and understand. Why you can't acknowledge that exceptions are exceptions and general rules are general rules completely eludes me.

 

[Joep]

And you just don't seem to get that "exceptional can" is not equal to "typically does."

It's a common, typical symptom of a failing SSD.