Block storage volume setup on a Linux VM means attaching a separate block device, confirming that Linux sees the correct disk, creating or recognizing its filesystem, mounting it at a stable path, and making that mount persistent across reboots.
The most important rule comes before any command: never format a device until you have positively identified it as the new volume. Formatting the wrong block device can destroy the operating system or existing production data.
Raff Technologies provides Raff Volumes for workloads that need disk-like persistent storage separate from the VM system disk. Use the live Volumes and pricing pages for current capacity, performance, resize, and pricing details rather than copying mutable product limits into an evergreen setup guide.
For most teams, the storage decision is:
Use the VM disk for the operating system, a block volume for persistent filesystem data that should scale separately from compute, and object storage for durable API-addressed files such as uploads and archives.
Linux block storage setup: the safe sequence
A production-safe setup usually follows this order:
- attach the volume in the cloud control plane;
- identify the new block device in Linux;
- confirm whether it already contains a filesystem or data;
- create a filesystem only if the volume is new and empty;
- create the mount point;
- mount and verify the filesystem;
- use a stable UUID-based
/etc/fstabentry; - verify the fstab entry before rebooting;
- set application ownership and permissions;
- add monitoring and recovery coverage.
Do not skip the identification step just because you expect a device name such as /dev/vdb.
What block storage is — and when to use it
Block storage presents disk-like capacity to the operating system. Linux can place a filesystem on that device and applications can use it through ordinary paths such as /data or /var/lib/....
Good block-storage workloads include:
- database data directories;
- Docker or container persistent state;
- application files that require filesystem semantics;
- build or processing workspaces;
- large working directories;
- data that should grow independently from the VM root disk.
Block storage is usually a poor fit for data that naturally belongs in an object API, such as public uploads, media libraries, large archives, and generated exports shared across many application nodes.
For the broader storage decision, see Object Storage vs Block Storage vs VM Disk.
Step 1 — Attach the volume, then identify the device
After attaching the volume to the VM, inspect the block-device layout before changing anything:
lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS,UUID,MODEL
A layout may look similar to:
NAME SIZE FSTYPE MOUNTPOINTS vda 80G └─vda1 80G ext4 / vdb 200G
Raff's current public documentation describes attached volumes as standard virtio disks that may appear as devices such as /dev/vdb or /dev/vdc. Treat those names as examples, not guarantees.
Confirm the new device using several signals:
- expected size;
- existing filesystem type;
- current mount points;
- whether partitions already exist;
- whether the disk contains a UUID;
- the cloud-side volume you just attached.
You can also inspect filesystem signatures:
sudo blkid
If the volume already contains a filesystem or data, stop before running mkfs. Mount or recover the existing filesystem instead of overwriting it.
Step 2 — Decide whether the new disk needs a filesystem
A brand-new empty volume must have a filesystem before ordinary Linux applications can use it as a mounted path.
For many general-purpose Linux workloads, ext4 is a reasonable default. XFS is also common, especially on distributions and workloads that standardize on it.
The filesystem decision should match:
- operating-system support;
- expected file sizes and workload pattern;
- resize procedure;
- backup/restore tooling;
- team familiarity.
This guide uses ext4 for the example commands.
Whole-device filesystem or partition?
Linux can place a filesystem directly on a block device or inside a partition. Both models are valid.
For a dedicated cloud data volume, a whole-device filesystem keeps the layout simple. Teams with partitioning standards can create a GPT partition first and then format the partition instead.
The important rule is consistency: know whether your filesystem lives on /dev/vdb, /dev/vdb1, or another device before writing /etc/fstab or performing a future resize.
Step 3 — Format only a confirmed new, empty volume
If you have confirmed that /dev/vdb is the new empty data volume and your design uses a whole-device ext4 filesystem:
sudo mkfs.ext4 /dev/vdb
Then verify the new filesystem signature:
sudo blkid /dev/vdb
Do not copy this command blindly. Replace /dev/vdb only after identifying the correct device on your VM.
If the disk already contains data, do not format it.
Step 4 — Create a stable mount point
Choose a mount path based on ownership and workload purpose.
Examples:
/data /srv/app-data /var/lib/postgresql
Create a generic data mount point with:
sudo mkdir -p /data
Avoid mounting a new empty filesystem over a directory that already contains important files. Once the mount is active, the original directory contents are hidden until the filesystem is unmounted.
For databases or container runtimes, stop the service and follow that application's documented data-directory migration procedure rather than moving live files casually.
Step 5 — Mount the volume and verify it
For the whole-device ext4 example:
sudo mount /dev/vdb /data
Confirm that the expected device is mounted at the expected path:
findmnt /data
Also check capacity and filesystem type:
df -hT /data
A successful mount command is not enough. Verification should confirm:
- source device;
- mount target;
- filesystem type;
- expected capacity;
- expected read/write behavior.
Step 6 — Use UUID in /etc/fstab
Do not rely only on names such as /dev/vdb for persistent production mounts.
Linux's fstab documentation recommends stable identifiers such as UUID= because device names can change when hardware or disk discovery order changes.
Get the filesystem UUID:
sudo blkid /dev/vdb
Example output:
/dev/vdb: UUID="11111111-2222-3333-4444-555555555555" TYPE="ext4"
Back up the existing fstab before editing it:
sudo cp /etc/fstab /etc/fstab.backup
Then add an entry similar to:
UUID=11111111-2222-3333-4444-555555555555 /data ext4 defaults 0 2
Use the real UUID from your server.
Should you use nofail?
nofail allows boot to continue when the data volume is unavailable. That can be useful for optional storage, but it can also allow an application server to boot without a critical database or data mount.
Choose intentionally:
- optional/noncritical data volume →
nofailmay be appropriate; - critical application data → failing loudly may be safer than starting the service against an empty local directory.
The mount policy should match the application's failure behavior.
Step 7 — Verify fstab before rebooting
A broken /etc/fstab entry can create boot or service-start problems.
Check fstab syntax and usability:
sudo findmnt --verify --verbose
Then test the configured mounts:
sudo mount -a
Finally confirm the target again:
findmnt /data
Do not use a production reboot as the first fstab test.
Step 8 — Set ownership for the application, not for convenience
The filesystem may initially be owned by root. Change ownership only to the service account or group that actually needs access.
For an application user called appuser, a simple example is:
sudo chown appuser:appuser /data
Avoid broad shortcuts such as:
chmod 777
They remove useful access boundaries and often hide a service-ownership problem rather than solving it.
For database directories, use the database vendor's expected owner, permissions, and migration procedure.
Step 9 — Verify application behavior
After moving an application to the new mount, verify more than disk visibility.
Check:
- the service actually writes to the mounted filesystem;
- expected ownership and permissions remain correct;
- restart behavior still works;
- the volume remains mounted before the service starts;
- disk usage is visible in monitoring;
- restore procedures reference the correct data path.
A common failure mode is mounting /data correctly while the application continues writing to its old directory.
Block storage vs resizing the VM disk
Adding a separate volume and increasing the root disk solve different problems.
Choose a separate block volume when you want:
- application data separated from the operating system;
- storage capacity managed independently from the root disk;
- a clearer data ownership boundary;
- easier service/data migration between compute layouts;
- a dedicated mount point for a database or application workload.
Choose a larger VM/root disk when the operating system itself is short on capacity and you do not need a separate data boundary.
See Add Volume vs Resize VM Disk for that decision.
Database data on a block volume
A separate block volume can be useful for a self-managed PostgreSQL or MySQL data directory because storage growth is separated from the VM root disk.
But moving an existing live database requires more than mounting storage.
A safe plan normally includes:
- verified database backup;
- service stop or database-native migration method;
- data copy with ownership preserved;
- configuration update;
- mount verification;
- service start;
- integrity/application verification;
- rollback plan.
If your team does not want to own database patching, backups, recovery, and availability at the guest-OS level, compare the workload with Raff Managed Databases.
Docker and container data on block storage
A block volume is a good fit when a self-managed Docker host needs persistent filesystem data beyond the lifecycle of a container image.
Keep the layers distinct:
Raff VM ↓ Linux mounted block volume ↓ Docker bind mount or Docker-managed path ↓ Container application
The cloud volume is not the same thing as a Docker volume object. Docker still needs a bind mount, volume configuration, or storage-driver path that points application data to the mounted filesystem.
For multi-node container platforms, storage semantics become more complicated because a disk attached to one node is not automatically shared across every node.
Object storage is better for many file workloads
Do not put every growing dataset on block storage.
Object storage is often a better fit for:
- user uploads;
- images and video;
- generated reports;
- exported archives;
- backup artifacts;
- files shared by several stateless application nodes.
Use block storage when the software expects a filesystem or block device. Use object storage when the application can address durable files through an object API.
A volume is not a backup
Separating data from the VM root disk improves architecture, but it does not create independent recovery by itself.
Production data still needs a recovery plan that answers:
- what failure are we protecting against?
- how often is data backed up?
- how long are recovery points retained?
- can accidental deletion be recovered?
- can corrupted application data be restored to an earlier state?
- has restore actually been tested?
If a database lives on the volume, database-native backup and recovery may still be required even when infrastructure snapshots exist.
Before relying on Raff Data Protection or any snapshot workflow, verify that the protection method covers the specific disk/data path you need and that its retention matches the workload's RPO/RTO requirements.
Resizing a block volume also requires filesystem planning
Increasing cloud-side volume capacity and increasing usable filesystem capacity are separate operations.
After a provider-side resize, Linux may see a larger block device while the filesystem still has its old size. The expansion procedure depends on whether you use:
- a filesystem directly on the device;
- a partition such as
/dev/vdb1; - LVM;
- ext4;
- XFS;
- another storage layout.
Do not run filesystem-grow commands until lsblk, the partition table, and filesystem type are understood. Shrinking is even more workload- and filesystem-sensitive and should never be assumed from a generic cloud-resize button.
Use the current Raff Volumes page for product-side resize capabilities and the relevant filesystem documentation for guest-side expansion.
For the Linux guest-side procedure across partitions, LVM, ext4, and XFS, continue with Linux Volume Expansion: Filesystem Growth and Verification.
Production checklist
Before formatting
- Confirm the cloud volume you attached.
- Run
lsblkand inspect size, filesystem, UUID, and mount points. - Confirm the target is not the root/system disk.
- Confirm the volume does not already contain data.
Before persistence
- Create the intended mount path.
- Mount the filesystem manually first.
- Verify it with
findmntanddf -hT. - Use UUID rather than only a device name in
/etc/fstab. - Back up
/etc/fstabbefore editing. - Run
findmnt --verify --verbose. - Run
mount -abefore rebooting.
Before production use
- Set service-specific ownership and permissions.
- Verify the application writes to the intended mount.
- Monitor disk capacity.
- Document the volume owner and purpose.
- Define backup/restore coverage.
- Test recovery.
