Score:5

Cloning data from a damaged SSD

kw flag

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

enter image description here

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.

br flag
That pvscan output suggests that both SSDs are in use already. Copying one over the other would be a bad idea then.
c4f4t0r avatar
nl flag
you have 2 physical volumes in pve vg, first you need to check the status of your logical volumes using lvs -ao +seg_le_ranges
Джон Смит avatar
kw flag
@SimonRichter 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.
br flag
I mean, both sdb3 and sdc3 have a PV on them, which is assigned to a volume group, and there are about 100 GB used on each and less than 100 GB free, so there isn't enough free space to keep all the data on just one. The `dd` command you suggested would overwrite the contents of one PV with that of the other, destroying data in the process. You need an additional storage medium with enough space. I think you should be able to use LVM to copy the data, which would solve the size difference problem, but I'm not entirely sure how it reacts to being unable to update metadata.
br flag
Simon's right, though: According to your `pvscan` output, both of your drives are ~ fully allocated already. If you created a logical volume or volumes on the destination drive, you **shouldn't** do that if you want to migrate or mirror your source LVs ­— you need _free_ extents on the destination PV(s). ...You didn't show your LVs, but if source PV holds multiple LVs, you can mirror them to different destinations. Heck, even if it's just one LV, you can juggle LVM volumes at the _extent_ level; if you have a 16GB USB stick, you could probably make up the extra space needed with that.
Джон Смит avatar
kw flag
@SimonRichter This is true. Data on sdс3 is not needed, they need to be replaced with data from sdb3. The required data takes up less than 70GB. I was hoping to transfer data using DD, but it copies the entire partition, which causes an error, since the partition is larger on the original drive.
br flag
Is this already a copy? If so, this is a dangerous situation, because both PVs now have the same UUID.
Джон Смит avatar
kw flag
@SimonRichter No, 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.
Nikita Kipriyanov avatar
za flag
Making a dump to the image on some spare device is very good idea. Use `ddrescue`; it will work around bad blocks (filling them with zeros in the image file) and also it will store a "log" file, which essentially contains an information on which blocks were copied, which weren't tried, and which were tried and found unreadable. You can safely restart a rescue command again and again (using the same log file). This is very useful, for example, when a device it is able to copy a chunk of data, then it overheats and shuts down and you need to wait for some time to cool it down before continuing.
Score:6
kz flag

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

https://clonezilla.org/

Джон Смит avatar
kw flag
Thanks, I'm already trying! I will post the result
Score:4
fr flag

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.
br flag
That works **only** if your disk contains no device files, no special files, nothing owned by a different user... there are a lot of things that won't work for, assuming it's not just a random bunch of data files. (Which I assume it's not, being an LVM volume. Most likely, it's the system disk for an OS install, extracted and plugged into an NVMe-to-USB bridge to attempt recovery.)
user1686 avatar
fr flag
@FeRD: `cp -a` preserves ownership, device nodes, and pretty much everything else I've tested it on. I've moved actual Linux systems this way several times.
Джон Смит avatar
kw flag
Initially, that's exactly what I planned to do. 1. Connect 2 USB drives to the test machine. 2. Booted from live linux 3. Created partitions on the second drive. But at the stage of mounting stuck. The mount command will not work, because it is an unknown file system for it, so you need it through lvm, but it constantly throws errors during activation and mounting.
Score:3
za flag

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.

Tom Yan avatar
in flag
It's worth mentioning that the new drive shouldn't be applied with (`pvcreate` and) `vgextend` if a pv clone is going to be made. If that has been applied, coresponding `vgreduce` should be run before cloning.
Nikita Kipriyanov avatar
za flag
That is what I meant by disusing and removal of labels from the target under the step 4.
Score:3
ro flag

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

Nikita Kipriyanov avatar
za flag
Keep in mind that this is the question about *how to do it in given particular situation*, you may suggest a software to do that, but your main goal is to present **exactly how** to use a chosen software. Don't make the answer into the list of the software, which, in this case, mostly unrelated to the question.
Z0OM avatar
ro flag
The question is that the OP has a problem, he ask for more solutions/other ways and wants to save his data. Since the disk is still in read mode, he has a problem. In my opinion i find the list of arch and wiki very good for the types of Block-level cloning, File system cloning and Versatile cloning solutions.So if for some reason your answer or another one doesn't work, the op has the list where other tools are presented and explained with examples and he can read further into the matter and think carefully about which way to go or what else to try.
Z0OM avatar
ro flag
If i had the problem and the data were important, i would buy a larger disk and make a backup with dd, ddrescue or clonzilla. I wouldn't try to shrink the disk or try to make other changes and then save and move anything afterwards.
Z0OM avatar
ro flag
There is also the possibility of cloning/backing up a disk using special hardware
Джон Смит avatar
kw flag
@BlockchainOffice The data on the source drive is less than 70GB. I already have a free new 100GB+ drive. The fact is that the size of the partition on the source disk is large, which is why DD cannot copy it.
Z0OM avatar
ro flag
@Джон Смит | I don't understand that now, if the target is larger than the source, there shouldn't really be a problem cloning with dd, regardless of whether it's 70 GB or more
Z0OM avatar
ro flag
@Джон Смит is sdc an empty drive with no other partitions ? try this than if "**sdb**" is the source and the target is "**sdc**" for the whole drive: **dd if=/dev/sdb of=/dev/sdc bs=1M status=progress** | or "**sdb3**" for the partition | dd if=/dev/sdb3 of=/dev/sdc bs=1M status=progress
Джон Смит avatar
kw flag
@BlockchainOffice I took a 500GB drive for testing. Caught the same error. It looks like the problem is elsewhere. This changes the essence of the issue. ___________________ 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
Z0OM avatar
ro flag
@Джон Смит what is your command?
Z0OM avatar
ro flag
What is the output with lsblk when both devices are plugged in?
Джон Смит avatar
kw flag
@BlockchainOffice -bash: /bin/lsblk: Input/output error
Джон Смит avatar
kw flag
Sounds like a disk problem. In the header, I updated the information, added a screen.
Z0OM avatar
ro flag
Let us [continue this discussion in chat](https://chat.stackexchange.com/rooms/145536/discussion-between-blockchain-office-and--).
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.