You are here
Amazon EC2: How to move your instance to a larger root volume (legacy)
Notes:
- This is older documentation and now that AWS supports resizing volumes, generally you will be better served by extending an existing root volume. However, this doc should still be relevant if you can not afford downtime.
- 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 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.