How to Grow a VPS Disk Partition and Filesystem After a Plan Upgrade

Resizing a VPS is sold as a two-click operation: pick the larger plan, reboot, and everything scales. The reboot is easy. What happens afterwards is where people get stuck, because the kernel keeps the old view of the block device, the partition table still ends where it did at provisioning time, and a filesystem that was formatted to 80 GB will happily ignore the extra 160 GB that just appeared underneath it. You end up paying for capacity the OS cannot see.

The procedure below is the one to follow on ext4 or XFS with a standard GPT layout, and it works the same on any KVM-based instance with root access. The goal is to get from “provider says 240 GB” to df -h reporting 240 GB, without a reinstall and without losing data.

Confirm the Kernel Sees the New Disk Size

Before touching a partition, verify the virtual block device actually grew. Compare three numbers: what the provider control panel claims, what the guest device reports, and what the filesystem reports.

lsblk -b            # SIZE column in bytes
blockdev --getsize64 /dev/vda
df -h /            # filesystem-level view

If lsblk still shows the old size, the guest has not re-read the device. Some hypervisors need an explicit rescan; a full power cycle (not a soft reboot) is the reliable fix. If lsblk shows the new size but df does not, you are in the normal case: the disk grew and the partition did not.

Map the Layout Before Editing Anything

Print the partition table and note the exact partition number and its current end sector. Most provider images use a single root partition (/dev/vda1) plus the BIOS boot or EFI partition.

sudo fdisk -l /dev/vda
sudo parted /dev/vda unit s print free

Write both numbers down. You want to see free space after the last partition. If there is none, the provider did not actually grow the disk and no amount of partition work will help. Also confirm the filesystem type with lsblk -f, because ext4 and XFS behave differently in the next step.

Take a Snapshot or Image First

Partition table edits are the one operation where a mistyped sector number destroys the whole system. Take a provider-side snapshot before you start, and if snapshots are not offered, at minimum export a copy of the partition table with sfdisk -d /dev/vda > /root/vda-table.bak.

The backup is cheap insurance, but it is not a substitute for care: restoring a snapshot costs a reboot and, on metered providers, bandwidth for the image download. Treat the snapshot as a rollback path you hope not to use. If you are still deciding whether an upgrade is the right move at all, weigh it against a fresh deployment on a larger plan — the trade-offs are covered in our guide to what cloud VPS benefits actually mean in practice.

Grow the Partition to Fill the Disk

With free space confirmed, extend the last partition. growpart from cloud-utils does the arithmetic for you and refuses to touch a mounted partition’s start sector, which is exactly the safety property you want.

sudo apt install -y cloud-guest-utils   # or dnf install cloud-utils-growpart
sudo growpart /dev/vda 1
sudo partprobe /dev/vda
lsblk /dev/vda

growpart works on a live root filesystem for both ext4 and XFS. If it reports NOCHANGE, the partition is already at the disk end and your problem is filesystem-level. Manual fdisk editing (delete, recreate at the same start sector, set the partition type) does the same thing but gives you many more ways to corrupt the table.

Extend the Filesystem Without Unmounting Root

The filesystem step is where ext4 and XFS diverge. ext4 can grow online in both directions of metadata; XFS can only grow, and only while mounted. Neither requires a rescue boot for a rooted filesystem.

# ext4
sudo resize2fs /dev/vda1

# XFS
sudo xfs_growfs /
# verify
df -h /

resize2fs picks up the new partition size automatically when given only the device. xfs_growfs takes the mount point, not the device. Both are fast on an empty tail and can take a while on a filesystem with a large allocation group count. If df now shows the target size, the job is done.

Check Swap and LVM If You Used Them

Blanket advice to “just grow the partition” fails on two layouts: an LVM volume group and a swap partition sitting at the disk end. If lsblk shows vda2 as an LVM physical volume, the free space goes into the volume group, not the filesystem, and you need a logical volume extension as well.

sudo pvresize /dev/vda2
sudo lvextend -r -l +100%FREE /dev/mapper/vg0-root
# -r calls the right grow tool automatically

If swap occupies the last partition, grow the root partition instead of swap — swap at the end only blocks you, and a swap file inside the grown filesystem is easier to size and resize later. That decision connects to how much swap a small instance should carry at all, which we break down in the VPS versus dedicated server comparison when sizing memory headroom for a workload that is about to get bigger.

Verify Capacity, Inodes and Mount Options

A successful df is necessary but not sufficient. Check inode count, free block percentage, and that the filesystem did not silently remount read-only during the resize. A read-only remount shows up as write failures minutes later, not at the moment it happens.

df -h; df -i
mount | grep ' / '
dmesg | tail -20
sudo touch /testfile && rm /testfile

For ext4, consider reserving less than the default 5% of blocks for root on a large volume with tune2fs -m 2 /dev/vda1, then re-check df. That recovers tens of gigabytes on big disks for non-root services such as databases or containers. Finally, add the resize step to your runbook so the next upgrade does not require rediscovering the commands.