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 explains the storage decisions teams should make before attaching a volume, how Linux identifies Raff attached volumes, how persistent mounts should be designed, and how backups and recovery fit into the storage model.
Raff Technologies provides Raff Volumes for Linux VM workloads that need persistent storage separate from the VM system disk. Raff Volumes currently cost $0.08/GiB-month and are designed for data that should grow independently from compute resources.
On Raff Linux VMs, the operating system disk is typically /dev/vda. Attached volumes appear as additional virtio disks such as /dev/vdb or /dev/vdc. The most important safety rule is simple: never format a disk until you have confirmed that it is the new attached volume, not the system disk.
Separate storage starts with the right workload decision
A volume is not just extra space. It creates a storage boundary.
Use an attached volume when data should live separately from the operating system, such as:
- database files
- Docker persistent data
- application state
- processing workspace
- large working directories
Use the VM disk for the operating system, installed packages, and application runtime. Use object storage for durable file objects such as uploads, media, exports, and archives.
Linux identifies attached volumes differently from system disks
Before formatting or mounting any disk, confirm the device identity.
A common Raff VM layout looks like:
/dev/vda → operating system disk /dev/vdb → attached Raff Volume /dev/vdc → additional attached volume
Check available disks first:
lsblk
Verify:
- disk size matches the new volume
- mount points are understood
- the system disk is not selected accidentally
Formatting the wrong device can destroy the operating system or existing data.
A persistent volume needs a filesystem and mount path
After confirming the correct device, create a filesystem suitable for the workload.
For many Linux VM workloads, ext4 is a practical default.
A clean storage layout should have:
| Component | Purpose |
|---|---|
| Volume | Persistent application data |
| Mount path | Predictable location for services |
| Owner | Person or team responsible for the data |
| Backup policy | Recovery expectation |
| Monitoring | Capacity awareness |
Example mount paths:
/data /var/lib/postgresql /var/lib/docker
The correct path depends on the application. A database directory, container storage path, and media workspace should not automatically share the same location.
UUID-based mounts prevent boot problems
Production Linux systems should avoid relying only on device names in /etc/fstab.
Device names can change when disks are added or removed. UUID-based entries are more predictable.
Check the filesystem UUID:
blkid
Then create the persistent mount entry using the UUID.
After updating fstab, test before rebooting:
mount -a
A failed mount configuration can prevent a clean boot, so always validate changes before restarting production systems.
Volumes are useful for databases and containers
Databases often benefit from separate storage because their data grows independently from application code.
A practical layout:
VM system disk ↓ OS + application runtime Attached Raff Volume ↓ Database files
Docker workloads also commonly use volumes when container data must survive rebuilds or image updates.
Docker container ↓ Persistent mounted volume ↓ Application state
A volume improves separation, but it does not replace database backups, restore testing, or application-level recovery planning.
Object storage solves a different storage problem
Not every growing dataset needs a block volume.
Use object storage for:
- user uploads
- images
- videos
- reports
- exports
- backup archives
Use block storage when software expects filesystem behavior. Use object storage when files should exist independently from a VM lifecycle.
For the broader storage decision, read Object Storage vs Block Storage vs VM Disk.
Production volumes need ownership and recovery planning
A production volume should always have:
- a documented purpose
- a known owner
- backup coverage
- snapshot strategy
- restore procedure
- storage monitoring
Raff Volumes work best when combined with Raff Data Protection and tested recovery procedures.
A volume that has no owner eventually becomes forgotten infrastructure.
Decision framework for Linux VM storage
| Need | Recommended choice |
|---|---|
| Operating system and packages | VM disk |
| Database files | Block storage volume or managed database |
| Docker persistent state | Block storage volume |
| User uploads | Object storage |
| Long-term archives | Object storage |
| Temporary processing files | VM disk or block storage depending on size |
The simplest rule is:
Use VM disk for the server. Use volumes for persistent disk-like data. Use object storage for durable files.
Conclusion
Setting up a Linux VM volume is not only a formatting task. The important decisions are where data belongs, how it should survive changes, who owns it, and how it can be recovered.
Raff Volumes give teams a separate persistent storage layer for databases, containers, and application data without forcing compute and storage growth to happen together. When combined with backups, snapshots, and tested restore procedures, separate storage boundaries make production systems easier to operate.
Before adding a volume, define the data it will hold. Before formatting a disk, confirm the device. Before trusting production storage, test recovery.