Amazon EC2: How to expand the size of an existing root volume


  • As of 2019, this is the recommended path if you wish to increase the size of your root volume. Best practice is to stop your server for the initial snapshot, but strictly speaking it's not required.
  • Alternatively, please see the older documentation on migrating data to a new instance (with a larger volume). It should still be relevant.
  • This page 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 AWS instances sizes. If you have a v14.2+ TurnKey server it will almost certainly be EBS backed. Versions as far back as v13.0 will likely be EBS backed too, but double check within the AWS Console to be sure, or please post to the forums stating the TurnKey version and AWS Instance size/type.

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
udev            486M     0  486M   0% /dev
tmpfs           100M  4.1M   96M   5% /run
/dev/xvda2       9.8G  9.8G   19M   100% /
tmpfs           498M     0  498M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           498M     0  498M   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?

Increase the root volume size using AWS Console

Expected time to complete: 40 mins to an hour.

These instructions assume that your server is running from the TurnKey Hub, but they also require usage of the AWS Console. If you aren't using the Hub (or TurnKey for that matter) they should still be generally relevant, although you may wish to consult the AWS docs for more detail strictly related to the AWS Console.

So long as you can afford a small amount of server downtime, then arguably the best way to resolve this, is to enlarge the root volume via the AWS console. If you can't afford any downtime, then this can be done live, but I would argue that the few minutes of downtime is worth the piece of mind.

Getting ready

The first thing to do is to create a backup. You can use TKLBAM for that purpose, although in this case, I would recommend taking a "snapshot" (as well?). If you are extremely short on space, TKLBAM may not be an option. A snapshot will allow you to get back to exactly where you are right now quicker and with less hassle (no need to start a new server, etc).

Whilst you can take snapshots of running servers, for the purposes of backup, Amazon recommend that you take snapshots of stopped servers. This is because there is a (very slim) chance of data corruption when taking a snapshot of a running server. So unless a few minutes of downtime is going to be a problem (and even then), it seems like a no brainer to follow that advice.

If you're stopping the server, from the Hub's Servers page, select your server so that the full info rolls down and click Stop.

Once you're ready to take a snapshot, still on the Hub Server page, look for the text link which says "x snapshots" (where 'x' is the number of snapshots you have taken already - will be '0' if you haven't taken any before). Click that and on the page that opens, click the "Create snapshot" button. Initially it will display "0%" and will take a minute or 2. If you don't see any progress, try refreshing the page. Once it's complete, you should see a green circle.

Finding your TurnKey server in AWS Console

Back on the Hub's Servers page (roll down your server info again if need be), look for where it says Region and note that. Now, in a new browser tab/window open your Amazon Console to the EC2 - Instances page. In the AWS Console, on the top bar, towards the top right (between where it shows your username, and "Support") click the drop down and ensure that the region matches the one that your Hub server is in (if it does already, skip that step).

If you only have one stopped server/instance (or are otherwise sure of exactly which server you need to work with), then you can skip this next step. Although, if you have 2 or more instances, to be completely sure that you are working on the right one, I recommend doing a "search".

To do that, go back to the Hub's servers page and copy the EC2 instance ID (in my case it's "i-0c04e369a3d987199"). Paste that into the search bar towards the top of the AWS Console tab/page (by default the search bar will contain the text "Filter by tags and attributes or search by keyword"). Paste your server/instance ID in there and hit enter.

Increasing the volume size

Only one instance should now remain showing in your AWS Console. If you don't get any result, double check that you have selected the correct region and that you are signed into the correct AWS account (if you use multiple accounts). Further information about your server should now be viable in the lower pane. Scroll through this until you see "Root device", it will likely be "/dev/xvda".

Click the device (e.g. /dev/xvda in my case) and small black pop-over should appear with some info about the EBS volume. Click on the EBS ID (in my case "vol-02110c92a873ad915") and you should be redirected to the AWS Console - Volumes page, with only the desired volume showing.

Right click on your volume and select "Modify Volume". A pop over should open. Look for where is says "Size". Mine is Currently "10" (GB). Increase that number to the desired volume size (in GB). I'm going to make mine 20GB. Then click the "Modify" button. On the next screen click "Yes". You should be greeted with a green message: "Modify Volume Request Succeeded". That should happen almost instantly, but you may need to refresh the AWS console to see your volume display with the desired size (e.g. 20 GiB in my case). If it doesn't, try refreshing again.

Back to the Hub: restart your server (if stopped) and confirm the larger volume

That's all we need the AWS Console for, so you can now log out and shut that. If you stopped your server, return to the Hub's Servers page. On your server, click "Start" to bring it back to life. As per usual, it will take a little while to become available. For most servers, this should only take a couple of minutes (5 at the most).

Once your server is running (or straight away if it wasn't stopped), log in via SSH. If you were to run the df command again, you would notice that nothing has changed. That is because we've only increased the volume size. If you wish, you can check that the volume is indeed bigger, with gdisk:

# gdisk -l /dev/xvda
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/xvda: 41943040 sectors, 20.0 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): 8A333A04-DB02-4249-870C-EC5665D405BF
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 20971486
Partitions will be aligned on 2048-sector boundaries
Total free space is 4029 sectors (2.0 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1            2048            6143   2.0 MiB     EF02  grub
   2            6144        20969471   10.0 GiB    8300  rootfs

Note the "Disk /dev/xvda: 41943040 sectors, 20.0 GiB".

Fix the partition table and resize the partition

Next we need to fix the partition table (GPT), then we can extend the partition to use the new free space. To extend the filesystem (and fix the GPT), we'll use parted (should be installed by default on all v15.x servers). Start it with the 'parted" command.

# parted
GNU Parted 3.2
Using /dev/xvda
Welcome to GNU Parted! Type 'help' to view a list of commands.

First up, double check the existing info (again) using the 'print' command. It should bring up a warning that not all the space is being used, with an option to fix it..

(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 20971520 blocks) or continue with the current setting? 

Allow it to do the fix (by typing 'f' followed by enter). It should now display similar info to the df check we ran earlier. Although note that this displays GigaBytes (1Byte x 1000 x 1000) as opposed to GigiBytes (1Byte x 1024 x 1024) so don't be alarmed if the numbers don't quite match. In my case, it's displaying 21.5GB (which is 20GiB).

Fix/Ignore? f
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 21.5GB
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


To resize the partition, use the 'resizepart' command. On a default set up, you will want to resize partition 2, but double check your output (from 'print') to make sure yours matches. Note that I ignored the warning about modifying a partition in use. Also note that I used all the free space (i.e. went to the final size of the disk: 21.5GB)

(parted) resizepart                                              
Partition number? 2                                                       
Warning: Partition /dev/xvda2 is being used. Are you sure you want to continue?
Yes/No? y                                                                 
End?  [10.7GB]? 21.5GB                                                    

Double check that it all worked as expected with 'print'. If something doesn't look right, you can rerun the 'resizepart' command again. But mine looks fine.

(parted) print                                                            
Model: Xen Virtual Block Device (xvd)
Disk /dev/xvda: 21.5GB
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  21.5GB  21.5GB  ext4         rootfs


Nearly done; extend the filesystem and finish

Even now, if you were to exit parted and recheck the output of df, you could still not see the additional new space. That is because the final step is to extend the filesystem to fill the partition. Some versions of Parted can also do that (IIRC the command is 'resizefs'), but the one I haven't doesn't seem to have that ability, so exit out of Parted ('quit'). You can safely ignore the info about /etc/fstab

(parted) quit
Information: You may need to update /etc/fstab.

Then run 'resize2fs' on the partition:

# resize2fs  /dev/xvda2

If we check df now, we'll see that the free space is now available.

# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            486M     0  486M   0% /dev
tmpfs           100M  4.1M   96M   5% /run
/dev/xvda2       20G  9.8G   10.2G   48% /
tmpfs           498M     0  498M   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           498M     0  498M   0% /sys/fs/cgroup

YAY! All done! :)

Final cleanup

Personally, I like to give it a few days to settle in before I remove the snapshot. That's just in case something isn't quite right, but doesn't show immediately. Having said that, I've never needed it before. Still, I'd rather give AWS a few more cents for the piece of mind. Once you are feeling confident, you can delete the snapshot if you wish. Do that by finding the snapshots as per the first part and this time instead of creating, delete.