Converting Amazon EC2 ext4 EBS volume into XFS filesystem

Question

I need to convert my Amazon EC2 ext4 filesystem into a XFS one so I could take consistent snapshots and send them to S3. I'm using custom small image of ubuntu server 10.10 with i686 architecture in us-east. The problem is that I'm only using one EBS drive for all the files and now it is giving me headaches, because I cannot really unmount, format or really do anything to the drive when logged in to the instance from ssh. My guess is I need to somehow split up the EBS volume into 2 and move /var/www and /var/lib to second EBS volume and convert that to XFS instead. I'm using apache2, mysql, ispconfig, bind, postfix, courier, pureftp (http://www.howtoforge.com/perfect-server-ubuntu-10.10-maverick-meerkat-ispconfig-3)

Thank you.

Solution

You can either convert your root volume to XFS or create a second volume. Personally, I would favour the latter as it offers more flexibility.

Option 1: Convert Root Volume to XFS

1. Stop your instance (not terminate) (let's call it instance A)
2. Start a new instance (let's call it instance B)
3. Detach the root volume from instance A and attach it to instance B
4. Create a second EBS volume, attach it to instance B
5. Format the new EBS volume as XFS (install xfsprogs if not already done)
6. Copy all the data from the first volume to the new one (e.g. using rsync -aHAXxSP /source /target)
7. Detach the new volume from instance B and attach it as the root volume of instance A
8. Start instance A
9. Terminate instance B (the original root volume should persist, keep it around until things work to your liking).

The reason for attaching the root volume to another instance is to attain consistency, which would be difficult with the volume in use.

Option 2: Move data to a second EBS volume

1. Create a second EBS volume and attach it to your instance; format it as XFS and mount it
2. Identify which directories you wish to move to the new volume (some to consider include: /var/log, /var/lib/mysql, /var/www, /var/spool/mail, /var/vmail)
3. Stop as many services as possible to remove write locks
4. Use lsof | grep /path/to/dir to check for remaining write locks
5. Move the directory to the new EBS volume
6. Mount bind the new directory to its old location (i.e. mount -o bind /mnt/path/to/dir /orig/path/to/dir)
7. Repeat for each directory
8. Start your services to ensure all is working
9. Edit your /etc/fstab file to make the mount points permanent; e.g.: /mnt/path/to/dir /orig/path/to/dir bind defaults,noatime,bind 0 0

Restart to ensure everything persists and functions as it should. You may also want to consider shrinking your root volume down a bit since, hopefully, it shouldn't be growing (or changing) much with all the data removed from it.

(As a point of mention, it may be possible to freeze an ext4 file system using fsfreeze, which is included in util-linux-ng).

Comments

[jaz]

Thanks, I will go with the 1st option because I'm not sure I would be able to restore from the backup with the second method, should things go wrong.

[cyberx86]

You can restore each EBS volume independently - you could keep snapshots of both volumes separately, restoring which ever one you need. Amazon's EBS snapshots are differential and compressed, so the total space used shouldn't be much different with the data on two volumes as opposed to one.

[JaredBroad]

For Option 1: Recent ubuntu versions will fail to boot because the "cloudimg-rootfs" label is too long for XFS. You need to fix this by shortening the label it uses; these steps from the link below: Label /dev/xvdf device as '/'. Just run: xfs_admin -L \/ /dev/xvdf Mount /dev/xvdf in /xfs directory. Edit fstab file associated to the new XFS volume (/xfs/etc/fstab) and make sure / is associated to volume labeled / and xfs filesystem is configured for root mountpoint From here: jsianes.blogspot.com/2014/06/…