I have resized the partition of the larger drive with GParted.

Can I do

sudo dd if=/dev/LargerDrive of=/dev/SmallDrive



Yes, as long as the partitions will fit so do not need to be resized by dd.
i.e. the size of the drive isn't the issue.

(Note that all the below should be done by booting your original installation DVD and using the LiveCD option so the drives in question are not mounted.)

Here is an over-simplified answer, where I either never used gparted to resize the partition, or I did but now have done it again to bring it back down to size.

For instance, if you take a 160 GB drive (/dev/sda) and copy it to a 750 GB drive (/dev/sdb) - which I did to get faster booting on a 7200 rpm drive. You might be doing this simply for backup.

/dev/sda (160GB boot drive) is plugged into SATA port 0

/dev/sdc DVD drive is in SATA port 1

/dev/sdb (750 GB drive) is plugged into SATA port 2

Start by collecting info

sudo fdisk -l

/dev/sda is your original 160 GB drive with partitions.

Then ideally, it will show that /dev/sdb has no partition table.

If /dev/sdb shows partitions but you want to use it anyway, you can wipe the MBR and partition table from it with the following command:

sudo dd if=/dev/urandom of=/dev/sdb bs=512 count=24

which will wipe the MBR and partition tables guaranteed.
It will appear as if it was a new, blank drive.

Proceed to back up your boot drive to the larger one:

sudo dd if=/dev/sda of=/dev/sdb

This will take some time. I am writing this 3 years after you posted the question and mine takes 8000 seconds (about 2.5 hours) to do the backup.

In my case, I then removed the original boot drive and set it aside as the backup. That causes my system to boot from the first hard drive it finds, which is the 750 on SATA port 2.

But in your case, you are removing the 750 and setting it aside as the backup, thus setting the stage to answer your question specifically.


Say your boot drive fails, or you decide to replace it with a 160 GB SSD drive like I just did. I have not used more of the 750 GB drive. It still contains just the original 160 GB partitions from before

The new SSD is also a 160 GB ($50 on eBay) so it is large enough to hold the partitions.

The original /dev/sdb is still plugged into the same motherboard SATA socket as before, so now I plug the SSD into SATA port 0, and the SSD is now /dev/sda

(/dev/sdc is the LiveCD I am booting from)

Open a terminal window and check things out:

sudo fdisk -l

to verify that the 160 GB (/dev/sda) has no partition table. If it does, you can wipe the MBR and partition table from it with the following command:

sudo dd if=/dev/urandom of=/dev/sdb bs=512 count=24

Then proceed with the dd:

dd if=/dev/sdb of=/dev/sda

(It will take the same length of time as before - a couple of hours)

Make sure to do a clean shutdown of the liveCD.

sudo init 0

It will eject the CD then prompt you to press enter so it can flush the remaining buffers.

Remove the 750 which was /dev/sdb.

And voila, it can now boot onto the smaller drive just fine, because the size of the partitions allowed it to fit.

If you do this with a SSD like I just did, put on your seatbelt before booting. It is so fast you won't even get a full draw from the coffee mug before it is asking for your password.

In my particular case, I opted to leave the 750 HDD in as a secondary drive that I mount by UUID in the fstab under /mnt for backups and data collection.

So there you have it. An answer from July 2017 using Ubuntu 14.04 Install/LiveCD

  • 1
    This will work if there is an MSDOS partition table. But there may be problems if there is a GUID partition table, GPT, because there is (should be) a backup of the partition table a the very end of the drive, and with a smaller target drive, this backup partition table will simply be lost. But do not despair, it can be repaired with gdisk :-) See this link, help.ubuntu.com/community/Installation/UEFI-and-BIOS/… – sudodus Jul 16 '17 at 4:45
  • I am confused by your comment. Everything I have done was using brand-new drives and Ubuntu 14 installation media to build the system and then to use the larger drive, to make a clone of the partitions, with which I then migrated to a fresh SSD. No MSDOS has been involved at any step of the way. btw, the boot speeds are dramatic. It is just seconds instead of a couple of minutes. This PC boots up faster than my smartphone. – SDsolar Jul 16 '17 at 8:02
  • Please run the following command line in order to find out which partition table there is in the SSD after cloning, sudo parted -ls "... space minus ell ess". I'm happy to read that your cloning was successful, and I guess that there is an MSDOS partition table. This does not mean that you are using the old MSDOS operating system, only an old style partition table, that was originally developed for MSDOS in order to create partitions on hard disk drives. – sudodus Jul 16 '17 at 8:17
  • @susosus - the SSD came to me completely wiped so there were no partition tables. However, you are absolutely correct about the MSDOS partition tables. I havehad a lot ore experience since posting this answer, so I just updated it to the guaranteed command that will work better: dd if=/dev/urandom of=/dev/sdx bs=512 count=24 which wipes the MBR and any partition tables, no matter the type. – SDsolar Aug 13 '17 at 15:39
  • 1
    to wipe the head end I would still prefer to write only zeros, dd if=/dev/zero of=/dev/sdx bs=512 count=24 (and I usually overwrite the first mibibyte, but I understand that your experience is that overwriting the first 12 kibibytes is enough). I would also add, that the cloning process will overwrite that part of the drive anyway, so it is not really necessary when you are cloning. But as I wrote in my first comment, there might be problems if there is a GUID partition table because of the backup partition table at the tail end of the drive. – sudodus Aug 13 '17 at 17:47

Yes, but you need to specify the partition if you're just copying the partition.

So if the partition number on the larger drive is 1, then

sudo dd if=/dev/LargerDrive1 of=/dev/SmallDrive bs=4M

You can give a number for the small drive if you want it to write over an existing partition or not.

Also, consider adding a block size to the command, it speeds things up.

  • I am not copying just one partition, I am trying to copy entire disk, is it ok to do it? – ChaoYang Mar 18 '14 at 0:41
  • Yes. Copying single partitions is beyond the scope of this question. – SDsolar Aug 13 '17 at 18:47
  • Here is a Q&A about specifying block sizes. Basically, specifying small block sizes simply adds time as it has to start and stop between blocks. askubuntu.com/questions/523037/… – SDsolar Aug 13 '17 at 18:52

No this isn't okay to do, you will lose data if you do it. The problem basically is that the data isn't stored in the first part of the disk necessarily. dd / cat copies from the start to the end. Including the blank regions of the filesystem.

If you did this the dd / cat will only copy the size of the target filesystem from the source. This may be a problem if there is any data on the last areas of the disk, additionally the filesystem data will be incorrect on the copy of the disk.

If however you are only interested in data stored in the first part of the disk - for example the boot / root partition, this may well be okay to do. (I have done this before for example with boot partitions from iso images).

If your data fits inside the smaller disk, then one option is to resize the filesystem on the larger disk. The procedure would be something like this:

0) Make a backup of the partition table (print out fdisk data using p and save it to a file). If you've deleted a disk partition, provided you do not format the disk, you can repartition the disk in exactly the same way as before and recover most, if not all of the data. If you want to backup the larger disk onto smaller disks, one option may be to dd / cat the source partition into an iso file onto the smaller drive - if it fits. If all your source partitions are smaller than your target drives, such a backup is possible.

1) Unmount the drive totally including all partitions.

2) e2fsck the partitions to make sure there are no errors.

3) resize2fs the partitions on the source disk.

4) shrink the partitions to an appropriate size that contains your data (delete and recreate original partitions). Do not change the starting positions of any of the source partitions. Changing the starting point of the partition would be dangerous because the data would stay in the same place, but the relative offsets against the starting position of the partition would not stay the same, the consequences of this would be that your entire partition could become unreadable. It is fine to have gaps between your partitions, the operating system doesn't mind.

5) partition your target disk so that the partitions are the same size as the source partitions.

6) dd or cat the source partitions onto the target partitions.

7) e2fsck the target partitions.

8) Pray.

This is a very risky procedure, and i don't recommend it. Particularly if there is no backup of the source disk. Having said that, i've done worse things when drunk and i'm still here, with most of my data.

Before doing this, practice with some expendable data.

Summary: by resizing the filesystems you can force the data together and squeeze out the empty space on each partition, then you can copy the data between drives, copying the partitions one at a time using dd or cat, then using filesystem checking on the target system you should be able to resolve any irregularities on the partitions. In practice, you'd have to have balls bigger than Chuck Norris to attempt such a thing.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.