How can I clone an entire drive (or partition) to a smaller drive (or partition)?

2

1

I have a 1TB hard disk which is set up as MBR with 3 primary partitions. The sizes of the partitions are exactly 250GiB, 250Gib, and 192GiB, respectively. The remainder of the drive is unallocated space.

This drive boots to the first partition by default (Windows) on its own, but can also boot into the second partition (another Windows) using GRUB (which is installed on another hard drive).

Ignoring the unallocated space, I want to clone the entire drive to a 750GB drive, because the allocated space will fit. I want to preserve UUIDs and the MBR. How can this be done?

ayane

Posted 2015-02-25T03:27:15.003

Reputation: 249

1Doing this is non-trivial, although something like Partion Magic may allow you to do it. As its the middle partition you are trying to resize quite a lot of manipulating is required to make this happen. I don't think you can just shrink the middle partition - I suspect you will need to move the third partition to just after the endpoint of the second one. – davidgo – 2015-02-25T05:21:02.927

Most if not all disk cloning software will allow you to resize the partions while cloning (by cloning I mean filesystem-aware cloning, not dumb sector copy) – Dan – 2015-02-25T08:16:33.423

Answers

1

Have you used gparted before (http://gparted.org)? I highly recommend it and it's free. I would boot into a gparted live CD and resize the partitions from there with a nice, friendly GUI (make sure Windows has shut down cleanly beforehand and isn't in hibernate etc).

Your UUID shouldn't change, but after resizing the partitions, you should run

sudo blkid

to double check on a terminal within the gparted live environment to double check the UUIDs and update the grub configs if necessary before rebooting.

fquinner

Posted 2015-02-25T03:27:15.003

Reputation: 161

3

I know this will work, because I've done it several times - read the whole thing first before starting!:

  1. Boot from a Knopix CD/DVD (suggest release 7.0). This will give you a nice stable work environment.

  2. Use gparted or another disk utility to determine the special device files associated with the source disk and target disk. Note that you are NOT interested in the device files associated with the partitions. For example, you want something like /dev/sda and /dev/sdb, not /dev/sda1 and /dev/sdb2

  3. MAKING SURE THAT YOU HAVE CORRECTLY IDENTIFIED WHICH IS THE SOURCE DISK AND TARGET DISK, use dd to copy the source disk onto the target disk as follows.

  4. ASSUMING THAT /dev/sda is the source disk, /dev/sdb is the target, the command will look like dd if=/dev/sda of=/dev/sdb bs=10M. This will copy 10 megabytes at time, which should be fairly efficient. DON'T GET THE SOURCE AND TARGET DISK wrong in the command, because once you start, there's no going back. Get them wrong, and you've effectively erased your source disk!

  5. dd will continue to run until it whines about running out of space on the target disk (because you are trying to copy 1TB onto 750GB, but that's ok). You could try to figure out how much to copy, because dd has a 'count' parameter, but because of the confusion over how 'mega' is defined, I'd just let it rip.

  6. The end result should be a clone, including master boot record, partition table, UUIDs and labels of the 1TB drive on the 750GB drive. You can use gparted to make sure after dd finishes.

  7. If you want to mount the file systems on the target drive while running Knopix, first run the command partprobe so that the kernel will recognize the partition table on the target drive. Then you can mount the the filesystems if you want by first creating mount points (for example, mkdir /sda), and then mount /dev/sda there. Don't try to mount the source and target partitions at the same time, because the UUIDs are the same, and I've a feeling that the system won't allow it.

EDIT: There are a few things that should be mentioned about the above 1) I'm assuming that there is no space between the 3 primary partitions i.e. they are contiguous on the source disk, and that the first partition has no unallocated space preceding it. 2) And, the sum of the sizes of the partitions on the source disk must be less than or equal to the available space on the target disk. Another way to look at is that the byte count to the end of the last partition must be less than or equal to the available space on the source disk. This to me is a fairly rare set of circumstances, but that was the question that was asked. 3) In the more generic case, where you want to clone a drive onto a smaller drive where the amount of data on the source drive can fit on the smaller drive, then you need to use a utility like gparted to first shrink the partitions on the source drive and then move them so that they are contiguous. Then you can use the method above.
4) Would I do this on the original source drive? Only if you like to live dangerously. I'd first clone the source drive onto another equal or larger drive using 'dd', and then reconfigure the clone first before cloning the clone onto the smaller drive. If anything can go wrong, it will, including a power failure in the middle of the operation.

fatswaller

Posted 2015-02-25T03:27:15.003

Reputation: 31

Excellent answer to an old question, haha! – ayane – 2017-04-11T02:14:27.110