Cfrgtkky

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.

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

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.

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.