VPS Resize Won't Show New Disk Space? How to Fix It

You upgraded your VPS plan for more disk space, RAM, or CPU cores — the invoice went through, the panel shows the new specs — but df -h still reports the old, smaller size. Nothing crashed, nothing broke, but the extra space you paid for just isn't there yet. Here's what's actually going on and how to finish the job safely.

Symptom: The Upgrade "Worked" But Nothing Changed

A few variations of the same problem, all from a resize that didn't fully land:

• You bumped disk from 50GB to 100GB, but df -h / still shows ~50GB total.
• RAM was doubled in the billing panel, but free -h shows the old number, or the server needs a reboot before it'll even boot with the new allocation.
• CPU cores increased, but nproc or lscpu still reports the old count.
• After a reboot, the disk size is still wrong — or worse, the server doesn't come back up at all.

None of this means the upgrade failed. It almost always means the hypervisor did its half of the job (allocating the resource to your VM) and is now waiting on you to do the other half (telling the guest OS to actually use it).

Cause: A VPS Resize Has Two Separate Steps

It helps to think of a VPS resize as two independent operations that most providers don't fully automate:

1. Hypervisor-side allocation. The host reserves more vCPU, RAM, or virtual disk for your VM. This part is instant and needs nothing from you — it's what you're paying for.
2. Guest-side recognition. Your operating system has to notice the new resource exists and actually use it. CPU and RAM usually just need a reboot. Disk is the one that trips people up, because the underlying virtual disk got bigger, but the partition and filesystem sitting on top of it are still the old size — Linux doesn't auto-grow a partition just because the disk under it changed shape.

That's why disk resizes are the ones that generate support tickets: RAM and CPU "just work" after a reboot, but disk needs two more commands (grow the partition, then grow the filesystem) or the extra space sits there unused and invisible to df.

Fix: RAM and CPU (the easy part)

If only RAM or vCPU changed, a clean reboot from your provider's panel — not a soft reboot from inside the OS — is usually enough:

# confirm current allocation before reboot
free -h
nproc

# reboot from the VPS control panel, not `reboot` inside SSH,
# if the hypervisor needs to reattach the VM with new specs

After it comes back up, re-run free -h and nproc. If the numbers still don't match what you're paying for, that's a provider-side issue — open a ticket with your host rather than digging further on the guest OS, since there's nothing left for you to configure.

Fix: Disk (the part everyone gets stuck on)

First, confirm the disk itself actually grew at the block-device level, before touching partitions:

lsblk

If lsblk shows the full new size on the disk (e.g. /dev/vda) but your partition (e.g. /dev/vda1) is still the old size, you're in the normal case — the disk grew, the partition didn't. Here's the sequence, in order. Skipping the reboot or doing these out of order is the most common way people get stuck.

Step 1: Reboot first if you haven't already

Some hypervisors only present the new disk size to the guest kernel after a reboot. Do this before touching partitions — resizing against a kernel that hasn't seen the new disk size yet can leave things in a confusing state.

Step 2: Grow the partition with growpart

Most modern distros ship cloud-guest-utils, which includes growpart. If it's missing:

# Ubuntu/Debian
sudo apt update && sudo apt install cloud-guest-utils

# CentOS/AlmaLinux/Rocky
sudo yum install cloud-utils-growpart

Then grow the partition — this example grows partition 1 on /dev/vda:

sudo growpart /dev/vda 1

Run lsblk again. The partition should now show the full disk size, but df -h still won't — that's the next step.

Step 3: Grow the filesystem

The command depends on what filesystem you're running. Check first:

df -T / | awk 'NR==2{print $2}'

XFS's xfs_growfs takes a mount point, not a device — that trips people up if they're used to resize2fs syntax. Run df -h once more and the new space should finally show up.

If you're on LVM

LVM adds a layer in between the partition and the filesystem, so there's one extra step: grow the physical volume, then the logical volume, then the filesystem.

sudo pvresize /dev/vda1
sudo lvextend -l +100%FREE /dev/mapper/your-vg-root
# then resize2fs or xfs_growfs as above, targeting the LV path

Run pvs and lvs before and after each step if you're not sure of your volume group and logical volume names — guessing wrong here on a production disk isn't worth the risk.

If the Server Won't Boot After a Resize

This is rare, but it happens most often after a disk resize on a VM that was cloned or built from a custom image with a rigid partition table. If it doesn't come back up:

• Boot into rescue mode from your provider's panel — this gets you a live environment with your disk mounted, not booted.
• Check /etc/fstab for hardcoded UUIDs or device paths that may no longer match if a resize also changed device ordering.
• Don't run growpart or resize2fs from inside rescue mode against a disk that isn't cleanly unmounted — mount it read-only first and inspect before writing.

If you're on Getwebup VPS hosting and a resize leaves the server unreachable, open a support ticket rather than experimenting further — we can attach the disk to a rescue instance and fix the partition table without risking the data on it.

Prevention

• Take a snapshot immediately before any resize, disk especially — growpart and resize2fs are safe operations by design, but a snapshot turns "should be fine" into "definitely reversible."
• Schedule disk resizes for a maintenance window even though downtime is usually seconds — the "usually" is exactly the case a maintenance window protects you from.
• Avoid resizing disk and RAM/CPU in the same maintenance window if you can help it. If something looks wrong afterward, you want to know which change caused it.
• After any resize, verify with df -h, free -h, and nproc before you close the ticket in your head — don't assume the panel showing new specs means the guest OS picked them up.

A VPS resize is almost never actually broken — it's just half-finished. The hypervisor did its part the second you clicked upgrade; growing the partition and filesystem is the part that's on you, and it's three commands once you know which ones to run.