An external hard disk recently started failing, so I bought a new one and partitioned it at approximately the same sizes, although a few turned out slightly smaller. The old partitions were nowhere near full.

I copied the old partitions one by one using dd:

(and same for sda3 etc.). For the partitions that were slightly smaller (including sbd2) I got a "no space left on device" error at the end. After this, running fsck on sdb2 gives an error:

I assume this is because dd writes data including the old superblocks to the new partition, which means that I probably want to regenerate the superblocks. When searching for solutions to the error above, all seem to use resize2fs to resize the partitions. Will this recreate the superblocks etc. but keep the partition table intact?

Another option seems to be to start over and simply copy the whole disk with dd if=/dev/sda of=/dev/sdb; will this work even if the new disk is a different brand (but approx. same size) and has different sector sizes etc.?

"dd" writes every block that it can read, even if it is in error. There are much better alternatives - ddrescue for example.
What you have done is truncate the filesystem - check the arithmetic in the messages you cited above. This is never going to work - ensure the target partition is at least as big as the source, or use a file-aware tool that will only copy the used portiions of the filesystem.
Copying the whole disk may mess with the architecture of the target disk - less of an issue these days, but I don't ever do it; partition by partition gives much better control over the whole affair.

1 members found this post helpful.

Thanks for your reply. I understand that I should stick to copying partition-by-partition.

The problem with using a file-aware tool (I assume you mean something like cp -R) is that because of the disk problems, I have trouble mounting the old file systems. So I have two questions:

• If I'm willing to accept that the partition is truncated (and thus lose small amounts of data), how do I clean up the file system structure?
• The alternative to accepting a truncated file system is to re-partition the new disk to exactly match the old one and copy the data again using dd or ddrescue, right? I'm not sure if I'm able to create exactly the same size for the last partition (i.e. since the sector structure is different for the new disk, it might be a tiny bit smaller), so if that happens, how do I clean up the file system structure? for this last partition, I can probably repair any errors this might create.

Truncating the file system invalidates it - you (effectively) lose the lot, not just a bit. After that is forensic recovery - slooooow and indefinite.
Seems you bought a second disk of the same (FSVO "same") size. Newer tools align new partitions differently, especially on the newer devices with bigger physical blocks. This might explain why you can't allocate all the partitions the "same" (FSVO ...) size. If it was me, I would work on just the partition that could give back the most space. Get it across to the new disk using a larger size, fix the filesystem, shrink it to release space, then shrink the partition to match (gparted is good for this), then work on the other partitions on the now larger than strictly required free space.

Recovery is always more work simply restoring from a current backup.

1 members found this post helpful.

Thanks again. I'll start over with partitions that are large enough. So, to summarize my understanding of your suggestion:

1. Re-partition the new disk with partitions that are same or larger size (number of blocks), if possible. If not, do not create last partition yet.
2. Copy data to partitions that are sufficiently large, using dd or ddrescue
3. If necessary, shrink recovered partitions to free space, create last partition and copy data
4. Resize partitions to desired size

Looks like a plan.