0

I'm cloning a larger HDD(750GB) to a smaller SSD(250GB). I shrunk the partitions and there is only 83gb of used space. (I defragmented and did a chkdsk). Also, sum of partition sizes is smaller than the SSD size.

I am now piping the dd process through pv to see the amount of data transfered. It's still going and it's already on 170gb+. Why is this? I used the "conv=sync, noerror" argument on dd. I thought it would finish at 83gb..

This is 'fdisk -l' output: (/dev/sda = 750gb HDD, /dev/sdb = 250gb SSD)

Disk /dev/sda: 750.2 GB, 750156374016 bytes
255 heads, 63 sectors/track, 91201 cylinders, total 1465149168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1               1  1465149167   732574583+  ee  GPT
Partition 1 does not start on physical sector boundary.

WARNING: GPT (GUID Partition Table) detected on '/dev/sdb'! The util fdisk doesn't support GPT. Use GNU Parted.


Disk /dev/sdb: 240.1 GB, 240057409536 bytes
255 heads, 63 sectors/track, 29185 cylinders, total 468862128 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x00000000

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  1465149167   732574583+  ee  GPT

And this is the command I'm using to clone:

sudo dd if=/dev/sda | pv | sudo dd of=/dev/sdb bs=64K conv=sync,noerror
10
  • Can't answer the question since it's on hold, but two things, first: /dev/sda is the entire disk, not just the partitions you created on it. So it will attempt to copy the entire 750GB until it runs out of space on the destination device. Secondly: Just because you resized the partitions to be less than 250GB it doesn't mean they will be confined to the beginning of the disk. It's very likely that you'll copy over the first 250GB of the HDD to the SSD and not get the entirety of the 83GB of data that is on there.
    – Gene
    Mar 29, 2018 at 21:10
  • It looks like you're copying a bootable windows system from HDD to SSD. Take a look at clonezilla. It can clone from a larger to smaller drive just so long as the space used on the source drive is less than the destination drive, it takes care of copying and setting up the destination partitions for you. You don't need to modify the source drive at all.
    – Gene
    Mar 29, 2018 at 21:21
  • Your ancient version of fdisk is too old to understand GPT partitioned disks. Use a newer version of fdisk, or use parted to list the partitions. Mar 29, 2018 at 21:49
  • I 'cloned' the partition table using sfdisk and now copying data of each partition. Will try clonezilla if it doesn't boot. Thanks a lot!
    – user463133
    Mar 29, 2018 at 22:32
  • Just be aware, if it does boot after the dd that doesn't necessarily mean all of the data is there.
    – Gene
    Mar 29, 2018 at 22:38

1 Answer 1

2

I'm cloning a larger HDD(750GB) to a smaller SSD(250GB). I shrunk the partitions and there is only 83gb of used space...
It's still going and it's already on 170gb+... I thought it would finish at 83gb.

That's because you aren't just copying 83GB of data. Let's take a look at how you're copying the data:

 sudo dd if=/dev/sda | pv | sudo dd of=/dev/sdb bs=64K conv=sync,noerror

The first part is reading the entirety of /dev/sda and dumping it to STDOUT.

pv is measuring the throughput and status of the dump from the first dd and redirecting it to the next command while providing a human readable output to your terminal. It doesn't massage the data in anyway, it's merely measuring things for informational purposes.

The third part is taking all input from STDIN and dumping it onto /dev/sdb.

So what will happen is it will copy data from the source device (/dev/sda) to the destination device (/dev/sdb) until the destination runs out of space.

I shrunk the partitions and there is only 83gb of used space. (I defragmented and did a chkdsk). Also, sum of partition sizes is smaller than the SSD size.

Because you resized the partitions the partition map may fit on the destination device, however that doesn't necessarily guarantee that all of the data is going to be at the beginning of the disk. You will need to look at the GPT layout to confirm that the partitions were moved to the beginning of the drive. If not it's possible that the copy won't have all of your data.

It looks like you're trying to copy the boot disk of a Windows system. Rather than trying to do this manually you'd be better off using a utility like Clonezilla to do this for you. You will still need to shrink the file system on the source disk, but it will handle creating the partitions on the destination disk for you and copy the data.

1
  • 1
    Upvote and a double plus one for clonezilla
    – ivanivan
    Mar 30, 2018 at 5:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .