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.

  • Clonezilla with turned -rescue option in the "Expert" mode.
    – Alex
    Sep 5, 2018 at 20:54
  • @Alex What exactly does that do? I'd assume it just works like dd_rescue, by simply ignoring/skipping IO errors? That scares me off a bit, I'd greatly appreciate an elaboration on how this works and how safe it is to use.
    – confetti
    Sep 5, 2018 at 20:56
  • Yes, clonezilla trying to read multiple times broken sectors and if it failed then it go further to copy rest of content in the same way as dd_rescue doing it. I would try first to make an image with clonezilla to be make sure that at least existing data saved then try to "cure" ssd with low level tool such as mhdd or victoria in attempt to force internal ssd controller to replace broken sectors. Low level tool work good on mechanical drives but rarely helpful on ssd drives.
    – Alex
    Sep 5, 2018 at 21:06
  • @Alex I'm going to create an image using dd_rescue and then look into those tools.
    – confetti
    Sep 5, 2018 at 21:16
  • Be careful with dd_rescue, it trying very hard to read broken part of the disk that may trigger even more damage to SSD (when internal firmware trying to replace broken sectors with healthy ones but there no left spare cells).
    – Alex
    Sep 5, 2018 at 21:24

2 Answers 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.

  • 1
    That doesn't quite answer my question. I'm not using the SSD anymore and I agree on your points, however a "full clone" is what I'm trying. AFAIK does clonezilla's clonepart not work with full disks (correct me if I'm wrong please), and clonezilla's dd is essentially the same as using dd from another system. By the way: I'm trying all of this on a live manjaro system, with the SSD being unmounted and locked. Also, using pv or dd, a copy is done sector-by-sector too. A "cloning OS" does not much more than use regular UNIX tools.
    – confetti
    Sep 5, 2018 at 20:44
  • @confetti Clonezilla can do full disk cloning when you choose disk-to-image or disk-to-disk option
    – Alex
    Sep 5, 2018 at 21:26
  • @Alex I'm asking about the underlying tool clonezilla uses to do the cloning. I haven't used clonezilla in a while, but I remember the last time I used it to clone a disk it was using dd.
    – confetti
    Sep 5, 2018 at 21:30
  • NO, clonezilla using dd only if you asked it about this.
    – Alex
    Sep 5, 2018 at 21:37
  • @confetti It used underlying tool in this order: partclone (default), partimage (optional), ntfsclone (optional), or dd as last resort when it cant figure out filesystems
    – Alex
    Sep 5, 2018 at 21:43

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.