0

I was unable to recover my other account where I originally asked a question, so I'm hoping it's ok that I ask some follow up questions here

I'm looking to use ddrescue to clone a failing drive that I used to boot from in order to restore all the applications/settings etc that I had. I'm planning to run ddrescue on an ubuntu live usb, connect the failing drive to my computer's SATA interface and copy everything to a new drive via a USB enclosure

From @Kamil Maciorowski's answer, there seems to be subtle issues however where the USB enclosure might report the wrong physical sector size. If this happens when I write to the new disk via USB enclosure then I may not be able to boot from it because

the partition table in the copy does not correspond to the logical sector size used by the target disk.

If this is the case, instead of cloning the failing drive directly onto the new drive, it was suggested I copy the failing drive to an image file in a partition of the new drive. If I do this instead, then I could still mount the image file even if the logical sector size of the target disk is different from what's listed in the partition table

My questions are

  1. If I were to clone to an image file, after I mount the image, could I create a new bootable partition and write the image file to it so I can boot off the partition? (therefore getting around the issue with the partition table if I wrote directly to the disk instead). Alternatively, is there any way I can boot off the image file?

  2. Is there a way to check/do a test to see if the USB enclosure has the quirk where it reports the wrong physical sector size?

  3. How do I keep the source disk unmounted at startup if I have it connected via SATA cable at startup

  4. Is there any recommendation on the cluster size to use with ddrescue?

  5. It was also mentioned that if I were to copy directly to the target drive (instead of copying to an image file) then I might need to fix he secondary GPT after

If it's GPT then you will need to fix the secondary GPT. The copy of the secondary GPT from the source disk is now somewhere in the middle of the target disk; normally it should be at the end. And it may be that at the and there is an old secondary GPT from /dev/sdc that has nothing to do with the copy.

Would this only occur if the target hard drive is not brand new and there happens to be a secondary GPT already on it? If I'm using a newly bought target drive, do I not have to worry about that?

hddrecover
  • 41

1 Answers1

0

About the secondary GPT: yes, the problem still exists even if the new drive does not yet contain an existing GPT, unless the new drive has the exact same size as the source drive, which is unlikely. The secondary GPT has to be located at the end of the drive, and if you copy an image of the source drive to the beginning of a larger target drive, including the secondary GPT, it won't end up at the end of the drive.

Creating an image file is a way to get around the problem with differing logical sector sizes. Here's another idea: before you start copying, recreate the partition table on the target device using fdisk or gdisk. You don't have to make an exact copy, it suffices to make a single partition that has the same size as the partition you want to copy, and the location (starting sector) on the disk does not matter either. Then, instead of copying the whole disk, just copy the data inside the source partition to the target partition.

For example, let's say the source disk is /dev/sda and the partition you want to copy is /dev/sda1. If the target disk in the enclosure is /dev/sdb, create a partition table and a partition /dev/sdb1 that has the same size as /dev/sda1. Then, instead of trying to copy from /dev/sda to /dev/sdb, copy from /dev/sda1 to /dev/sdb1 instead.

Edit: this solution eliminates the problem with the secondary GPT, and you don't need to deal with an image file. However, the potential problem with the logical sector size mismatch still exists. The structure of the partition table is dependent of the sector size. If there is a mismatch, a disk partitioned while in the enclosure cannot be used when taken out of the enclosure, and vice versa. You can partition the disk while in the enclosure, and copy files to the partitions (including the aforementioned image file), but the disk is not usable outside the enclosure without re-partitioning it.

You can examine the sector size of the disk using sudo blkid /dev/XXX -o NAME,LOG-SEC.

Johan Myréen
  • 13,168