Jtdcftul

I have Ubuntu 14.04 with a lot of packages and work related stuff that I am very happy with it. It is installed on my main SSD drive which is a 120GB one (I had choosen "/" when I installed ubuntu, so I beleive everything should be on this drive). It shows up as /dev/sda

Now I have added another SSD to my computer which is a 240Gb. I do not have any other storage media at hand at the moment (e.g. external hard drive).

Since the new 240GB drive has obviously more capacity and is faster (a newer generation than my 120GB one), I want to move my Linux to this new drive. This new drive shows up as /dev/sdb and at the moment it is not formatted or anything (I have literally unpackaged and inserted in my PC right now :P)

How can I safely move my linux installation to the new drive?

I can change the SATA cable so the new drive shows as /dev/sda if necessary.

This is the output of "fdisk -l" if that helps:

Disk /dev/sda: 120.0 GB, 120034123776 bytes

255 heads, 63 sectors/track, 14593 cylinders, total 234441648 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: 0x00076d7a



   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *        2048   226064383   113031168   83  Linux

/dev/sda2       226066430   234440703     4187137    5  Extended

Partition 2 does not start on physical sector boundary.

/dev/sda5       226066432   234440703     4187136   82  Linux swap / Solaris



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



Disk /dev/sdb doesn't contain a valid partition table

You can use CLONEZILLA for this purpose.

Clonezilla is a free partition and disk imaging/cloning tool which can be used to backup all your data (whole disks or partitions) in a highly compressed way and later clone it back to your hard disk to get it into exact same condition. This is faster than installing the OS most of the times.

• Download Clonezilla stable ISO or Direct Download clonezilla-live-2.4.6-25-amd64.iso




• Make a bootable (Live) USB using Tuxboot 7.0.




• Boot from the created Clonezilla media.



• 
  

  Now you have many options :

  
  
  
  
  
  1. Create an image of only '/' (saveparts) and clone it to any partition of your other SDD.
  
  
  2. Create an image of the full disk (savedisk) and clone it to your new SSD.
  
  
  
  

In your case you can use the "device-device" option too, but I am not familiar with it.

You can find a detailed guide about Clonezilla here : http://clonezilla.org

It can be done in a few ways. But the easiest one is to just copy all files from the old drive to the new one.

1. Create an ext4 partition and a swap partition on the new drive.




2. Boot from LiveUSB.




3. Mount the old Ubuntu partition to some directory, mount the new one to some other directory.




4. Copy all files from the old one to the new one using cp -a command.




5. Install grub to the new drive.




6. Update /etc/fstab with new UUIDs.

If something is not clear, I can add some explanations.

In case you have some time and want to go safe:

$ dd if=/dev/sda of=/dev/sdb bs=64K conv=noerror,sync

Explanation of the command:

• 
  if is the input, of the destination


• 
  bs sets the block size. It's the size of the chunks dd will read and write in. Higher Chunk sizes usually means higher performance but also more corruption of data if input disk has errors, see here: archwiki on dd
  


• 
  noerror continues in r/w-errors.


• 
  sync synchronizes the offsets if an error has occured.

This will basically create an image of you disk sda and write it onto sdb (same partition layout etc.) Ofcourse this'll write the whole 120GB as it's file-agnostic. Thus very safe, but not the fastest, if you only use small portions of the disk.
However if the input disk is rather full it might even be faster.

BUT:

• After that you probably want to resize the partitions as otherwise you cannot take advantage of the extra space.


• In any case it might be needed to edit the /etc/fstab file.
  
  This is the case if Hardware-IDs are used to recognize the disks.