You are not logged in.

#1 2024-04-15 23:20:04

archfluke
Member
Registered: 2016-06-08
Posts: 39

after running dd to clone entire disk in vmware

hello. While booted into the installation media on vmware, I ran dd and cloned the entire disk which consists of the following table.
```
Device      Start       End   Sectors   Size Type
/dev/sdb1    2048    821247    819200   400M EFI System
/dev/sdb2  821248 820021247 819200000 390.6G Linux filesystem
```
I cloned using the guidance on https://wiki.archlinux.org/title/Dd#Dis … nd_restore with `dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync status=progress` and was seeing a single entry for a dos thing. I tried to mess with fdisk and create two new partitions of EFI system and LInux filesystem, but doing that didn't allow me to mount either partition, which is how I've been testing success. It looks like I can still salvage the data from this clone, since maybe making a new gpt partition table didn't wipe anything? I did wipe the boot efi partition, but have yet to run mkfs.ext4 on the 2nd root partition. It look about 5 hours cloning so I'd rather work with getting this data working. If it's beyond hope, I imagine I'd have to retry using https://www.reddit.com/r/archlinux/comm … tices_and/ ? I find dd scary and would like to minimize risking loss of data as much as possible. Thanks!

Offline

#2 2024-04-16 04:17:13

mpan
Member
Registered: 2012-08-01
Posts: 1,215
Website

Re: after running dd to clone entire disk in vmware

Hello. If “/dev/sdb” was meant to be the source disk and “/dev/sda” to be the destination, your “disk destroyer” invocation have them swapped. You moved data from “/dev/sda” to “/dev/sdb”, overwriting contents of the latter.

If `dd` completed, all data on “/dev/sdb” has been removed. If you have cancelled the operation earlier, it’s possible some was spared. But with 5 hours runtime certainly all basic filesystem structures are erased, so at best only some files may be recovered using PhotoRec from testdisk (PhotoRec FAQ).

Your issue seems unrelated to the use of `dd` or attempts to clone an entire disk. However, in general both are bad ideas. Coincidently today you’re a second person I see which suffered trouble because of that.

  • Avoid cloning entire disks. Exceptions include cloning for data recovery, or backing up with the intention to put data back on the same device. A blind clone will cause multiple partitions and filesystems share the same PARTUUID/UUIDs. Copying to another device may render data in the partition table invalid, if sector size differs. Instead rather create a new partition table, new file systems, and copy files there using rsync. The advantage is you get defragmentation for free.

  • Don’t use `dd`. For reasons, explaining of which is beyond the scope of this post, `dd` gained association with disks. But the only association is the whimsical explanation of the name: disk destroyer. The “disk magic” actually happens in the kernel and it happens for any file utility. Article on writing Arch ISO to USB flash drive contains better examples. There are rare exceptions, where `dd` (in particular GNU dd) may have some useful options. But in general it’s a tool painfully trivial to use wrong, with very non-obvious behavior. All this amplified by hordes of people, who fail to read documentation deep enough and suggest things they learned from the lore.


Sometimes I seem a bit harsh — don’t get offended too easily!

Offline

Board footer

Powered by FluxBB