Block Storage Volumes for Databases, Containers, and App Data

A block storage volume is persistent disk-like storage that attaches to a virtual machine independently from its system disk. Use one when application data needs a separate lifecycle from compute: it must survive VM replacement, grow independently, or follow its own backup and recovery plan.

For small teams, that separation matters more than adding storage for its own sake. A database may need more capacity before it needs more CPU. A container can be disposable while its state is not. A processing workload may need temporary working space without making the VM permanently larger.

Raff Technologies supports 3,000+ customers and 15,000+ VMs. Our storage decision rule is to add a separate volume only when it creates a clear lifecycle or recovery boundary. If the data can be recreated with the VM, the system disk may remain the simpler choice.

This guide explains where block storage volumes fit databases, containers, and application data, when object storage is better, and how sizing, backups, and recovery should affect the decision. For the broader model, read Storage and Recovery Architecture for Production Apps.

Block storage volumes separate persistent data from compute

A VM system disk and a block storage volume can both expose a filesystem to Linux or Windows, but they serve different operational roles.

The system disk normally holds the operating system, packages, application runtime, and other data coupled to that VM. A block volume is a separate storage resource that can hold persistent application data without making the boot disk the only data boundary.

That separation is useful when:

• storage grows faster than CPU or RAM;
• the VM should be replaceable without replacing the data;
• a database or application expects filesystem semantics;
• a container workload needs persistent state outside its container layer;
• backup and recovery policies should apply to a specific data area;
• the team wants clearer ownership of persistent data.

The separation does not make the data self-protecting. A volume can preserve deleted, corrupted, or incorrectly migrated data just as faithfully as valid data. Persistence and recoverability are different requirements.

A volume should create a separate lifecycle or recovery boundary; otherwise, the VM system disk may be simpler.

The decision framework starts with storage behavior and lifecycle

Choose storage by how the workload accesses data and how that data should survive infrastructure changes.

The decision can be reduced to four questions:

1. Does the workload require a mounted filesystem? If no, object storage may be a better fit.
2. Should the data survive VM replacement? If yes, separate it from the system disk.
3. Does storage need to grow independently from compute? If yes, a separate volume avoids resizing the whole VM only for disk capacity.
4. Who owns recovery? Persistent storage still needs snapshots, backups, retention, and restore testing.

Use Object Storage vs Block Storage vs VM Disk when the main question is which storage model fits the data rather than how to use a volume.

Databases and containers benefit from clear storage boundaries

Databases are a common block-storage workload because they expect persistent disk behavior, filesystem access, and predictable ownership of their data directory.

A simple self-hosted database layout is:

Raff VM
  ↓
Database service
  ↓
Attached volume
  ↓
Database data directory

A separate volume can make capacity growth and data ownership clearer, but it does not remove database responsibilities. Production databases still need database-aware backups, restore testing, monitoring, upgrade planning, access controls, and enough free space for maintenance operations.

Storage snapshots can be useful recovery points, but a database may require application-aware backup procedures to guarantee the recovery state the team expects. Treat snapshots as one layer of protection, not as a substitute for a tested database recovery process.

Containers create a similar lifecycle problem. Containers are meant to be recreated; important state should not depend on a container writable layer that disappears with the container.

Block storage can fit container workloads that require persistent filesystem data such as:

• self-hosted database directories;
• application state;
• search indexes that are expensive to rebuild;
• plugin or service data;
• processing workspaces that need more capacity than the VM disk provides.

Use object storage instead when the application stores user uploads, media, generated reports, exports, or other file objects that should be shared independently from one application node.

Application files do not all belong on a volume

“Application data” is too broad to map to one storage product.

Classify each data type before choosing its location:

This classification prevents a block volume from becoming a catch-all disk for every file the application creates.

For horizontally scaled applications, shared uploads should normally move outside individual app VMs. A block device attached to one server is not automatically shared storage for every application node. Object storage is usually the cleaner boundary when multiple servers need the same durable files.

Growth, backup, and restore planning determine volume size

Volume sizing should include more than the current dataset.

Plan for:

• normal data growth;
• indexes and database overhead;
• temporary migration or import space;
• logs and retained files;
• filesystem overhead;
• maintenance operations;
• restore testing space;
• alert thresholds and growth headroom.

A database that uses 80 GiB today should not automatically receive an 80 GiB volume. If it grows every month and needs temporary workspace for imports or migrations, the operational requirement is larger than the current dataset.

Monitor both percentage used and expected time to exhaustion. A steadily growing disk can become an incident even when current usage still looks comfortable.

Backups should be planned separately from active capacity. A volume protects the active data path; backups and snapshots create recovery points.

A practical model is:

Volume = active persistent data
Snapshot = point-in-time recovery aid
Backup = scheduled recovery copy with retention
Object storage = durable files or exported backup artifacts where appropriate

Before a risky migration or application change, a snapshot can provide an additional recovery point. For important databases, combine storage-level protection with database-aware backup procedures and verify that the restore process works.

Security and access need deliberate boundaries

Persistent volumes can hold customer records, database files, exports, logs, and other sensitive data. Treat them as part of the production security boundary.

Useful controls include:

• attach the volume only to workloads that need it;
• restrict administrative access to the VM;
• use operating-system permissions for mounted data;
• keep secrets out of general-purpose data directories;
• define who owns the volume and its recovery plan;
• monitor unexpected capacity growth;
• remove unused volumes deliberately rather than leaving them orphaned;
• protect snapshots and backups with appropriate access controls.

Do not treat a separate volume as an isolation boundary by itself. The operating system and application still control access to the mounted filesystem.

A second operational risk is mount state. After a reboot, the application should not silently write into an empty directory on the system disk because the expected volume failed to mount. Document the mount point, test reboot behavior, and monitor the filesystem that actually contains the application data.

Raff Volumes fit workloads that need persistent disk semantics

Raff Volumes provide persistent NVMe block storage for VM workloads that need a disk-like filesystem outside the system disk.

As verified on August 7, 2026, Raff Volumes are available from 10 GiB to 1 TB at $0.08/GiB-month. A 100 GiB volume therefore costs $8.00 per month at the current rate. The live product page is the source of truth for current pricing and limits.

Raff Volumes can grow online without rebooting the VM, and a volume can remain after the VM is deleted so its lifecycle does not have to match the server lifecycle. Volume data is encrypted at rest, and traffic between a VM and its attached volume is unmetered. Linux workloads use the VM disk as /dev/vda, with additional volumes appearing as devices such as /dev/vdb.

Raff Volumes currently cost $0.08/GiB-month and can grow from 10 GiB to 1 TB.

A practical Raff storage model is:

Raff VM system disk
  ├─ operating system
  ├─ application runtime
  └─ disposable local data

Raff Volume
  └─ persistent filesystem data

Raff Object Storage
  └─ uploads, media, exports, and shared objects

Raff Data Protection
  └─ snapshots, backups, retention, and recovery workflows

Use Block Storage vs Local Disk when the primary decision is whether durable data belongs on the VM system disk or a separate volume.

Common block storage mistakes create avoidable recovery risk

Using the VM disk for every type of data

A simple single-disk server is reasonable early on. Separate storage only when the data needs a distinct lifecycle, growth path, or recovery boundary.

Treating a volume as a backup

Persistence does not protect against deletion, corruption, bad migrations, or compromised credentials. Keep independent recovery points.

Putting shared uploads on one application node

If several app servers need the same durable files, object storage is usually a better architectural boundary than a filesystem attached to one VM.

Resizing only after the disk is nearly full

Track growth before capacity becomes urgent. Leave enough space for maintenance and recovery operations.

Skipping restore tests

A snapshot or backup is useful only when the team knows how to recover from it.

Leaving mount behavior undocumented

Document the device, filesystem, mount point, application path, owner, alerting, and recovery procedure.

Conclusion

Block storage volumes are most useful when persistent filesystem data needs a lifecycle separate from the VM.

Use a volume for self-hosted databases, container state, or application data that requires disk semantics and independent capacity growth. Keep user uploads and shared file objects in object storage when filesystem access is unnecessary. Treat the volume as active storage, then add snapshots, backups, retention, monitoring, and restore testing according to the workload’s recovery requirements.

Continue with Storage and Recovery Architecture for Production Apps for the wider storage model or Object Storage vs Block Storage vs VM Disk for the storage-type decision.

Sources

• Raff Volumes
• Raff Object Storage
• Raff Data Protection
• Product facts verified: 2026-08-07