Cloning data from a damaged SSD

Question

The SSD went into read-only mode, so you need to move the partition to a working SSD, but I encountered the fact that the LVM size is different:

#lvm pvscan

PV /dev/sdc3 VG pve lvm2 [<111.29 GiB / 13.87 GiB free]

PV /dev/sdb3 VG pve lvm2 [<118.74 GiB / 14.75 GiB free]

It will not be possible to transfer through DD due to the difference in volume.

sudo dd if=/dev/sdb3 of=/dev/sdc3 status=progress

What other ways are there? Maybe there is software to clone partitions from under the BIOS?

UPD: Both SSDs are connected via an NVME-usb adapter. I am working through live linux on iODD-2531. And I, in turn, connect to the system via ssh.

Copying from a 128gb drive to a 120gb drive. If the first drive wasn't write-protected, I could try to reduce the size of the partition, and then copy using DD.

UPD:

I connected a 500GB drive for the test and started copying using DD. As a result I get an error:

ubuntu@ubuntu:~$ sudo dd if=/dev/sdd of=/dev/sdc status=progress
456839680 bytes (457 MB, 436 MiB) copied, 53 s, 8.6 MB/s
459821568 bytes (460 MB, 439 MiB) copied, 57 s, 8.1 MB/s
461292032 bytes (461 MB, 440 MiB) copied, 59 s, 7.8 MB/s
569393664 bytes (569 MB, 543 MiB) copied, 72 s, 7.9 MB/s
709820928 bytes (710 MB, 677 MiB) copied, 85 s, 8.4 MB/s
dd: error reading '/dev/sdd': Input/output error
1388520+0 records in
1388520+0 records out
710922240 bytes (711 MB, 678 MiB) copied, 93.8062 s, 7.6 MB/s

This is a copy error. SSD patriot p300, it continued to degrade and more than 50% of bad sectors. The topic can be closed. The drive is dead. Thx.

Answer 1

Clonezilla might come handy in your situation. You can definitely copy mismatched partitions with it!

https://clonezilla.org/

Answer 2

Do you have to do it at partition level? It might be easier to move the files instead, as you wouldn't need to mess around with shrinking the old filesystem or anything like that. A cp -avx will do the job just fine with moving an OS, although rsync -avxHAX may be better if there's a need to interrupt and resume.

1. Prepare (mkfs) the new filesystem.
2. Mount both old and new filesystems and copy everything using cp -avx /old/. /new/
3. Edit /mnt/etc/fstab and other config files to match the new filesystem's UUID.

Answer 3

Disk cloning is the process of making an image of a partition or of an entire hard drive. This can be useful for copying the drive to other computers or for backup and recovery purposes.

Note: Disk cloning between drives with different logical sector sizes is not advised. Moving to a drive with a smaller logical sector size (e.g. from 4096 bytes to 512 bytes) will require recreating the partition table since partition boundaries are specified in sector numbers. Moving to a drive with a larger logical sector size (e.g. from 512 bytes to 4096 bytes) may not be possible at all if a file system's block size is less than target drive's logical sector size or is not divisible by it.

Tip: Over time file systems get new features and the mkfs utilities change their defaults, but not all new features can be enabled without reformatting. So, when moving data to a new drive, instead of cloning the block devices or file systems, consider creating a new file system and only copy the files (and their attributes, ACLs, extended attributes, etc.) with e.g. rsync.

Check this sources to get more details about different tools and what fit your needs:

Disk cloning tools

1. Block-level cloning

dd

The dd command is a simple, yet versatile and powerful tool. It can be used to copy from source to destination, block-by-block, regardless of their filesystem types or operating systems. A convenient method is to use dd from a live environment, as in a Live CD.

ddrescue

GNU ddrescue is a data recovery tool capable of ignoring read errors. ddrescue is not related to dd in any way except that both can be used for copying data from one device to another. The key difference is that ddrescue uses a sophisticated algorithm to copy data from failing drives causing them as little additional damage as possible.

2. File system cloning

e2image

e2image is a tool included in e2fsprogs for debugging purposes. It can be used to copy ext2, ext3, and ext4 partitions efficiently by only copying the used blocks

3. Versatile cloning solutions

Clonezilla

A partition and disk imaging/cloning program which helps with system deployment, bare metal backup and recovery.

Deepin Clone

Tool by Deepin to backup and restore. It supports to clone, backup and restore disk or partition.

FSArchiver

A safe and flexible file-system backup/deployment tool

Mondo Rescue

A disaster recovery solution to create backup media that can be used to redeploy the damaged system.

Partclone

A tool that can be used to back up and restore a partition while considering only used blocks.

Partimage

An ncurses disk cloning utility for Linux/UNIX environments.

Redo Backup and Recovery

A backup and disaster recovery application that runs from a bootable Linux CD image.

System Tar & Restore

Backup and Restore your system using tar or Transfer it with rsync

Another list of tools, with some features

Disk cloning software facilitates a disk cloning operation by using software techniques to copy data from a source to a destination drive or to a disk image

Comparison list of disk cloning software

Answer 4

You have to shrink the PV before cloning it with dd, but read only status of the SSD prohibits this.

But, using an overlay difference image you can still do it. In general it is the same as I described in detail in the other answer. I'll describe only differences here.

1. Create a difference overlay scratch image file with physical backing device — old SSD, in qemu-img arguments have -b /dev/sdb3.
2. Load the nbd driver and attach the image file as NBD disk with qemu-nbd. That device will be read-write, it will initially contain whatever the backing device (old SSD) had, but changes will be written into the qcow2 file (so the read-only status of the old SSD will not interfere with writes to the NBD).
3. Now, it is possible to shrink the PV on the NBD device. Since it shouldn't involve much data movement, the scratch qcow2 file will not grow much. Reduce it so it matches (or slightly less) than the partition on the second SSD. You have to use something like pvresize --setphysicalvolumesize 111G /dev/nbd0 (if you attached it as nbd0 on previous step).
4. After it is reduced, you can use dd from the NBD device. Better disuse the target partition and remove any leftover labels from it (use wipefs) prior to cloning to it.

The same setup (read-only backing device and read-write overlay) could be achieved with device-mapper built-in overlay capability and sparse overlay image instead of using Qemu's image tools and NBD, as explained on the RAID wiki, but I never did it that way.

---

Edit: Since this appeared in the comments I think I need to add it here too. If you have a spare backup space (external HDD or something), big enough to store an image of the original device, do it, take a dump. ddrescue tool is very useful for this task, as it:

• works around unreadable blocks, filling them with zeros
• maintains a state ("log") file where it remembers which blocks were successfully copied, which were found unreadable and which weren't tried yet
• you can safely restart it using the same source, destination and state file. Also it is possible to reset unreadable blocks to non-tried state, so it will retry them during the run.

This makes it possible to fully copy devices which overheat or otherwise fall offline after doing some work and overall unstable. Just be patient, after several runs it will pull all the data possible to recover.

After that, use this image instead of the original dying device. You can use it the way I explained above, e.g. setup another overlay image which will store the differences. You'll have infinite attempts, by not changing the original image and recreating overlay images again and again as needed.