Block storage volume setup on a Linux VM means preparing an attached disk so it can safely hold persistent app data, database files, container state, or processing workspace.
This guide is for teams that already understand why they need a separate volume and now want the safe Linux setup model without turning the page into a narrow command-only tutorial. It explains how to think about device names, formatting, mount paths, /etc/fstab, permissions, Docker paths, database paths, snapshots, backups, and restore testing.
Raff Technologies provides Raff Volumes for Linux VM workloads that need persistent NVMe-backed storage separate from the VM system disk. Current Raff Volume pricing is $0.10 per GB-month. Raff VMs commonly show attached volumes as virtual disks such as /dev/vdb, /dev/vdc, or /dev/vdd, while the system disk is usually /dev/vda.
The main safety rule is simple: never format a disk until you have confirmed that it is the new attached volume, not the system disk.
If you are still deciding whether to add a volume, read When to Add a Volume Instead of Resizing a VM Disk. If you need the broader storage model, read Storage and Recovery Architecture for Production Apps.
Linux VM volume setup should start with a clear purpose
A volume should have a job before it is mounted.
Good purposes include:
- Database data directory
- Docker persistent data
- Self-hosted app data
- App-generated local files
- Processing workspace
- Search index storage
- Media-processing scratch space
- Development environment storage
- Large working directory
Weak purposes include:
- Extra disk for random files
- Temporary test storage nobody owns
- User uploads that should live in object storage
- Backup archives that should live outside the VM
- Logs with no retention policy
- Data nobody knows how to restore
A good volume plan answers:
What workload owns this volume?
Where will it be mounted?
What data will live on it?
Who is responsible for it?
How will it be backed up?
How will restore be tested?
A block storage volume is not only extra capacity. It is a storage boundary.
Understand the Linux disk layout before changing anything
A Linux VM usually has a system disk and one or more attached disks.
On Raff VMs, the system disk is typically:
Attached volumes commonly appear as:
/dev/vdb
/dev/vdc
/dev/vdd
The exact name can vary, so always inspect the VM before formatting or mounting.
Use:
Example output:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
vda 252:0 0 80G 0 disk
├─vda1 252:1 0 79G 0 part /
└─vda2 252:2 0 1G 0 part /boot
vdb 252:16 0 100G 0 disk
In this example:
/dev/vda is the system disk/dev/vda1 is mounted at //dev/vdb is the attached 100 GB volume/dev/vdb has no mount point yet
Use this command for more detail:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
Example:
NAME SIZE FSTYPE MOUNTPOINTS
vda 80G
├─vda1 79G ext4 /
└─vda2 1G ext4 /boot
vdb 100G
If the new disk has no filesystem and no mount point, it may be ready to format. If it already has a filesystem, stop and confirm whether it contains existing data.
The safest default filesystem for simple Linux volumes
For many Linux VM workloads, ext4 is a safe default filesystem.
It is widely supported, simple to operate, and suitable for many app, database, and container storage paths.
A common formatting command is:
But this command deletes existing data on /dev/vdb.
Before formatting, confirm:
- The device is the attached volume
- The device is not
/dev/vda
- The device is not mounted at
/
- The size matches the created Raff Volume
- The volume does not already contain needed data
- A backup exists if the volume has been used before
A safe pre-format check:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
Do not format these paths:
Those are part of the VM system disk.
For simple workloads, formatting the full disk such as /dev/vdb is usually acceptable. Some teams prefer creating a partition first and formatting /dev/vdb1. Both can work, but the chosen approach should be documented so future recovery is clear.
Mount paths should explain the volume purpose
A mount path should be easy to understand later.
Good mount paths:
/mnt/data
/srv/app-data
/srv/postgres-data
/srv/docker-data
/srv/media-workspace
Weak mount paths:
/mnt/new
/mnt/test
/mnt/disk1
/data2
The mount path should tell the next person what the volume is for.
A general-purpose mount path:
An app-specific mount path:
A database-specific mount path:
mkdir -p /srv/postgres-data
Mount the volume after formatting:
Verify:
Example:
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 79G 6.2G 69G 9% /
/dev/vdb 98G 24K 93G 1% /mnt/data
The mount works at this point, but it is not reboot-safe until /etc/fstab is configured.
Persistent mounts should use UUIDs in fstab
A manual mount is temporary. A persistent mount survives reboot.
For production workloads, add the volume to /etc/fstab.
Avoid relying only on a device path such as /dev/vdb in /etc/fstab when a UUID is available. Device names can change in some environments. UUID-based mounts are safer and easier to verify.
Get the UUID:
Example output:
/dev/vdb: UUID="12345678-aaaa-bbbb-cccc-123456789abc" BLOCK_SIZE="4096" TYPE="ext4"
A safe /etc/fstab entry:
UUID=12345678-aaaa-bbbb-cccc-123456789abc /mnt/data ext4 defaults,nofail 0 2
The nofail option helps the VM continue booting if the volume is temporarily unavailable.
A complete example:
# /etc/fstab
UUID=11111111-2222-3333-4444-555555555555 / ext4 defaults 0 1
UUID=66666666-7777-8888-9999-000000000000 /boot ext4 defaults 0 2
UUID=12345678-aaaa-bbbb-cccc-123456789abc /mnt/data ext4 defaults,nofail 0 2
After editing /etc/fstab, test before rebooting:
umount /mnt/data
mount -a
df -h
findmnt /mnt/data
If mount -a returns an error, fix /etc/fstab before rebooting. A bad /etc/fstab entry can create boot problems.
Permissions should match the application user
A mounted volume is often owned by root by default.
Check:
Example:
drwxr-xr-x 3 root root 4096 Jul 24 12:00 /mnt/data
Create an app directory:
If the app runs as a user named app:
chown -R app:app /mnt/data/app
If the app runs as www-data:
chown -R www-data:www-data /mnt/data/app
Avoid broad permissions such as:
A production mount should use the narrowest permissions the workload needs.
A simple write test:
echo "volume test" > /mnt/data/test.txt
cat /mnt/data/test.txt
rm /mnt/data/test.txt
If the application cannot write to the mounted path, the problem is usually ownership, group permissions, or the app writing to a different path than expected.
Docker workloads need stable data paths
Docker containers are easy to recreate. Their important data should not disappear when containers are rebuilt.
A volume-backed Docker layout might use:
/mnt/data/docker/app
/mnt/data/docker/postgres
/mnt/data/docker/redis
Example directory setup:
mkdir -p /mnt/data/docker/app
mkdir -p /mnt/data/docker/postgres
mkdir -p /mnt/data/docker/redis
A simple Docker Compose pattern:
services:
app:
image: your-app:latest
volumes:
- /mnt/data/docker/app:/app/data
postgres:
image: postgres:16
environment:
POSTGRES_PASSWORD: change-me
volumes:
- /mnt/data/docker/postgres:/var/lib/postgresql/data
Before moving existing Docker data:
- Stop containers
- Back up current data
- Copy files with ownership preserved
- Update volume paths
- Start containers
- Check logs
- Verify the app
- Keep a rollback plan until tested
A block volume is a good fit for container data that needs filesystem persistence. It is not the best default for user uploads, reports, media, or archive files. Those usually fit object storage better.
For broader storage planning, read Storage and Recovery Architecture for Production Apps.
Database storage needs backup-aware setup
A block storage volume can hold a self-hosted database data directory.
A typical layout:
Raff VM
↓
System disk = OS and database service
↓
Raff Volume = database data directory
Possible database paths include:
/var/lib/postgresql
/var/lib/mysql
/srv/postgres-data
/srv/mysql-data
But moving production database data is not only a Linux mount task.
Before moving a database to a volume:
- Take a database-aware backup
- Confirm the volume is mounted after reboot
- Stop the database service
- Copy data with ownership and permissions preserved
- Update the database configuration
- Start the database
- Check database logs
- Run safe queries
- Test application connection
- Confirm backups still run
- Keep rollback path until verified
A volume gives the database a storage boundary. It does not replace database backup strategy.
For many teams, Raff Managed Databases may be a better fit than self-hosting a database on a VM plus volume. Use self-hosted database volumes when control matters. Use managed databases when reducing operations work matters.
For backup planning, read Database Backup Strategy for SaaS Apps.
Object storage is better for durable file objects
A Linux volume is disk-like storage attached to a VM. Object storage is a service for durable file objects.
Use object storage for:
- User uploads
- Images
- PDFs
- Media files
- Generated reports
- Export files
- Import files
- Backup archives
- Static assets
- Retained artifacts
- Files shared across services
A common pattern:
App VM
↓
Managed Database stores metadata
↓
Object Storage stores files
Use a block volume when the workload needs filesystem behavior. Use object storage when files should live outside the VM lifecycle.
For example:
Object Storage input
↓
Worker VM with attached volume for temporary processing
↓
Object Storage output
↓
Database metadata
This keeps final files outside the VM, while still giving workers local disk-like space for processing.
For upload-heavy apps, read App Uploads: VM Disk vs Object Storage for SaaS Teams.
Volume setup should include snapshots and restore testing
A mounted volume can hold production data. That means it needs a protection plan.
Ask:
- What data lives on the volume?
- Who owns the volume?
- How fast does it grow?
- What happens if it is deleted?
- What happens if files are corrupted?
- Does it need snapshots before risky changes?
- Does it need scheduled backups?
- Does the database need database-aware backups?
- How will the team test restore?
- What should be stored in object storage instead?
Use snapshots before risky changes such as:
- Database migrations
- Major app releases
- Container storage changes
- Large imports
- File cleanup jobs
- Service upgrades
- Configuration changes
Use backups for scheduled recovery history and longer-term protection.
Use restore testing to prove the volume, VM, app, database, and storage paths can actually recover.
Common setup mistakes to avoid
The most serious mistake is formatting the system disk or a disk that already contains data.
Always check:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS
before running mkfs.
Mounting the volume but not adding fstab
A manually mounted volume disappears after reboot unless /etc/fstab is configured.
Use UUID-based /etc/fstab entries and test with:
Using vague mount paths
A path like /mnt/disk1 does not explain the volume purpose.
Prefer paths like /srv/app-data, /srv/postgres-data, or /mnt/data.
Giving broad write permissions
Avoid chmod -R 777.
Set ownership for the app user or service account.
Moving database files without a backup
Database migration to a new storage path needs a database-aware backup and rollback plan.
Storing uploads on a volume by default
Uploads usually belong in object storage.
Use a volume for active disk-like work, not as the default file archive.
Forgetting monitoring
A larger disk without alerts only delays the next disk-full incident.
Set disk usage alerts and growth expectations.
Skipping restore testing
A mounted and backed-up volume still needs restore testing.
Recovery should be proven before production failure.
Linux volume readiness checklist
Before using a mounted volume in production, confirm:
A volume without documentation becomes hidden infrastructure.
Hidden infrastructure becomes recovery risk.
A practical Raff Linux volume model
A clean Raff Linux storage model looks like this:
This model keeps each layer responsible for the right kind of data.
Use Raff Volumes when a Linux VM needs disk-like persistent storage. Use Raff Object Storage when files should live outside the VM lifecycle. Use Raff Data Protection when snapshots, automated backups, retention, and restore planning matter.
The setup is successful when the volume has a purpose, a mount path, a filesystem, a reboot-safe mount, correct permissions, and a recovery plan.