Move to a bigger plan without losing data

Two ways to get a bigger server

Changing plan can work in two ways. Either the same server gets more CPU, memory and disk, or you create a new, larger server and move your data to it. Which one applies depends on how the change is performed for your service. The control panel and plan details will tell you. This guide covers both, because both end the same way: check everything still works.

Either way, take a backup that you have tested before you start. Note your current IP address, because a new server usually gets a new one, and DNS records and firewall allow lists must be updated.

hostnamectl
ip -br a
lsblk -f
df -hT
free -h

After an in-place upgrade: check memory and CPU

The new CPU count and memory show up after a restart or power cycle. Confirm with the commands below, and add or resize swap if you still need it (see the swap guide). Services that were tuned for less memory, such as databases and PHP, may need their limits raised to use the new capacity.

nproc
free -h
swapon --show

Check whether the disk grew

A bigger plan may give a bigger virtual disk, but the partition and filesystem inside it do not grow by themselves. Compare the size of the disk with the size of its partition. If the disk is larger than the partition, extend them. Check the filesystem type first, because the resize command differs.

lsblk
df -hT /

Extend the partition and filesystem

If the root filesystem is on a plain partition, such as /dev/vda1, grow the partition to fill the disk, then grow the filesystem. Use growpart from cloud-utils-growpart on AlmaLinux or cloud-guest-utils on Ubuntu. Use resize2fs for ext4 and xfs_growfs for XFS. If your root is on LVM, extend the logical volume with lvextend first. These steps work on a running system, but a mistake on the wrong disk is destructive, so double-check the device names against lsblk.

sudo apt install cloud-guest-utils

sudo dnf install cloud-utils-growpart

sudo growpart /dev/vda 1

sudo resize2fs /dev/vda1

sudo xfs_growfs /

df -h /

CHANGED: partition=1 start=2048 old: size=260063 end=262110 new: size=522207 end=524254
Resizing the filesystem on /dev/loop0p1 to 65275 (4k) blocks.
The filesystem on /dev/loop0p1 is now 65275 (4k) blocks long.
ext4 capacity grew: 120553472 -> 246370304 bytes
data blocks changed from 131072 to 196608
XFS growth preserves this file

If you are moving to a new server

Create the new server, install the same operating system, then apply your setup: users, keys, firewall, packages and services. Copy data with rsync over SSH, which transfers only differences, so you can run it once while the old server is live and again at cutover. Exclude virtual filesystems and keep permissions with the archive option.

sudo rsync -aHAX --numeric-ids --info=progress2 -e ssh --rsync-path="sudo rsync" deploy@OLD_SERVER:/var/www/ /var/www/

ssh deploy@OLD_SERVER "sudo mysqldump --single-transaction appdb | gzip" > appdb.sql.gz
gunzip -c appdb.sql.gz | sudo mysql appdb

Cut over safely

Lower the DNS TTL a day before the move, so changes spread quickly. Stop writes on the old server, run a final rsync and database dump, start the services on the new server and test using a hosts-file entry or the new IP before changing DNS. Then update the records, and keep the old server for a few days in case you need to roll back.

curl -I --resolve example.com:443:NEW_SERVER_IP https://example.com/

Verify and clean up

Check services, logs, scheduled jobs, certificates and backups on the new server. Certificates renew only when DNS points to the server that runs Certbot, and cron jobs and timers are not copied by rsync of your data directories. After the cutover has been stable for a few days, cancel or delete the old server.

systemctl --failed
sudo journalctl -p err --since "1 hour ago" --no-pager | tail -n 20
sudo certbot certificates 2>/dev/null
sudo crontab -l