14

I am trying to clone a 500 GB SSD to a 1TB SSD. For some reason, it keeps failing when the data being copied reaches 8GB. This is the third 1TB SSD I've tried this on and they all get stuck at the same place. I've ran the following command:

dd if=/dev/sda of=/dev/sdb bs=1024k status=progress

I've also tried to clone the drive using Clonezilla which fails at the same spot. I used GParted to reformat the drive and set it to a EXT4 file system but it still gets stuck at the same spot. Sda is internal and sdb is plugged in externally.

The error I'm getting says:

7977443328 bytes (8.0 GB, 7.4 GB) copied, 208s, 38.4 MB/s
dd: error reading '/dev/sda': Input/output error
7607+1 records in
7607+1 records out

Thanks to @roaima for the answer below. I was able to run ddrescue and it copied most of the data over. I took the internal SSD out and connected both the new and old SSDs to a CentOS box via USB3. I ran the following:

ddrescue -v /dev/sdb /dev/sdc tmp --force

It ran for over 15 hours. It stopped overnight. But the good thing is it picked back up where it left off when I ran the command again.

I used screen so that I wouldn't be locked into a single session the second time around :) . I used Ctrl+c to exit the ddrescue command after 99.99% of the data was rescued since it was hanging there for hours. I was able to boot from the new drive and it booted right up. Here is the state where I exited the ddrescue:

Initial status (read from mapfile)
rescued: 243778 MB, tried: 147456 B, bad-sector: 0 B, bad areas: 0

Current status
     ipos:  474344 MB, non-trimmed:    1363 kB,  current rate:       0 B/s
     ipos:  474341 MB, non-trimmed:        0 B,  current rate:       0 B/s
     opos:  474341 MB, non-scraped:   522752 B,  average rate:   8871 kB/s
non-tried:        0 B,  bad-sector:   143360 B,    error rate:       0 B/s
  rescued:  500107 MB,   bad areas:      123,        run time:  8h  1m 31s
pct rescued:   99.99%, read errors:      354,  remaining time:     14h 31m
                              time since last successful read:      6m  7s
Scraping failed blocks... (forwards)^C
  Interrupted by user

Hopefully this helps others. I think my old drive was starting to fail. Hopefully no data was lost. Now on to resizing the LUKS partition :)

blacKnight
  • 303
  • 20
    I would hazard a guess and say that you have a hardware problem on sda. Not sure why you would believe it is sdb. – Bib Dec 02 '21 at 17:28
  • 6
    For starters, don't use dd. I know every tutorial says to use it, but it's pointless at best, counterproductive at worst. Use cat or pv, or more dedicated tools like ddrescue. – marcelm Dec 03 '21 at 09:26
  • 2
    My first thought was that it could be a counterfeit SSD of 8 Gb sold as a 500 Gb: https://www.geckoandfly.com/22803/detect-fake-usb-flash-drives-sd-cards-ssd-disk/ Are you sure it contains 500 Gb of data? – dr_ Dec 03 '21 at 12:53
  • I had this same issue when using a cheap USB->SATA with broken UASP support. Disabling UASP helped: https://leo.leung.xyz/wiki/Disable_UAS – Manawyrm Dec 05 '21 at 10:39

2 Answers2

46

The error is, dd: error reading '/dev/sda': Input/output error, which tells you that the problem is reading the source disk and not writing to the destination. You can replace the destination disk as many times as you like and it won't resolve the issue of reading the source.

Instead of using dd, consider rescuing the data off the disk before it dies completely. Either copy the files using something like rsync or cp, or take an image copy with ddrescue.

ddrescue -v /dev/sda /dev/sdb /some/path/not/on/sda_or_sdb

The last parameter points to a relatively small temporary file (the map file) that is on neither /dev/sda nor /dev/sdb. It could be on an external USB memory stick if you have nothing else.

The ddrescue command understands that a source disk may be faulty. It reads relatively large blocks at a time until it hits an error, and at that point it marks the section for closer inspection and smaller copy attempts. The map file is used to allow for restarts and continuations in the event that your source disk locks up and the system has to be restarted. It'll do its best to copy everything it can.

Once you've copied the disk, your /dev/sdb will appear to have partitions corresponding only to the original disk's size. You can use fdisk or gparted/parted to fix that up afterwards.

If you had an error copying data you should first use one of the fsck family to check and fix the partitions. For example, e2fsck -f /dev/sdb1.

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
7

There is an error on the source medium and dd, by default, stops on the first error. The canonical solution for copying partially-bad source media involves giving it the "conv=noerror,sync" options. This tells it to ignore the bad bits, replacing them with nulls, and continue on. The block size you're using should match that of the filesystem in this case, else a little-bitty bad 'sector' will take out an entire dd-block. (You will lose additional data, besides what is bad on the source medium.)

So, while dd can do the job, and has been used to do exactly this for decades, there are likely other tools that might be better suited.

jcathey
  • 71
  • 1