How to properly clone a slightly damaged SSD onto a new one

Question

So recently my old SSD (containing /root + /home partitions for my system) broke (details in this question) and I went to get a new one. Now I wanted to clone it but ran into the following issues:

$ pv /dev/sdd > /dev/sda
4.24GiB 0:00:18 [ 234MiB/s] [==>                          ]  7% ETA 0:03:55
pv: /dev/sdd: read failed: Input/output error

$ dd if=/dev/sdd of=/dev/sda bs=1M status=progress
dd: error reading '/dev/sdd': Input/output error
4397+1 records in
4397+1 records out
4611493888 bytes (4.6 GB, 4.3 GiB) copied, 22.0249 s, 209 MB/s

The old SSD still kinda works. There are lots of system freezes due to it being damaged but I can unlock, mount and use it quite fine still. I can access all data (AFAIK) and a full backup using tar worked well too.

The reasons I would greatly prefer a direct clone over file-by-file (or tar) copying is:

1. Convenience
2. Speed
3. Rather complex encryption on the disk, that I'd rather not re-setup again

This website suggests using conv=noerror with dd, but I'm unsure whether this is safe or not. I have the same concerns about dd_rescue and clonezilla's -rescue.

Question: How can I safely clone my old SSD onto the new one, and is a md5sum check afterwards sufficient to make sure the clone was 100% successful?

The website I've linked above suggests using gparted to check if the clone was successful, but AFAIK gparted doesn't work with LUKS encrypted partitions. (To make things more complicated: The LUKS header is detached.)

Bonus question: My drive's decryption is done at boot, using grub and the partitions's ID (not UUID). Is it enough for me to update the ID in my crypttab and grub's config or do I need to do more?

---

Edit: I just realized that md5sum will most likely fail to read the drive aswell. Is there any other way to safely tell if the clone was successful?

---

UPDATE: So I've tried clonezilla with the -rescue option. It seemed to work and I can unlock the LUKS container to reveal the LVM but when I try to mount the root partition I get the following:

$ sudo mount /dev/mapper/vvg-root /mnt/sda
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vvg-root,
       missing codepage or helper program, or other error

Relevant data from dmesg:

[ 4686.401702] JBD2: no valid journal superblock found
[ 4686.401707] EXT4-fs (dm-3): error loading journal

So I guess that didn't work as planned. Has anyone a better idea, please?

---

UPDATE2: I ran a fsck.ext4 -yv on the new drive's partition. I was flooded with errors. In the millions. Now I'm able to mount it, but pretty much all of my files are missing. The /home directory, among many others, is gone entirely. There should be around 30-35GB of data on it. Now it's 53MB.

Is my only option really to rollback the tar backup I have? I'm thinking maybe a one-on-one rsync copy is better, since that would report if a specific file is damaged/unreadable, right? I used --verify when I made the tar archive though and it didn't report any errors.

Answer 1

^{After doing what I stated in my question, I ended up doing the following:
1) Remove the LVM on the new SSD after the failed CloneZilla copy.
2) I kept the outer dm-crypt untouched, since it worked well.
3) I re-created a new LVM and resized everything to fit the new (bigger) SSD.
(This is only relevant to my case, hence the smaller font, see question updates)}

Now for the cloning:

1) I mounted both SSDs' root partitions normally in a live system after unlocking them:

# unlock the LUKS containers with cryptsetup first
mount /dev/mapper/ovvg-root /mnt/oldssd
mount /dev/mapper/vvg-root /mnt/newssd

2) I used rsync to clone the files:

rsync -ahv --progress /mnt/oldssd /mnt/newssd

3) Confirmed that the size of all folders match:

du -cs /mnt/oldsdd/* && echo " " && du -cs /mnt/newssd/*

4) Confirmed that all the files are there, to double-check:

find /mnt/oldssd | cut -d "/" - f 4- | sort > oldssd.txt
find /mnt/newssd | cut -d "/" - f 4- | sort > newssd.txt
diff oldssd.txt newssd.txt

Eight files weren't present in newssd.txt so I assume those had read errors. I ended up leaving those files alone as I have backups, I will copy them manually later.

5) Satisfied my paranoia further by checking on checksums:

cd /mnt/oldssd && find . -type f -exec md5sum {} \; | sort > /root/oldssd_md5.txt
cd /mnt/newssd && find . -type f -exec md5sum {} \; | sort > /root/newssd_md5.txt
cd /root && diff oldssd_md5.txt newssd_md5.txt

No output at all - Meaning every file is the same!

As for the bonus question:

1) Change device path (using UUID) in /etc/fstab
2) Change device path (using by-id) in /etc/default/grub
3) Since I can't chroot into my system right now I modified the grub.cfg directly to reflect the change of the disk's by-id - However the better practice is to not do this and instead chroot into the root system and re-configure the GRUB bootloader. I immediately did this after being booted into the system from the new SSD.

More complicated than I wish it would've been, but at least it worked, safely.

Answer 2

Firstly, I'd recommend to not use the SSD or run tests on it because it could cause the drive to continue failing, I once had a drive that I was repairing and after running some integrity checks on it, it wouldn't let itself be read at all. If you are still able to see it from a separate system, then it should still be saveable, though usage can cause the chips to stop reading, so I'd try a full clone before doing anything else. I recommend using Clonezilla from USB as to keep the SSD away from unneeded read/writes during cloning. when you've cloned it, md5sum would the best way to confirm it's all there, although it may not be reliable if it's failing. A bonus to using a cloning OS or hardware cloner is that all the data is copied sector by sector.