You increase the disk size in the provider's panel, reboot, and the server reports exactly the same free space as before. Nothing is broken. Two of the three layers have not been told.
The three layers
The disk is what the provider enlarged. That part is done.
The partition still describes the old, smaller area. It has to be grown to fill the new space.
The filesystem inside the partition still describes the old size. It has to be grown too.
Each is a separate step, and skipping either of the last two produces exactly the symptom above.
Look before doing anything
lsblk df -h
lsblk shows the disk's real size and the partition's. df shows the filesystem's. When the first is larger than the others, you have the situation this page describes.
Grow the partition
growpart /dev/vda 1
Note the space: the device and the partition number are separate arguments. This is the tool designed for the job and it handles the alignment correctly.
If it is not installed, it comes from the cloud utilities package on most distributions. Doing this with a general partitioning tool is possible and considerably easier to get wrong.
Grow the filesystem
resize2fs /dev/vda1 # ext4 xfs_growfs / # XFS, by mount point
Check which you have first:
df -T
Both can be done while the filesystem is mounted and in use, which means no downtime for this step.
With a volume manager
If the system uses logical volumes, there is one more layer:
growpart /dev/vda 2 pvresize /dev/vda2 lvextend -l +100%FREE /dev/mapper/vg-root resize2fs /dev/mapper/vg-root
More steps and considerably more flexibility afterwards, which is the argument for choosing a volume manager at installation. Installing an operating system deals with that decision, and it is the one that cannot be changed later without reinstalling.
Back up first
Growing a filesystem is routine. Editing a partition table is the step where a mistake costs the whole filesystem instead of the free space.
Take a snapshot or a backup before starting. It takes minutes and it is the difference between an error and a rebuild. Backing up and restoring your VPS goes into the distinction between a snapshot and a backup, which matters here.
Adding a second disk instead
Often simpler than growing the first, and it isolates the growth:
lsblk # find the new device mkfs.ext4 /dev/vdb mkdir /mnt/data mount /dev/vdb /mnt/data
Then make it permanent in /etc/fstab, and use the UUID instead of the device name:
blkid /dev/vdb
Device names can change between boots. An fstab entry naming a device that has moved will hang the boot, which is one of the more common reasons a server does not come back. Diagnosing a server that will not boot sets out recovering from it.
Test it before trusting it:
umount /mnt/data && mount -a && df -h
Shrinking
Considerably riskier than growing, and not supported at all on some filesystems.
Where a smaller disk is genuinely needed, the safe route is a new smaller volume, copy the data across, and switch, not shrinking in place.
The question worth asking first
Is more disk actually the answer? An account filling up is frequently logs that never rotate, old backups, or a very large number of small files exhausting the inode count in place of the space.
du -sh /* 2>/dev/null | sort -h | tail -10 df -i
Buying disk for a directory full of orphaned archives just schedules the same conversation. Understanding inodes explains the case where space is not the problem at all.
When the disk is already full
A completely full disk stops you doing the very things needed to fix it, so the first job is to free enough room to work.
journalctl --disk-usage; journalctl --vacuum-size=100M du -sh /var/cache/* 2>/dev/null | sort -h | tail -5 lsof +L1 2>/dev/null | awk '$5=="REG"' | head
System logs and package caches are the usual quick wins and are safe to clear. The third command is the one people miss: files that have been deleted while a process still holds them open occupy space that no listing shows, and restarting that process releases it immediately.
A disk that reads as full while du accounts for far less is almost always this. Look there before resizing anything. Managing logs and log rotation deals with stopping it happening again.
Running out of files rather than space
A filesystem can refuse to write with plenty of room left, because the other limit was reached.
df -h / df -i / find /home -xdev -type d -printf '%h\n' 2>/dev/null | sort | uniq -c | sort -rn | head
If the second command shows the used percentage near a hundred while the first does not, the problem is the number of files, not their size. Growing the disk does not raise that count on most filesystems, so the resize you were about to perform would have changed nothing.
The cause is usually one directory holding an enormous number of small files: a session store, a cache, a mail directory, or a queue that stopped being consumed. Understanding inodes goes into finding it.
Confirm it survives a reboot
A resize that works now and disappears at the next restart is a worse outcome than one that fails immediately, because the failure arrives without a change to blame.
lsblk -f blkid grep -v '^#' /etc/fstab findmnt --verify
The mount entry should reference a stable identifier rather than a device name, since device names can change order between boots. The verification command reports entries that would fail.
Then reboot deliberately, at a time you choose, and confirm the mount returns with the new size. Discovering this months later during an unplanned restart is how a routine reboot becomes an outage.
Snapshots are not a backup of the disk
Taking a snapshot before a resize is right, and it is worth knowing exactly what it protects against.
A snapshot stored on the same storage as the volume protects against your mistake and not against the storage failing. It is also frequently kept as a difference from the original, so it grows as the machine writes, and a forgotten one can consume the space you just added.
lvs -o lv_name,lv_size,data_percent,origin 2>/dev/null df -h
Delete the snapshot once the change is confirmed good, and keep a real backup somewhere else for the case the snapshot cannot help with. Using rsync for transfers and backups goes into the copy that lives elsewhere.