Answer by Kamil Maciorowski for Can I use a partition as ddrescue destination?

Short answer

You can use a partition as the outfile of ddrescue and the tool will not "format the whole disk", but almost certainly working with such copy will be somewhat complicated. If you don't want to use a whole block device (like your large disk) then write to a regular file in a filesystem (which may be on your large disk).

How things work (ddrescue, partitions and such)

ddrescue reads from a file (infile in terms of man 1 ddrescue) and writes to a file (outfile). Note that "file" is a broad term. In the context of ddrescue we should consider regular files and block devices (disks, partitions). The important thing is you can read a regular file or a block device from its beginning to its end and you get a sequence of bytes.

ddrescue copies the infile to the outfile; it's like cp with ability to skip read errors, to retry, to resume, to work backwards. If there are no read errors and the outfile is a regular file in a filesystem with enough room then ultimately the outfile will be a copy of the infile, i.e. if you read one and the other from the beginning to the end then you will get two identical sequences of bytes.

If there are read errors then the outfile might not be a perfect copy, the mapfile will tell you which parts of it came from the infile and which are just placeholders.

If the outfile is a block device, remember that writing to a block device can neither truncate nor expand it. If the block device is too small then you will get an incomplete copy. If the block device is just right then you will get a perfect copy (unless there were uncorrected read errors). If the block device is too large then you will get a copy with extra bytes at the end.

Anyway, the most important thing is ddrescue tries hard to copy the content of one file to the other file. The goal is to do what cp does. The algorithm and the mentioned abilities are just means to "try hard".

If there are no read errors then you can get the same result with cp infile outfile. There are more tools that can do the job (see the second half of this answer).

You want to copy a whole device, your smaller disk. A whole device (like /dev/sdx in Linux) almost always contains a partition table that tells the OS which fragments of the whole device should be exposed as separate block devices we call partitions (/dev/sdx1, /dev/sdx2, …). When a program opens a partition and reads from or writes to it, it's like accessing any other seekable file. The OS translates this to accessing the whole device, it takes care every access happens with the right offset and it does not let the program reach fragments outside of the partition.

A partition usually contains a filesystem. In other words the sequence of bytes you can read from it is a structure we call filesystem of some type. Operating systems expect (almost) each partition to contain a filesystem.

A whole device may directly contain a filesystem. This is called "superfloppy". Such setup is possible, yet uncommon and not recommended.

A whole device almost always contains a partition table and then filesystems (where the fragments being the partitions are), possibly with some null bytes, junk or whatever in between. This resembles a simple filesystem. It's a "filesystem" specific to whole devices, nobody/nothing expects it inside an actual partition.

Consider cp infile outfile, it overwrites the outfile without writing to any other_file. It's similar with ddrescue: if you tell it to write to /dev/sdx3 then it will overwrite this exact partition without writing to /dev/sdx1, /dev/sdx2, /dev/sdx4 etc. (unless the partitions overlap, which would be a pathological situation in the first place). It will change the content of /dev/sdx (the whole device) only because the sequence of bytes one can access by opening /dev/sdx3 is a sub-sequence of bytes one can access by opening /dev/sdx. Still it will not change the partition table of /dev/sdx, because the partition table is outside of /dev/sdx3 (unless the partition overlaps the partition table, which would be another pathological situation).

So no, ddrescue will not format the whole disk, it will just overwrite the target partition. Note even when you ddrescue a whole disk to another whole disk, a partition table and filesystems appear on the target disk not because of "formatting" performed by ddrescue. They appear because they are sub-sequences of bytes inside the sequence of bytes copied as-is (unless there are read errors) from one disk to the other; later the OS interprets them. In this aspect ddrescue is dumb like cp that can copy AVI, PDF or any other regular file, without knowing anything about AVI or PDF, and without being able to create AVI or PDF from scratch, and without being able to edit it; later your media player or your PDF reader interprets these files. You can even use ddrescue to read as much of a regular file as possible.

What you can get

If your smaller disk is a superfloppy (no partition table, a filesystem directly on the whole device) then copying it to a partition of the larger disk will create a usual situation where a filesystem is inside a partition, something that every operating system expects. You will be able to mount the filesystem from the copy, unless read errors while copying severely crippled it (but even then data recovery will be straightforward in principle). I don't expect your smaller disk to be a superfloppy though.

Most likely your smaller disk contains a partition table, partition(s) and filesystem(s). If so, copying the whole of it to a partition of the larger disk will create an unusual situation where there are partitions nested in a partition, AFAIK no operating system expects this. In effect the "inner" partitions (copied from the smaller disk) will be "invisible" (e.g. in Linux they won't automatically appear in /dev/). There are tools (e.g. partx, kpartx) and ways (mount -o offset=…) to get to them and their filesystems.

Consider copying the smaller disk to a regular file. Working with such file is as easy as working with a partition, at least in modern Linux. Namely:

• If the smaller disk is a superfloppy then the file will contain a filesystem and you will be able to mount it with mount /path/to/file /mountpoint (again, unless read errors while copying severely crippled the filesystem). Modern mount can mount a regular file, it creates a loop device automatically. (Creating a loop device "manually" is possible with losetup.)

• If the smaller disk contains a partition table then the file will contain a copy of it. fdisk -l /path/to/file or gdisk -l … will show you the table (unless read errors…). mount -o offset=… should work (unless…). You can use partx or kpartx. Modern losetup can create loop devices for the file and for partitions within. Example:

  losetup --partscan --show --find /path/to/file

You can achieve similar results with a copy written to a partition; still a regular file has some advantages:

• Depending on the filesystem where you put the file, the file may be compressed or at least sparse.
• If the filesystem supports reflinks, it's a good idea to make a reflinked copy of the file and make it read-only. The point is sometimes you need to modify the filesystem(s) inside the file in order to rescue data (e.g. you fsck a filesystem crippled because of errors while reading from the source), but there's a risk this will make the situation worse. Thanks to the copy you can always start over; reflinking avoids actual copying that takes time and diskspace.
• You can use an existing filesystem with enough space (there is no need for repartitioning). When the file is no longer needed, just delete it (there is no need for repartitioning again).
• You can give the file a descriptive name, you can protect it. A partition with unrecognized content "begs" for a filesystem (e.g. some overzealous operating systems may ask if you want to format it; one click to disaster).