Safest way to back up old, failing drives?

Question

I have a number of old hard drives (some IDE, most SATA). Some years ago I powered them up and attempted to restore all files through an undelete program, and got some files. I'm not convinced I did a good job, so now I'd like to try again.

My assumption is that a sector-by-sector approach would be best, since that should catch every bit of data and then I can try as many times as I like to recover any files that might remain in the image. I'm aware that attempting my own recovery reduces the chance of successful professional recovery, but I'm really only hoping to recover some files I vaguely remember from my childhood so it's not that important.

What's the safest way to create some sort of sector-by-sector image of my old drives, considering there may be many failed sectors?

I'm familiar with Linux and have Mint dual-booted on my laptop, but I've never used DD and I'm not sure if I should be learning to use that or finding another tool.

Answer 1

In general there are at least two strategies:

1. Copy the whole of the disk with a tool designated to deal with read errors. The standard tool is GNU ddrescue, I have used it many times to image block devices.

   GNU ddrescue does not care about a partition table or filesystems, its job is to read as much of the drive as possible, while trying to rescue the good parts first in case of read errors.

   ^{(I've heard good things about HDDSuperClone, but I have never used it (yet).)}

   In the best case you will get a perfect image of the drive, including any remnants of previously deleted filesystems or files; so any attempt to undelete or recover such files will work to the same or to a higher degree as if you used the original drive. Possibly "to a higher degree" because the assumption is the original drive is likely to fail under strain, but a copy/image once created and properly stored on healthy drive(s) is firm and can be worked with without risking anything.

   In the worst case the sole attempt to create a full image will turn out to be the strain that kills the source drive. To mitigate this risk, there is the other strategy.

2. Copy the desired filesystem by using a tool that understands it and deliberately skips the parts of the drive the filesystem does not use. The idea is there is no point in trying to read sectors not currently used by the filesystem, because even a successful read will give you nothing anyway, while still being a strain that may kill the disk before the whole operation completes.

   For this to work, the basic structures of the filesystem must be intact. You need a tool specific to the type of the filesystem. For NTFS, see this question: How can I find out which sectors are used by files on NTFS?

   This strategy deliberately skips sectors not currently used by the filesystem. In general the majority of data you could potentially undelete exists in such sectors, this data will be lost. The strategy aims at maximizing chances of copying the current state of the filesystem, but nothing more.

You mentioned an attempt "to restore all files through an undelete program". You want to try again. If so, then the first strategy is the one for you.

Notes:

• With the first strategy you can copy a whole block device (e.g. /dev/sdc in Linux). I assume there is a partition table. If the partition table is intact then copying to another block device (e.g. /dev/sde) will "create" the partitions there (the kernel will give you /dev/sde1 etc. after partprobe) and working with them will be quite straightforward. Copying a whole partitioned block device to a regular file is somewhat problematic later, because you need to know how to access "partitions" existing inside the regular file (in case you want to do this, in Linux the tools are losetup --partscan, partx, kpartx). For this reason, if you want to copy to regular file(s), it's often better to copy each partition to a separate file.

  With the second strategy you copy a filesystem which almost always exists inside a partition (e.g. /dev/sdc1 in Linux).

• Personally I prefer copying to regular files on a Btrfs. First I make the copy immutable (chattr +i) just in case. Next I create a reflinked copy of the copy (cp --reflink=always). Then I work with this "secondary" copy, so even tools that need to modify the image can work, but I still have the immutable copy to start over in case anything goes wrong. Such carefulness is possible without reflinks, by actual copying, so in any filesystem; reflinking greatly saves time and disk space though.

• Still, Windows and (recovery) tools in Windows may require the copy to exist on a block device. I don't know Windows well enough to tell how easily it can nowadays pretend that a regular file is a block device (like Linux can with losetup). One generic way to use a disk-copy-in-regular-file with some OS (e.g. Windows) is to connect the copy as "HDD" to a virtual machine running the OS.

• If there is Btrfs on the cloned drive then do not try to mount the copy while the original is still connected (nor the other way around). The reason is they will share the UUID that identifies the filesystem and by design they will be interpreted as parts of a single filesystem, not two distinct ones. See How to copy a btrfs filesystem for some useful ideas.