Answer by Kamil Maciorowski for Safest way to back up old, failing drives?

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.