How to Format and Mount Additional Storage on a Linux VPS: A Step-by-Step Guide

When you order a storage VPS, you get two disks: a small SSD for the OS, and a large HDD for data. The SSD comes pre-formatted and mounted at /. The HDD comes raw — it's yours to partition, format, and mount however you want.

This guide walks through the full process: identifying the disk, creating a partition, formatting it, mounting it, and making the mount persist across reboots. Everything here runs on a standard Linux install (Debian, Ubuntu, Rocky, AlmaLinux).

Step 1: Identify the Disk

First, list all block devices to find your raw disk:

lsblk

You'll see output like this:

NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
vda    252:0    0    20G  0 disk
└─vda1 252:1    0    20G  0 part /
vdb    252:16   0     5T  0 disk

vda is your SSD boot disk — already partitioned (vda1) and mounted at /. vdb is your HDD data disk — raw, no partition table yet.

Confirm it with fdisk -l, which shows more detail:

fdisk -l /dev/vdb

Disk /dev/vdb: 5 TiB, 5497558138880 bytes, 10737418240 sectors
Disk model: QEMU HARDDISK
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

No partition table yet — that's expected for a new disk.

Step 2: Create a Partition

Use fdisk to create a single partition that spans the entire disk:

fdisk /dev/vdb

Inside the interactive prompt:

Welcome to fdisk (util-linux 2.38.1).

Command (m for help): g
Created a new GPT disklabel (GUID: ...).

Command (m for help): n
Partition number (1-128, default 1): [Enter]
First sector (2048-10737418206, default 2048): [Enter]
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-10737418206, default 10737418206): [Enter]

Created a new partition 1 of type 'Linux filesystem' and of size 5 TiB.

Command (m for help): w
The partition table has been altered.
Syncing disks.

The commands: g creates a GPT partition table (correct for disks over 2TB), n adds a new partition accepting all defaults (full disk), w writes the changes.

After writing, you'll have /dev/vdb1.

Step 3: Format the Partition

Format it as ext4:

mkfs.ext4 /dev/vdb1

This takes a moment on a large disk. You'll see output like:

mke2fs 1.47.0 (5-Feb-2023)
Creating filesystem with 1342177024 4k blocks and 167772160 inodes
...
Writing superblocks and filesystem accounting information: done

Step 4: Create a Mount Point and Mount

Create the directory where the disk will be accessible:

mkdir -p /mnt/data

Mount it:

mount /dev/vdb1 /mnt/data

Verify it's mounted:

df -h /mnt/data

Filesystem      Size  Used Avail Use% Mounted on
/dev/vdb1       4.9T   24K  4.6T   1% /mnt/data

It's there. But this mount is temporary — it won't survive a reboot.

Step 5: Make the Mount Persistent with fstab

Get the UUID of the partition. UUIDs are stable across reboots; device names like vdb1 can occasionally shift:

blkid /dev/vdb1

/dev/vdb1: UUID="a1b2c3d4-e5f6-7890-abcd-ef1234567890" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="..."

Copy the UUID value. Now open /etc/fstab in your editor:

nano /etc/fstab

Add a line at the end:

UUID=a1b2c3d4-e5f6-7890-abcd-ef1234567890  /mnt/data  ext4  defaults,nofail  0  2

The nofail option is important: if the disk is unavailable for any reason on boot, the system won't hang waiting for it. Replace the UUID with your actual value.

Test the fstab entry before rebooting:

mount -a

If that returns no errors, the entry is valid. Reboot to confirm it mounts automatically:

reboot

After reboot:

df -h /mnt/data

Should show the disk mounted at /mnt/data.

Step 6: Set Permissions

By default, /mnt/data is owned by root. If you're running an application as a non-root user (which you should be), fix ownership:

chown -R youruser:youruser /mnt/data

Or if running Docker containers, you may need to set permissions based on the UID the container runs as. Check the documentation for the specific application.

BulkVM-Specific Note: ZFS on the Host

The steps above treat /dev/vdb as a plain block device, and that's exactly how it behaves inside your VM. But at the host level, BulkVM's storage nodes use ZFS RAIDZ2 pools backed by large HDD arrays.

You don't manage this — it's transparent. Your VM's virtual disk is a ZFS zvol allocated from that pool. What this means practically:

• You don't need to set up RAID inside your VM; the host pool is not your concern
• Disk I/O performance reflects the HDD pool (sequential throughput is solid; random IOPS are typical HDD)

If you want to see pool health from inside the VM, you can't — zpool status and zfs list only work with host-level ZFS pools. Inside the VM, df -h and lsblk are your tools. The ZFS layer is the host's concern, not the guest's.

If you want ZFS features (snapshots, compression, deduplication) inside the VM itself, you can install ZFS on Ubuntu/Debian and create a pool using /dev/vdb as the backing device. That's a nested ZFS setup — it works, though with some overhead. For most applications (Nextcloud, Jellyfin, Immich), ext4 on the raw virtual disk is simpler and fast enough.

---

Quick Reference

# Find your raw disk
lsblk
fdisk -l /dev/vdb

# Partition (GPT + single partition)
fdisk /dev/vdb
# → g, n, [Enter] x3, w

# Format
mkfs.ext4 /dev/vdb1

# Mount
mkdir -p /mnt/data
mount /dev/vdb1 /mnt/data

# Get UUID for fstab
blkid /dev/vdb1

# Add to /etc/fstab:
# UUID=<your-uuid>  /mnt/data  ext4  defaults,nofail  0  2

# Test fstab
mount -a

# Verify
df -h /mnt/data