A disk attached to a VPS appears as a device and nothing more. Until it is formatted and mounted it holds nothing and no directory points at it, which is why a freshly attached volume looks like it did not work.

See what is attached

lsblk -f

The new device has no FSTYPE and no MOUNTPOINT. That is how you tell it apart from the system disk, which is already carrying a filesystem.

Format it

sudo mkfs.ext4 -L data /dev/sdb
Run this against the wrong device and the data on it is gone with no prompt and no undo. Read the lsblk output again and confirm the size matches the volume you just attached.

A whole-device filesystem, with no partition table, is normal for a cloud volume and makes it easier to grow later. Partition only if something else expects a partition.

Mount it

sudo mkdir -p /srv/data
sudo mount /dev/sdb /srv/data
df -h /srv/data

The step people forget

A mount made by hand disappears at the next reboot and the directory goes back to being an empty folder on the system disk - which then fills up while the volume sits idle. Write it into fstab by UUID, because device names can change order between boots.

sudo blkid /dev/sdb
# UUID="0a1b2c3d-..." TYPE="ext4"

echo 'UUID=0a1b2c3d-... /srv/data ext4 defaults,nofail 0 2' | sudo tee -a /etc/fstab
sudo mount -a
nofail lets the machine boot if the volume is missing. Without it a detached volume leaves the server stuck at boot, and on a VPS with no console that is a support ticket.

Move data onto it

  1. Stop what writes there — the database, or the web server, so nothing changes mid-copy.
  2. Copy with permissions intact — sudo rsync -aHAX /var/lib/mysql/ /srv/data/mysql/
  3. Point the service at the new path — and start it again.
  4. Keep the old copy until it is proved — rename it rather than deleting it, and remove it a week later.