Partially dead drive

[D. Hugh Redelmeier]

| From: sciguy <sciguy-Ja3L+HSX0kI at public.gmane.org>
| To: tlug-lxSQFCZeNF4 at public.gmane.org
| Date: Sun, 04 Aug 2013 10:26:05 -0400
| Subject: [TLUG]: Partially dead drive
| Reply-To: tlug-lxSQFCZeNF4 at public.gmane.org
| 
| I have a 1TB Seagate drive which, I admit, was partitioned when the NT drive
| was less than half full, and I didn't defrag the data to the start of the
| drive.

Why do you have to "admit" that?  Are there any consequences?

<Superstitious mode> When I've used Linux tools to resize a Windows
boot partition, I've found it important to immediately boot Windows
and do a repair.  This is before installing Linux.  I think that the
resizing might be moving unmoveable files and the Windows repair tools
can fix that. </superstitious mode>

Windows (without 3rd party tools) can resize its own partitions but it
seems to not wish to move any unmoveable files (like perhaps SWAP) and
so it cannot shrink as much as one would like.  Getting rid of the
swap file (somewhere in settings) temporarily might help

| It lasted a couple of months that way, then it all but bricked my
| computer. While the NT (W7) system partition was on a separate drive, GRUB was
| the MBR of the bad drive. The partitioning on the bad drive was done to
| install Linux. The NT partition on the bad drive was used for various data (no
| programs or system files) which I wanted to at least make a valiant attempt at
| trying to recover.

So: you are saying that the problem is raw disk I/O errors.  Nothing to
do with partitioning.  But symptoms and recovery methods involve
partitions and file systems.  Right?

| All of the linux partitions seemed to have survived somehow, but when mounting
| the NTFS partition, I get an I/O error, even when booting with parted magic
| (live mode).

Disks often go bad in a number of spots.  Often, an increasing number
of spots.  The bullet holes in a filesystem don't always hit vital
organs.

If you care, the very FIRST thing you should do when you have trouble
like this, and you care at all about your data, is capture an image of
the disk (or perhaps images of partitions) onto somewhere safe.

Why?

- disks have a way of getting worse.

- (superstition) sequential reads of a disk might be more successful
  than random access reads

- fsck and friends may make things worse.  Just one way: terminating
  half-way through

- you, the human, can easily make fatal mistakes in the heat of
  battle.

The best tool I know (which isn't saying much) for capturing the image
is GNU DD Rescue (confusingly there are three different programs
called ddrescue).
<http://article.gmane.org/gmane.org.user-groups.linux.tolug/61318>

There's a lot to like about ddrescue but the documentation isn't that
comforting to a panicking user.  Hints:

- always invoke it with a logfile parameter.  That's where it keeps
  track of what's done, what's failed, what's untried, etc.

- the first time you run it, don't ask it to retry.

- When it's done the first run, you can run it again (with the same
  logfile!) and ask it to retry.  I found that the retrying eked out a
  little more from the disk, but very slowly.

| The data in the NTFS partition is worth some trouble in trying to at least
| partially recover data. Is there anything anyone might suggest that I haven't
| tried?

smartmontools are useful.  They let you get at the S.M.A.R.T.
capability of the drive.  Mind you, most external USB cases fail to
support S.M.A.R.T.
	smartctl -a /dev/whatever
tells you lots of stuff.  Unfortunately, most firmware tries to make
reports optimistic in several ways.
	smartctl -t short /dev/whatever
starts an offline short self-test.  When the time is up, you need to
do a smartctl -a to see the result.
The long test is useful too, but long.

When disks fail partially, it matters where the bullet holes end up:
metadata (think partition table, inodes, directories) or data or even
unused space.

fsck and chkdisk (is that actually what it is called these days?)
fix metadata.

There are tools (that I don't remember and haven't needed) that grovel
through the raw bits of a disk and try to find things that seem like
JPEG files.  Being undermotivated, I will suggest googling.  But
here's a long article that might be helpful (I've only glanced at it):
<http://www.dedoimedo.com/computers/linux-data-recovery.html>
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists