Use the extra disk space after an add-on

After you add disk, the quickest way to use it is to restart the server from the panel: the partition and filesystem grow by themselves as it boots. If you can't restart right now, you can grow them yourself while the server keeps running, in two commands.

Why the space doesn't show up at once#

Three layers sit on top of each other, and an add-on only grows the first one straight away:

1. The virtual disk (/dev/vda): grows shortly after the add-on is paid, while the server runs. lsblk shows the new size.
2. The partition on it (for example /dev/vda1): still the old size, so the new space sits unused after it.
3. The filesystem in that partition: also the old size. This is what df -h reports.

So straight after an add-on, lsblk shows a bigger disk while df -h / doesn't. That's expected; nothing is broken.

The simple way: restart from the panel#

Restart the server from its page in the panel. Our images run cloud-init at every boot, and its standard settings grow the root partition and filesystem to fill the disk. When the server is back, check:

df -h /

On our Debian 13 test server, which had gone from 40 to 50 GB, df -h / showed 50G after one restart, with nothing done by hand. If yours still shows the old size after a restart (for example because you changed cloud-init's settings, or the root filesystem is on LVM), use the steps below.

Without a reboot#

Run these on the server. First see where the root filesystem lives and what kind it is:

lsblk
findmnt -no SOURCE,FSTYPE /

The partition number isn't the same on every image, so read it from the output rather than copying someone else's. Our test servers showed:

Grow the partition, with your own disk and partition number (a space between them):

sudo growpart /dev/vda 1

It answers with a line that starts CHANGED: partition=1. If it says NOCHANGE, the partition already fills the disk: check lsblk again in a minute, because the disk itself may not have grown yet.

Then grow the filesystem. Run only the one that matches the second word findmnt printed:

• ext4:

  bash

  sudo resize2fs /dev/vda1

  Use your own partition. It prints The filesystem on /dev/vda1 is now … blocks long.

• xfs: XFS is grown by its mount point, not the device:

  bash

  sudo xfs_growfs /

• btrfs:

  bash

  sudo btrfs filesystem resize max /

Both steps are safe on a running, mounted filesystem, and neither touches your files. Check the result:

df -h /

On our Ubuntu 24.04 test server, / went from 38G to 48G; on AlmaLinux 10, from 39G to 49G.

When this doesn't apply#

• findmnt shows a /dev/mapper/… device: that's LVM, which these steps don't cover. Restart from the panel, or grow the physical volume, logical volume and filesystem with your own LVM tools.
• growpart: command not found: install it with apt install cloud-guest-utils (Ubuntu, Debian) or dnf install cloud-utils-growpart (AlmaLinux, Rocky Linux, Fedora), or restart from the panel instead.
• You added a second filesystem or a swap partition at the end of the disk yourself: the root partition can't grow past it. Restarting won't help either; that layout is yours to rearrange.

Snapshots and backups#

• Reverting to a snapshot taken before the disk grew keeps the bigger disk, but brings back the snapshot's smaller partition and filesystem. Restart from the panel, or repeat the steps above.
• The same goes for restoring an off-site backup made before the disk grew.
• A disk can't be made smaller again once it's grown, so add what you need rather than a lot more.

We tested this on 6 November 2026 on Rack4 servers built from our Ubuntu 24.04, Debian 13 and AlmaLinux 10 images, each grown from 40 to 50 GB with the disk add-on. The btrfs line comes from btrfs's own tools and wasn't part of that test.