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
user463133
  • 3
  • 1
  • 3
  • 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 '18 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 '18 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. – Michael Hampton Mar 29 '18 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 '18 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 '18 at 22:38
  • If I copy all of the partition's content to a partition of the exact same size, why shouldn't all the data be there? I am not trying to clone the entire disk at once anymore. Anyway, I will do a 'du -s' to check if it matches. – user463133 Mar 29 '18 at 22:50
  • I didn't see that you were copying specific partitions, just making an additional comment on the original question. However, be aware that copying the partition map using sfdisk doesn't copy the boot sectors. The destination device may not be bootable (unless you get lucky and successfully got those sectors from the initial dump). – Gene Mar 29 '18 at 22:59
  • Nice, it does boot and all the data is on the disk. It has a UEFI so no boot sectors needed:) Thanks again for your time and help, much appreciated. – user463133 Mar 30 '18 at 00:00
  • If you don't mind my asking, how did you know it was Windows? Would an outdated version of fdisk recognize e.g. EXT partitions on GPT? – user463133 Mar 30 '18 at 01:30
  • You said you "defragmented and did a chkdsk", which is a Windows (FAT, NTFS) thing. – Gene Mar 30 '18 at 05:17

1 Answers1

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.

Gene
  • 3,663
  • 20
  • 39