... or so I think at least.

I'm trying to keep it short, but I need to quickly summarize the backstory of my problem:

A few days ago my Thinkpad SL510 suddenly stopped working. More precisely, after turning it on, the screen stayed black (though under power), and no further activity happens. Cannot get into BIOS, nothing. I am still trying to figure out what exactly is wrong with it (I already was able to rule out RAM, CPU, broken USB and some other problems).

I wasn't exactly able to rule out the HDD as the cause of the problem, so I took it out and put it into an external case and connected it to my 2nd PC that runs (x)ubuntu. Much to my relieve the HDD was recognized, and mounted, and I did a quick check to see if my files were still readable. They were.

Here's where the real problem started: I then tried to unmount the device, but got an error. Didn't think much of it, but when I tried to mount the HDD again later, again under Linux, 2 out of 3 partitions are not mountable anymore. The error thrown by linux suggests to run chkdsk /f under Windows, which I tried (on a friend's Windows PC). One of the partititons of my HDD (the Lenovo recovery partition) is recognized without problems.

The 2 other partitions (the important ones, one is 'system', the other holds most of my data) appear, in Windows, but are not accessible/Windows Explorer doesn't manage to read their size, etc. Running chdksk on them simply results in an error.

The HDD in question is a 320 GB, 5400 rpm, SATA interface disk. Don't know the manufacturer, but I can find it out. File system is NTFS.

To summarize: My notebook doesn't boot up anymore, and I cannot rule out (nor confirm) that my HDD is the cause. However, I was able to mount it under Linux, and open several files without problems. But when I unmounted the disk, an error occured and since then 2 partiations of the HDD cannot be mounted/read anymore, neither in Linux nor Windows. No idea if it's a result of the unmount error in Linux, or part of the original problem that caused my notebook to stop working.

My question: I'm sort of lost... where do I even begin to figure out what to do now? Do I need to try to recover my data, or can I still try to get the HDD working again? Maybe it's just some minor detail overwritten by Linux that can be changed back again... I simply don't know. Any suggestions what I should do now?

Insufficient details of exact error messages (and unfortunately you weren't looking in the best place for exact details). Errors reported by "mount" or "umount" can occur for many reasons and so are not helpful, except to indicate that something has a problem. Nothing was the "result" of the Linux umount error - that error itself was the result of whatever underlying problem there is (chicken vs. egg). Instead you should look at the kernel messages, for hints about the underlying problem.

As always, you are taking risks, and if the data on this drive is really important - stop now. If you are happy to take risks, and accept responsibility for the fact that you might make the situation worse, or even change a recoverable situation into a totally unrecoverable one, then I would stop any further diagnosis attempts, as you risk "diagnosing the drive to death". Instead use your favourite non-Windows cloning software (my preference is GNU ddrescue) to clone your 320GB drive onto another, blank 320GB (or larger) drive (obviously data will be overwritten on that drive), or into an image file in a filesystem mounted on another drive, or via NFS or iSCSI etc elsewhere. There are many possible options depending on your skills, experience, attitude to risk, available equipment, and other things I've described dozens of times before - use the search option in the top right corner for previous comments from me and others about cloning.

It's possible (though unlikely IMHO) that the drive is OK - in that case your cloning would show 2 things: (a) it would show the drive was readable, and (b) it provides a backup. Based on your symptoms, however, I doubt the drive is fully readable, and it may even fail catastrophically while you attempt cloning, but you might be lucky. If you choose to use GNU ddrescue, then read about it carefully first, and ideally practice using it with different drives containing unimportant data.

P.S. If you want to send your drive to a DR professional, instead of risking your data with DIY attempts, there is a forum member in Belgium who also does several recoveries from people in Holland (if I remember correctly).

@Vulcan:

Thank you for the reply.

First: yes, I should have included at the very least the error xubuntu throws when I try to mount the two non-working partitions. For the record, it is:



Two: you write I have to make a decision, if I want to continue, since I risk "diagnosing the drive to death". What is the alternative? Stop my own attempts and hand it over to a professional?

Three: If I take the cloning route, and assuming for a moment it would be fully (or nearly fully) readable, could I expect to be able to read the data from the clone, or is the point of the cloning not yet retrieving usable files but rather having a backup in case the primary disk gives in entirely?

You're welcome Unfortunately I don't have much time, so briefly:


That's what I expected to see - almost certainly your drive has a fault and, since this is a new situation, the drive is deteriorating. For more details of the exact problem, you need to get the details of the I/O error from your distro's kernel messages file (I don't use Ubuntu, but it could be /var/log/messages or similar - use your Google skills if you're unsure) or, if the error message is still in the kernel's message buffer, you can look in the output from "dmesg" for the relevant time of that mount failure.


Yes. Even just mounting & unmounting the drive has risks, if the drive is deteriorating - we don't know when it will fail catastrophically...

Also stop trying to run fsck /chkdsk on the drive - the I/O error message proves this isn't (just) a filesystem inconsistency problem; (part of) the filesystem metadata is unreadable, preventing the filesystem from being mounted. That NTFS-related error message is a generic one, with several possible causes.


Yes (or with a little more work), but the original drive could fail catastrophically during the cloning attempt. As I said, there are risks...


I don't understand.


Yes, that too. As I said, a drive which is deteriorating could fail catastrophically at any time. This is why, since we have some evidence of a drive problem from the mount/umount problems, now confirmed by the I/O error message, that your focus should be on saving your data (if that is possible), rather than scanning the drive etc. to see how bad the problem is - as that could "consume" the last of the drive's lifespan, before professional recovery becomes your only option.

At this stage, with the drive at least partly readable, a DR professional would use more capable equipment to produce a clone, that what us amateurs have access to. If the drive deteriorates to the point where it starts to click and none of the drive is readable, then recovery becomes more expensive, more difficult, and less certain. I don't know your skills, experience, available equipment, the exact state of the drive etc. etc. to judge whether you trying to clone that drive is a very high risk or just a high risk. Welcome to the limits of remote assistance. Hope this reply is at least some help.

It was, very much so. Thanks a lot.

I'm going to sleep over this and decide in the next days if I want to give it a run myself and try to clone it or instead start asking DR professionals in my vicinity. Until then, I'm not going to fuck around with the drive anymore

Makes perfect sense. Good luck

_________________
PC Image Data Recovery
http://www.pcimage.co.uk

New!! HDD-PCB.COM for all your PCB and donor HDD requirements!

Yet another thread where Vulcan gives the right answer and lays a hand to help someone.
A valueable asset of this forum, sometimes it is good to give credits where credits are due and it doesn't hurt to give kudos to people that deserve it.

Not that OP didn't say thanks, but I'm just sayin'.

_________________
http://www.northwind.gr
SandForce SSD Recovery
Ransomware Reverse Engineering - NoMoreRansom! partners

@tonfagun,


You're welcome and that sounds like a good plan, as pcimage said. No need to rush into anything.

I also slept on this, and I have one suggestion which you can consider, for a low-risk way (nothing is zero-risk!) to get some more info about how sick the drive thinks it is. That would be to use "smartctl -x" (from the smartmontools package) to collect the SMART data from the "problem drive" (and then attach to your reply as a file) the full text output from that smartctl command - for example:


That assumes the "suspect" drive is /dev/sdc, as the error message suggested earlier. Change this part, if the drive is assigned a different device number. If you're not familiar with this, then practice with another drive first because the exact syntax depends on where your smartctl binary is placed, and also you should confirm that the output file (which is /tmp/smartctl-sdc.txt in my example) does contain the text from smartctl.

That output from smartctl cannot show how rapidly the drive is deteriorating, nor can it tell us exactly when the drive will fail catastrophically. As I said before, gathering this SMART data would not be zero-risk (because it will cause another power-cycle of the drive, and some extra SA accesses), but if the SMART data shows that the drive is really sick (for example) that info might be useful for you making your decision about what to do next. It's just an idea...

@northwind,

I'm not always right (as my gf often tells me!), but thank you very much for your kind words and support I appreciate it!

You are so correct. He is always there to give a long detail of what is wrong. He deserves more thanks than he gets from people who come here. You did a good job Vulcan and please do not worry people are sometime rude and do not say thank you for all your time and help.

_________________
Iorana Haraharaini

+1 for Vulcan and his efforts

Thanks for your kind comments, poehere and sathyan You both (and many other members) offer excellent help too

After all those 'thank you' messages for Vulcan I suddenly feel compelled to express my gratitude for his help again as well :P

Somewhat related: after reading a few older threads in this forum I realized that it seems to be a bit of an open question how to handle total DR newbies (like me) that come to this forum after experiencing sudden HDD failure and googling for "DR advice" (again, just like me), and whether to give those newcomers any actual DIY advice or simply tell them to "go find a DR professional near you". Taking this dilemma into account, I appreciate even more the cautious, yet helpful advice I've received on here so far.

Finally, I vow I will never, ever put my HDD into a freezer for more than 2 hours to recover my data.

3 hours, tops. Promised!

* * *

re: smartmontools

Since I've never worked with that tool before I tested it on another HDD (in another external case with USB connector). The only result I got, despite trying several different versions of the '-d' argument of smartctl, was: "unsupported USB bridge".

I'm mentioning it because when I ran smartctl on my (possibly) damaged drive I wasn't sure if the result I got was due to my inability to make smartctl work, or a result of drive damage.

Anyway, running



on my damaged drive gave me




Then I tried



and got



That's all. Can you interpret the results for me, Vulcan? (although I'm afraid I already know your answer)


re: Kernel messages

I poked around in the log of the kernel messages, around the relevant time (i.e. when I mounted/unmounted the drive for the first time). The log mentions some NTFS-fs errors at 15:35:40 (line 2693), but I don't want to pretend I really know what I'm looking at in this log

I'm attaching a (partial) log of the Kernel messages, beginning at the time of mounting the drive, ending 2 hours later... perhaps, if you can find a minute, you could take a look at the log as well?

Aw shucks, thanks, and again you're welcome Some kind members offering their messages of support wasn't something I expected either, and it's very generous of them to do that. Seriously though, you've already said thanks earlier, which is more than some people do My day job is engineering in another part of the data storage industry and not in DR, so I also have limits about what I can help with, but since you've been using Linux then I've tried to use my experience there to help to diagnose the problem. Let's see what we can do together, with this latest info


Some older USB bridges simply cannot pass the special commands through to the drive, to read the SMART data. Having said that, it might be that you didn't yet find whatever specific "-d" argument is needed for that specific bridge. If you can get the part number off the top of the USB-SATA bridge chip in that enclosure, then this may help. The same applies to the bridge chip in the (different?) USB enclosure you are using for the "suspect" drive - its part number may also be useful (see below). I saw some info in the kernel log, but I didn't know which (if any) of the USB devices that I saw there, was either of the USB enclosures that you have tried.

Just FYI, I have an external drive whose USB-SATA bridge chip requires "-d sat,12" to allow smartctl to collect the SMART data - neither "-d sat" nor "-d sat,16" nor the default "-auto" setting (nor any others) will work. Some bridge chips will only work with a specific setting! However see below about the smartctl errors - yours may have a different cause.


I suspect the former is more likely, because your drive (last I heard) was still (at least partially) readable. However, I'm acutely aware of the risk of "diagnosing the drive to death".

To avoid doing further "trial & error" of the correct smartctl parameters using a potentially failing "suspect" drive, can I suggest that you use a different (preferably known-good, but unimportant) drive, for your testing trying to find a USB enclosure and the smartctl parameters to extract the SMART data from that drive? (The smartctl parameters won't change when you later swap the "suspect" drive into that same enclosure.)

Alternatively, even better (but perhaps more risky, due to the fragile connectors in laptops, amongst other reasons), you could put the "suspect" drive into a laptop (or other PC) so that it is attached to a SATA connector, not via USB, and boot Linux from another drive (or use a Live CD / DVD / USB which has smartmontools already installed). That way, USB and its limitations are not involved with the "suspect" drive.

In fact directly attaching a "suspect" drive via SATA is also the much, much better option, not only for gathering the SMART data but also if you do decide to go ahead and try to clone the "suspect" drive. It is fine for the target drive of the clone, to be attached via USB - we don't expect errors writing to that drive. It is typically not good for a "suspect" drive to be attached via USB, and then attempt to clone it. However, getting that text file containing the SMART data off that system, so you can attach it to your next reply, might be a little more difficult if you booted it from a Live CD / DVD / USB (e.g. write it to a mounted filesystem on a flash USB drive, or use an NFS-attached drive if you have one etc.) It all depends on what other systems & equipment you have available.


Don't take that "serious" error as necessarily relating to the drive - as I mention earlier, I suspect it's more likely that this was the USB-SATA bridge reacting badly to the smartctl command, or due to the problem which I describe next.

Actually, I'm not sure you were choosing the correct drive, for the smartctl command. From a quick scan of the kernel messages, the 320GB drive was sometimes sdb, not sdc (that was sometimes a 4GB Transcend USB flash drive). If that was the configuration when you tried running "smartctl -x /dev/sdc" then it's no surprise that you got errors reported by smartctl, since typical USB flash drives don't support SMART commands.

I've had a quick look at the kernel messages, and I suspect that not all useful messages are being logged there - that's not the first time I've seen this situation, but it's a shame for us. The syslog daemon can be configured to log only some types of messages - the NTFS messages clearly show they are getting errno 5 (i.e. I/O error) from an underlying driver (in your case, likely to be the HBA driver), but no errors from the HBA driver are being logged at that time. I can't commit the time needed to research Ubuntu settings in this area. If the errors had just occurred, and you hadn't yet rebooted so that _all_ kernel messages would still be in the memory buffer, then running "dmesg" (and redirecting that output to a text file) would likely contain the details needed. However gathering the SMART data may be easier, and would hopefully give some idea of what type of problem there is.

So in summary: Assuming that you still accept the (non-zero) risks of DIY diagnosis, then the quickest route to gathering the SMART data (and also the best chance of DIY cloning it later) would probably be to attach the suspect drive via SATA, make sure you've identified the correct /dev name for the drive and use smartctl as detailed before. If you can't do that, then use a different drive in a USB enclosure (again making sure to use the correct /dev name) and try to figure out whether you can find a smartctl "-d" parameter that will work with that enclosure. Then you can put your suspect drive into that enclosure and gather its actual SMART data for review. Hope that makes sense. Good luck!

Hey Vulcan

Thank you for your extremely helpful guidance and advice one last time. I decided to hand the HDD over to a DR professional.

Reasons: Under different circumstance I probably would have followed up on the route you layed out (get smartctl to work with the drive, if that gives at least moderately hopeful results, use ddrescue to clone the drive), but there's a number of problems. My main PC (in which the damaged HDD was housed) seems to have some additional problems (probably the mainboard), so I can't use it. Which means I can't attach the HDD via SATA. It also means I would have to use my extremely underpowered netbook (from which I'm writing) to perform the cloning... somehow the thought of channeling 320GB through a piece of plastic that occasionaly chokes on a fancy website doesn't sit well with me. Finally, because I don't have another SATA harddrive I can't experiment and get used to the necessary programs without using the damaged drive, which seems like a bad idea.

I hope you don't regret taking the time to guide me through this. Even though I didn't follow the DIY route in the end, I got a better understanding of what is (at minimum) involved in data recovery, and I won't be quite as unprepared for it when something like that happens again.

EDIT: the 320GB drive was in fact /dev/sdc. I had made sure of that beforehand via fdisk -l

... had to mention that otherwise I would look like a total idiot :P

Hi,

No worries at all, and thanks for the update. That decision seems very sensible - you wouldn't want to introduce additional problems with unproven equipment, unfamiliar programs and unpracticed procedures. Glad you got something out of the discussion anyway!

P.S. Regarding the device name used for smartctl - understood - as I mentioned, the device name for the 320GB drive changed at different times (as different USB devices were add/removed?) and sometimes it was indeed /dev/sdc but sometimes it wasn't. So based on your comment, I think (and hope!) the errors from smartctl were caused by problems sending the SMART command to the drive via the USB-SATA bridge. Good luck - I'll keep my fingers crossed