← All blogs

Carve a Dedicated /data Volume Out of Free LVM Space on Ubuntu

Sep 2026 · 6 min read · Storage

When you install Ubuntu Server on a modern machine, the installer hands you a 100 GB root LV and quietly leaves the rest of your NVMe inside the volume group as unallocated space. This guide walks through claiming that free space as a dedicated /data logical volume — ext4 formatted, fstab-mounted, and ready for services that shouldn't live on the root filesystem.

Why a dedicated /data volume

Most self-hosted services — Docker volumes, database data directories, media libraries, backup snapshots — shouldn't share a filesystem with the OS. Putting them on a separate volume gives you clean boundaries:

• Independent growth. Resize /data without touching root, or vice versa.
• Easier backups. Snapshot or back up the data LV without carrying the entire root filesystem.
• Cleaner reinstalls. Reinstall the OS on the root LV while /data survives untouched.
• Cleaner quotas and monitoring. Disk-pressure alerts point at the right layer.

And critically, on Ubuntu Server the LVM installer already leaves the room for it. You just have to carve it out.

What you'll end up with

Prerequisites

• Ubuntu Server installed with LVM partitioning (the default)
• sudo access on the target machine
• A confirmed backup or simply a throwaway machine — these commands only touch newly allocated space, but mistakes in fstab can prevent boot. Read each command before running it.

Step 1 — Confirm what's free

Before carving anything, see the lay of the land. You're looking for a Volume Group with more capacity than its existing logical volumes consume.

sudo vgs

Expected output (sizes will differ):

  VG        #PV #LV #SN Attr   VSize    VFree
  ubuntu-vg   1   1   0 wz--n- <950.00g <850.00g

The #LV column currently shows 1 — just the root volume. The VFree column shows what's available for new LVs. That gap is your working room.

Cross-check the existing logical volume:

sudo lvs

  LV        VG        Attr       LSize
  ubuntu-lv ubuntu-vg -wi-ao---- 100.00g

Step 2 — Create the new logical volume

LVM resolves VG names with double-hyphens in device paths but single hyphens in the actual vgcreate / lvcreate arguments. The path /dev/mapper/ubuntu--vg-data--lv maps back to the VG named ubuntu-vg.

sudo lvcreate -l +90%FREE -n data-lv ubuntu-vg

-l +90%FREE allocates 90% of the volume group's remaining free space. If you'd rather pick a specific size, swap it for -L 800G. The new LV now shows up in sudo lvs alongside ubuntu-lv.

Step 3 — Format with ext4

ext4 is the boring, safe choice — a stable journaling filesystem with years of production use and full fstab tooling. xfs is equally valid; pick what your distro supports best.

sudo mkfs.ext4 /dev/mapper/ubuntu--vg-data--lv

This takes seconds on an NVMe. The filesystem is created with a UUID; record it from the command output if you ever need to reference it directly:

sudo blkid /dev/mapper/ubuntu--vg-data--lv

Step 4 — Mount it and verify

Create the mount point and attach the new filesystem to it:

sudo mkdir -p /data
sudo mount /dev/mapper/ubuntu--vg-data--lv /data

Confirm the mount is healthy and the size is what you expect:

df -h /data

Filesystem                               Size  Used Avail Use% Mounted on
/dev/mapper/ubuntu--vg-data--lv          845G   77M  802G   1% /data

If the size matches what you allocated and the used column is tiny, the volume is live.

Step 5 — Make it survive a reboot

mount by itself is per-session — the moment the box reboots, /data disappears until you mount it again. To make it persistent, add an entry to /etc/fstab:

echo "/dev/mapper/ubuntu--vg-data--lv  /data  ext4  defaults  0  2" \
  | sudo tee -a /etc/fstab

The trailing 0 2 means "don't dump" and "fsck after root." For a data volume on ext4, that order is correct. Databases and similar write-heavy filesystems usually want 0 0 instead — skip the periodic fsck and rely on the application for consistency.

Step 6 — Validate fstab before rebooting

A malformed fstab entry can prevent the system from booting cleanly. Validate it without rebooting:

sudo mount -a

If the command returns with no output and /data stays mounted, the entry is sound. If it complains, fix the line in /etc/fstab and re-run before you ever reboot.

Troubleshooting

Useful commands

# Inspect the LVM stack
sudo pvs        # physical volumes
sudo vgs        # volume groups (capacity and free space)
sudo lvs        # logical volumes (sizes and attributes)

# Mount state
findmnt /data
mount | grep /data

# Filesystem identity
sudo blkid /dev/mapper/ubuntu--vg-data--lv

# Grow the LV later when you need more space
sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-data--lv
sudo resize2fs /dev/mapper/ubuntu--vg-data--lv

Resize when /data fills up

LVM's main selling point is that the volume doesn't have to stay the size you first carved. When /data fills, free space in the VG, and:

sudo lvextend -l +100%FREE /dev/mapper/ubuntu--vg-data--lv
sudo resize2fs /dev/mapper/ubuntu--vg-data--lv
df -h /data

The filesystem grows online while mounted — no downtime. Shrinking ext4 is possible but more delicate; do it offline and with a backup.

Closing notes

What makes this five-minute job feel delicate isn't the carving — it's the fstab step. A misplaced space in that file can prevent a box from booting, and that's the part worth doing carefully: sudo mount -a to validate, then a planned reboot to confirm. The rest is mechanical, and the payoff is a clean separation between OS and data that pays for itself the first time you reinstall or migrate a service.

← All blogs