How to extend a disk in Ubuntu/Debian after increasing it on a hosting provider or Proxmox (without downtime)

In production this is a routine situation: you increased the disk at the hypervisor level (VPS, cloud or Proxmox VE), but inside Ubuntu nothing changed — the / partition is still 100% full.

Let’s go through how to properly “propagate” the resize to the filesystem without stopping services or rebooting the server.

Why the disk didn’t grow automatically

When you increase the volume in the provider panel (Hetzner, Timeweb, Selectel) or in Proxmox (Hardware -> Disk -> Resize), you change only the size of the physical block device (for example, /dev/sda).

Inside Linux the old structure remains:
Disk (sda) -> Partition (sda3) -> LVM PV -> LVM VG -> LVM LV -> Filesystem

Until you go through the whole chain and update each level, the operating system won’t see the new space.

Step 0. Check current state

Record the initial data:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT
df -h

Typical example:

• /dev/sda shows as 50G.
• /dev/sda3 (partition for LVM) remains 18G.
• ubuntu--vg-root is mounted at / and is 10G.

Goal: expand sda3 to 50G and give all the space to the root filesystem.

Step 1. Resize the partition

Use the growpart utility. It can resize the partition table “on the fly”.

sudo growpart /dev/sda 3

Note: there is a space between the disk name and the partition number.

If the utility is not installed:

sudo apt update && sudo apt install -y cloud-guest-utils

Step 2. Resize the LVM Physical Volume

Now tell LVM that the physical volume (PV) got bigger:

sudo pvresize /dev/sda3

You can check the result with pvs or pvdisplay. The PFree column should show free space.

Step 3. Resize the Logical Volume and filesystem

The most convenient way is to extend the logical volume together with the filesystem in a single command:

sudo lvextend -r -l +100%FREE /dev/mapper/ubuntu--vg-ubuntu--lv

Explanation of flags:

• -l +100%FREE — use all available space in the volume group.
• -r (resizefs) — automatically run resize2fs (for ext4) or xfs_growfs (for XFS).

Fixing GPT errors (PMBR size mismatch)

When increasing a disk in Proxmox an error often appears: the GPT table expects the disk end at one place, but in fact it became larger.

Instead of interactive parted you can fix this with a single command:

sudo sgdisk -e /dev/sda

It will move the backup GPT structures to the end of the disk.

If LVM is not used

If your system is installed on a plain partition (for example, cloud images without LVM), the process is shorter:

1. sudo growpart /dev/sda 1
2. For ext4: sudo resize2fs /dev/sda1
3. For XFS: sudo xfs_growfs /

Common errors in Production

1. Wrong disk name: On different hosts this may be /dev/sda, /dev/vda or even /dev/nvme0n1. Always check with lsblk.
2. No free space for growpart to work: If the disk is filled 100% to the last byte, growpart may fail. In this case remove logs or clear the APT cache (apt clean) to free a few megabytes.
3. Docker and disk usage: Often space runs out not because of data but due to container logs and unused images. After expansion it’s useful to run:

docker system prune -a

Automation (Ansible)

If you have many servers, it’s better to automate these actions. In Ansible the community.general.parted and community.general.lvol modules are used for this. This reduces the risk of typos in the device path.

Monitoring

To avoid reaching a critical situation, set up alerts in Zabbix or Prometheus at the 80–90% disk usage threshold. Resizing without downtime is a routine process, but it requires caution.

Summary

Command chain for quick expansion: growpart -> pvresize -> lvextend -r.

This is the standard pipeline for maintaining modern infrastructure.