Amazon EC2: How to move to a larger root volume

Note that this is only relevant for EBS backed AWS EC2 instances. If your instance has "instance storage"*, it is suggested that you instead consider moving files to your instance storage.

* - "Instance storage" is only available on older AWS instance sizes. I.e. older versions of TurnKey and/or older instances sizes launched from the AWS Marketplace.

The problem: the root filesystem is running out of space

Here's an example to illustrate the problem. Alon launches a Micro server via the TurnKey Hub. After a couple of months Alon notices that space on his 10GB root filesystem has almost run out.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2      9.8G  9.2G   14M 100% /
udev             10M     0   10M   0% /dev
tmpfs           402M  5.4M  397M   2% /run
tmpfs          1005M     0 1005M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs          1005M     0 1005M   0% /sys/fs/cgroup

The problem is that there is only 10GB in the server's root filesystem.

So how does Alon increase the storage size?

Option #1: Use TKLBAM to migrate your data to a new server

If your server has sufficient free space, the easiest way to migrate to a bigger root volume is to create a fresh backup and restore your backup to a new server with a bigger root volume.

This will also allow you to check your backup (which ideally you should be doing on a regular basis to ensure your backups will save in a worst case scenario).

Launch a new server (with a bigger volume than you had before). If you didn't launch from the Hub, you'll need to initialise the new server with your API key. Once you have created a current backup, plus your new server, then it should be a simple case of restoring the relevant backup record to the new server. Once you have confirmed that everything is working as it should, then you can destroy the old server.

Obviously if your root volume is too full to create a new backup, then ideally you should try to clean up a bit so you do have room. If not, you may need to go the longer more complex route below. Ideally it's always best to have a backup though!

Option #2: Creating a new instance from a snapshot via the Hub

These instructions assume that your are using the TurnKey Hub. If you are using TurnKey from the AWS Marketplace, please consult the AWS docs on how to do this using default AWS tools. Note, you may still need to resize the partition afterwards.

As mentioned above, ideally it's best practice to ensure that you have a (working) backup before you do anything possibly destructive. If your volume is just too full, then this is relatively safe as the only thing you need to do to your existing production server is take a snapshot of it. Everything else will occur on the new server you create.

Browse to the Hub's Servers page. Click on the relevant server to roll down the additional info. To ensure that this works reliably and avoid the risk of data corruption, you are strongly advised to stop the server first. Once the server has stopped, click the text link which says "x snapshots" (where x is a number).

On the new page, click the "Create snapshot" button. This process can take a little while and if progress appears to be stuck, please try refreshing the page.

Once the snapshot creation is complete, click the "Launch new server" text link. This will open a new page where you can set the details. Don't forget to set a larger volume size! :)

Resize the partition

Ideally, everything should now just work, however, I noticed that in my new instance, it is still reporting that the root volume is 10GB (mine still looks exactly the same as above). That is because although we're now using a larger volume, the partition where your data is is still only 10GB.

So for starters, log into your server via SSH.

To make sure that the volume is indeed bigger, let's just double check:

# fdisk -l
GPT PMBR size mismatch (20971519 != 62914559) will be corrected by w(rite).

Disk /dev/xvda: 30 GiB, 32212254720 bytes, 62914560 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
Disklabel type: gpt
Disk identifier: 5CB70E90-BE55-4EB0-8C61-F0612C6C9D0A

Device     Start      End  Sectors Size Type
/dev/xvda1  2048     6143     4096   2M BIOS boot
/dev/xvda2  6144 20969471 20963328  10G Linux filesystem

So that confirms that we do indeed have a bigger volume (Disk /dev/xvda: 30 GiB). It's also showing that there is a error in the "GPT PMBR" (the partition table) - we'll fix that along the way...

Next thing we'll need to do is install "parted". I have played with other tools and in my opinion, parted is the quickest and easiest way to get the desired result. I suggest that you run an apt-get clean to give us a little more space - just in case your drive is REALLY full!

apt-get clean
apt-get update
apt-get install parted

Then open the volume with parted. Note that the parted program is interactvie and provides a "(parted)" prompt. WHen you first start it, it should look like this:

# parted /dev/xvda
GNU Parted 3.2
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted)  
Initially we want to see the current state of the disk using the "print" command. It will initially complain about the error the fdisk noted. But we can fix that easy! :)
(parted) print                                                            
Warning: Not all of the space available to /dev/xvda appears to be used, you can fix the GPT 
to use all of the space (an extra 41943040 blocks) or continue
with the current setting? 
Fix/Ignore? fix                                                           
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 32.2GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name    Flags
 1      1049kB  3146kB  2097kB               grub    bios_grub
 2      3146kB  10.7GB  10.7GB  ext4         rootfs

(parted)
Now we need to resize the partition. We know it's partition 2 and that the total size is 32.2GB (from the partition table we just displayed).
(parted) resizepart 2                                                     
Warning: Partition /dev/xvda2 is being used. Are you sure you want to continue?
Yes/No? yes                                                               
End?  [10.7GB]? 32.2GB
(parted) 
That should have done the trick:
(parted) print                                                            
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 32.2GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name    Flags
 1      1049kB  3146kB  2097kB               grub    bios_grub
 2      3146kB  32.2GB  32.2GB  ext4         rootfs

(parted) 
Looks good! Now just quit out of parted:
(parted) quit                                                             
Information: You may need to update /etc/fstab.
Now all we have left to do is resize the filesystem:
resize2fs /dev/xvda2
We should now have a 30GB root volume, that looks a bit like this:
# df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/xvda2       30G  9.2G   19G  33% /
udev             10M     0   10M   0% /dev
tmpfs           402M  5.4M  397M   2% /run
tmpfs          1005M     0 1005M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs          1005M     0 1005M   0% /sys/fs/cgroup
To ensure that you don't get any nasty surprise next time you reboot, I suggest doing that right now:
reboot
It takes a few minutes to reboot, but once it's up and running again, just double check that everything is good. Assuming it is, you can destroy the old server.