DEV Community

Big Mazzy
Big Mazzy

Posted on Originally published at serverrental.store

How to Resize a VPS Without Losing Data

#webdev #cloud #linux #devops

A “resize” button looks harmless until the VPS comes back online with the same disk size—or, worse, a filesystem that won’t mount. The risky part usually isn’t adding CPU or RAM; it’s making sure the operating system can see and use a larger disk without disturbing the data already on it.

This guide walks through a careful resize: check what you have, make a recoverable backup, change the VPS size, grow the partition and filesystem, and verify the result. The commands below are for common Linux setups; the exact steps depend on your provider, partition layout, and filesystem.

What a VPS resize changes

A provider may let you change CPU, RAM, and disk size together, or treat disk changes as a separate operation. Some providers require a shutdown; others can change CPU and RAM while the VPS is running. Disk expansion is commonly supported, but shrinking a disk is a different and riskier operation. Don’t assume a smaller plan will safely shrink your existing disk.

For a typical Linux VPS, the storage layers look like this:

Virtual disk → partition → filesystem
Enter fullscreen mode Exit fullscreen mode

If the provider makes the virtual disk larger, the partition and filesystem might not grow automatically. That’s why adding disk capacity in a control panel can leave df -h showing the old size.

1. Inspect the current layout

Before changing anything, record the current disk, partition, filesystem, and mount details:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
df -hT
findmnt /
Enter fullscreen mode Exit fullscreen mode

Look for the device mounted at /. A common layout might show a disk such as /dev/sda, a root partition /dev/sda1, and an ext4 filesystem. Other VPS images use NVMe names such as /dev/nvme0n1 and /dev/nvme0n1p1, XFS, or LVM.

Don’t copy a device name from a tutorial into a destructive command. Confirm yours with lsblk first.

2. Make a backup you can restore

Take a provider snapshot or image before resizing, and make sure you know how you would restore it. A snapshot is useful, but it’s not automatically a verified backup. If the data matters, keep another copy somewhere separate and test that it contains what you need.

For databases and other write-heavy services, a live snapshot may capture files at different points in time. Follow your database’s backup guidance or pause writes for the snapshot if consistency matters. For example, a database-native dump or backup is often easier to restore predictably than a raw disk image alone.

A practical, easily missed detail: check that you can access the provider’s recovery console before starting. If the VPS fails to boot, SSH won’t be much help.

3. Change the VPS size in the provider panel

Choose the new plan and follow the provider’s resize instructions. If a shutdown is required, stop the VPS cleanly first:

sudo systemctl poweroff
Enter fullscreen mode Exit fullscreen mode

Wait until the provider reports that the VPS is stopped before applying the resize. Start it again when the panel says the change is complete, then reconnect and inspect the disk:

lsblk
Enter fullscreen mode Exit fullscreen mode

If the disk itself still shows its old size, don’t try to grow partitions yet. Check the provider’s task status and resize documentation. The guest operating system can’t use capacity that the virtual disk hasn’t actually been given.

4. Grow the partition

The following example assumes a regular partitioned disk and the common growpart utility. On Debian or Ubuntu, it is usually provided by cloud-guest-utils:

sudo apt-get update
sudo apt-get install cloud-guest-utils
Enter fullscreen mode Exit fullscreen mode

Suppose lsblk shows /dev/sda as the disk and /dev/sda1 as the root partition. First, ask growpart to show whether it can expand partition 1:

sudo growpart -N /dev/sda 1
Enter fullscreen mode Exit fullscreen mode

If the preview looks right, grow it:

sudo growpart /dev/sda 1
Enter fullscreen mode Exit fullscreen mode

For an NVMe example where the disk is /dev/nvme0n1 and the root partition is /dev/nvme0n1p1, the command is:

sudo growpart /dev/nvme0n1 1
Enter fullscreen mode Exit fullscreen mode

The disk and partition are separate arguments: don’t include the partition number in the disk argument. If your root storage uses LVM, a different partition layout, or no partition table, stop and follow the appropriate procedure for that layout rather than applying this example blindly.

5. Grow the filesystem

Check the filesystem type with lsblk -f or df -hT. The command depends on what you find.

For an ext4 filesystem on /dev/sda1:

sudo resize2fs /dev/sda1
Enter fullscreen mode Exit fullscreen mode

For XFS mounted at /:

sudo xfs_growfs /
Enter fullscreen mode Exit fullscreen mode

These tools grow filesystems; they do not create a backup or fix an incorrect partition choice. Confirm the filesystem and target before running a command.

If your VPS uses LVM, the sequence generally includes growing the physical volume and logical volume as well as the filesystem. The exact commands depend on the volume group and logical volume names, so inspect them first:

sudo pvs
sudo vgs
sudo lvs
Enter fullscreen mode Exit fullscreen mode

Don’t run the non-LVM commands above as a substitute for understanding your LVM layout.

6. Verify the result

Check that the partition and filesystem now show the expected capacity:

lsblk -o NAME,SIZE,FSTYPE,TYPE,MOUNTPOINTS
df -hT
Enter fullscreen mode Exit fullscreen mode

Then check that essential services are healthy. For example:

sudo systemctl --failed
Enter fullscreen mode Exit fullscreen mode

For a web server, database, or queue, also run an application-level health check. A larger disk is only useful if the application can read and write its data normally.

Two practical tips

Leave headroom for snapshots and backups. If the provider charges for snapshots or backup storage separately, a bigger VPS disk can increase those costs too. Check the billing details before resizing, especially when keeping several restore points.

Don’t resize during a deployment or database migration. A provider operation may require a reboot or temporarily affect I/O. Pick a maintenance window, note the current plan and disk layout, and avoid combining the resize with unrelated changes. If something goes wrong, fewer simultaneous changes make diagnosis much easier.

Choosing a provider and plan

For a general-purpose VPS, PowerVPS is one option to compare. Check its current resize, snapshot, and backup policies against your workload before committing; those details can matter as much as the advertised CPU and RAM.

For short-lived GPU workloads, Vast.ai is a different kind of option: GPU rental rather than a like-for-like replacement for a persistent general-purpose VPS. Check the instance and storage terms carefully, and keep important data somewhere durable if the compute instance is temporary.

The Server Rental Guide is also a useful resource when comparing server rental options and figuring out which setup fits your workload.

Summary

A safe VPS resize is a sequence, not just a control-panel click: inspect the layout, make a restorable backup, resize through the provider, grow the correct partition, grow the filesystem, and verify both disk space and services. The commands vary with filesystem and storage layout, so use lsblk, df, and the provider’s documentation to confirm each step. And if the goal is a smaller disk, plan a migration instead of assuming it can be shrunk safely.

Top comments (0)