14

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

Can I do

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

?

4 Answers 4

11

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.

THEN LATER -- AND MORE TO THE POINT OF YOUR QUESTION:

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

6
  • 5
    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, 2017 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, 2017 at 8:02
  • 3
    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, 2017 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, 2017 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, 2017 at 17:47
5

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.

3
  • There shouldn’t be an issue with dd if the partition table is an msdos one and the size from the first byte to the end of the last partition does not exceed the size of the new drive. Otherwise, see my answer.
    – user149408
    Apr 30, 2020 at 15:05
  • I just started a copy of a 580GB lvm-partition into another smaller 200GB partition. since the large partition only has about 100GB on it. Assuming all the data were at the start of the 580GB partition, will the dd be able then to copy all data and I can use the new partition normally?
    – rubo77
    May 9, 2020 at 6:57
  • @rubo77 I can't think of any reason why not, but I'm not experienced with lvm, so I can't say for sure.
    – Owl
    May 9, 2020 at 13:44
4

It depends. (Assuming you want to copy the entire drive with any and all partitions, not just a single partition.)

Of course, the “surplus” space at the end of the bigger disk cannot be occupied by partitions, else the data will not fit. So, as you have already done, you will need to resize your partitions and move them to the start of the drive.

The second factor to consider is the partition table. An msdos partition table resides at the start of the drive. Hence, once you’ve taken care of partition sizes, dding the drive and cutting off the unused space is fine. I have successfully copied several drives that way.

It’s a little more complicated if a gpt partition table is involved. In this case, the partition table is stored in two places: at the beginning and at the end of the drive. The copy at the end will be lost if the new drive is too small—I have tried that and GParted did not recognize any partitions on the destination drive after that. What has worked for me is to first create a new partition table of type gpt on the destination drive (using GParted), and then copying the individual partitions over with GParted. That way, GParted will take care of updating the partition table entries.

1
  • Thanks for the hint. I was able to follow your advice and port my linux on new hdd of smaller size. after create GPT on newer drives and copying partitions one by one I then had to run boot-repair to just make everything work
    – Umair
    Apr 6, 2023 at 19:48
2

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.

3
  • I am not copying just one partition, I am trying to copy entire disk, is it ok to do it?
    – ChaoYang
    Mar 18, 2014 at 0:41
  • Yes. Copying single partitions is beyond the scope of this question.
    – SDsolar
    Aug 13, 2017 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, 2017 at 18:52

You must log in to answer this question.

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