Block Storage Volumes for Databases, Containers, and App Data

Block storage volumes are attachable storage devices that give a VM or workload additional persistent disk capacity outside the base system disk.

For small teams, this matters because storage growth rarely matches compute growth. A database can need more disk before it needs more CPU. A Docker app can need persistent data without a larger VM. A media workload can need separate storage for uploads, generated files, logs, or working data. If every storage problem is solved by resizing the main VM, the architecture can become harder to recover, migrate, and operate.

Raff Technologies provides Block Storage Volumes for teams that need NVMe-backed storage they can attach, expand, snapshot, and manage separately from the VM. Current Raff Volume pricing is $0.10 per GB-month. Raff Volumes are useful for databases, container volumes, application data, media workloads, backup staging, and development environments.

This guide explains when to use a block storage volume, when the VM disk is enough, when object storage is better, and how volumes fit into a practical Raff architecture with Raff VM, Data Protection, Object Storage, and databases.

Block storage volumes solve a different problem than the VM disk

A VM disk usually starts as the system disk.

It holds the operating system, packages, application runtime, logs, and sometimes application data. That is fine at the beginning. But as workloads grow, mixing everything into the system disk creates operational problems.

A block storage volume gives the team a separate disk-like device that can be attached to a VM and mounted for a specific purpose.

The main benefit is separation.

The VM can stay focused on compute and runtime. The volume can hold the persistent data that grows, changes, or needs separate protection.

A block volume is not the same as object storage. It behaves like a disk attached to a server. Your app, database, or container runtime reads and writes files through the filesystem.

Use block storage when the workload expects a filesystem or database data directory. Use object storage when the workload stores objects such as uploads, exports, reports, media files, backup archives, or generated artifacts.

The quick decision framework

Use this table before adding a volume.

A useful rule:

Use a volume when the workload needs disk behavior. Use object storage when the workload needs durable object storage.

The volume should have a clear job before it is created.

Volumes are useful when storage grows faster than compute

One common mistake is scaling the whole VM because disk is full.

That can waste money and complicate sizing.

For example:

The app needs 200 GB more storage.
The CPU and RAM are still fine.

If the only answer is "resize the VM," the team may pay for compute it does not need. A volume can solve the storage problem directly.

Add a block storage volume when:

• The workload needs more disk but not more CPU or RAM
• The data should be separated from the operating system
• The database needs dedicated storage
• Docker volumes are growing
• App data should survive VM-level changes more cleanly
• Storage needs to be expanded independently
• Snapshots are needed for a specific data area
• Multiple environments need repeatable storage layout
• The team wants clearer data boundaries

Do not add a volume just because it feels more advanced.

If the app is small, the system disk has enough room, and recovery needs are simple, the VM disk may be enough. Add a volume when it creates operational clarity, not only because the product exists.

Database storage needs stricter thinking

Databases are one of the strongest block storage use cases.

A database expects low-latency disk behavior, filesystem consistency, and predictable storage. PostgreSQL, MySQL, MongoDB, and similar systems do not treat storage like a simple file bucket. They write data files, indexes, WAL or transaction logs, temporary files, and metadata through disk-level operations.

A database storage layout might be:

Raff VM
  ↓
Database service
  ↓
Attached volume mounted at database data path

This can be useful when the team wants self-hosted database control on a VM.

Use a volume for self-hosted database storage when:

• The database is tied to a specific VM
• The team needs control over database configuration
• The database data grows faster than compute
• The database should have a separate filesystem
• Snapshot or backup planning needs a clear data boundary
• The team understands database-aware backup requirements

But a volume does not remove database operations work.

For production databases, still plan:

• Database-aware backups
• Restore testing
• Replication where needed
• Upgrade process
• Monitoring
• Disk usage alerts
• Connection limits
• Corruption recovery
• Retention policy
• Security and access controls

A volume gives the database a storage layer. It does not replace database backup strategy.

For many small 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.

Containers need persistent storage boundaries

Containers are easy to recreate. Container data is not.

A Docker or Kubernetes workload may need persistent storage for:

• Database data
• Uploaded files
• Queue state
• Search indexes
• App-generated files
• Local cache
• Plugin data
• Build artifacts
• Development data
• Stateful service directories

If the container writes important data only inside its writable layer, that data can be lost when the container is recreated.

A better pattern is:

Container runtime
  ↓
Mounted volume
  ↓
Persistent data directory

For Docker Compose, that may mean using a mounted host directory or named volume that sits on an attached block volume.

For Kubernetes, persistent workloads need a more careful storage model. Some state may fit persistent volumes. Some should move to managed databases. Some files should move to object storage. The decision depends on the workload.

Use block storage for container data when:

• The container expects filesystem access
• Data must persist across container rebuilds
• The workload is stateful
• You need disk-like semantics
• The data is tied to one service or node
• Object storage would require app changes

Use object storage instead when:

• The files are user uploads
• The files need to be shared by multiple app servers
• The data is mostly read/write objects
• The app can store object keys in a database
• Files should survive server rebuilds cleanly
• Long-term retention matters more than filesystem access

For the broader decision, read Object Storage vs Block Storage vs VM Disk.

App data should be classified before choosing storage

"App data" is too broad.

Before choosing a volume, classify the data.

This classification prevents the common mistake of putting everything on a mounted disk.

A volume is useful, but it should not become a dumping ground.

A clean app storage model may look like this:

Managed Database = durable records
Object Storage = uploads, reports, artifacts
Block Volume = database files, container state, processing workspace
VM Disk = OS, packages, app runtime

The more clearly each layer is defined, the easier the app is to recover and scale.

Volumes are not a replacement for backups

A replicated block storage volume protects against some infrastructure failures, but it is not the same as a backup.

If a user deletes data, the deletion is written to the volume. If an app corrupts files, the corrupted data is stored. If a bad migration changes the database, the volume reflects that change. If ransomware or a script damages data, the volume alone cannot decide what the correct previous state was.

That is why teams need snapshots and backups.

Use volumes for active storage. Use snapshots and backups for recovery points.

A simple model:

Volume = active data
Snapshot = short-term point-in-time recovery
Backup = scheduled or longer-retention recovery
Object storage archive = retained files or exported backup artifacts

Raff Data Protection supports snapshots and automated backups with retention options, replicated storage, and recovery workflows. Use it with volumes and VMs where recovery matters.

Snapshots are useful before risky changes

Snapshots are useful when the team needs a quick recovery point.

Examples:

• Before a database migration
• Before a major app release
• Before changing container storage
• Before importing a large dataset
• Before deleting old files
• Before upgrading a self-hosted service
• Before testing a risky configuration change

A snapshot is especially useful when the team needs to roll back quickly.

But snapshots should not be the only protection strategy for production databases. A database may need application-aware backups, exports, transaction logs, point-in-time recovery, or managed database features.

Use snapshots for operational recovery. Use database-aware backups for durable data recovery.

A safe pattern before a risky migration:

Take snapshot
  ↓
Run migration
  ↓
Verify app and database
  ↓
Keep or delete snapshot according to retention policy

Snapshots are easy to create. Retention discipline is what keeps costs and recovery points under control.

Object storage is better for shared files and archives

Block storage is attached storage. Object storage is a service for storing objects.

That difference matters.

Use object storage for:

• User uploads
• Media files
• Generated reports
• Export files
• Backup archives
• Static assets
• Attachments
• Artifacts
• Long-term retained files
• Files shared across app servers
• Files accessed by functions or workers

Object storage is usually better when files need to survive VM rebuilds, be shared across services, or be retained independently from a single server.

A common SaaS pattern:

App VM
  ↓
Managed Database stores metadata
  ↓
Object Storage stores files

Use a volume for active filesystem data. Use object storage for durable file objects.

For upload-heavy apps, read App Uploads: VM Disk vs Object Storage for SaaS Teams.

Volume sizing should include growth and recovery

Sizing a volume is not only a capacity question.

Teams should plan for:

• Current data size
• Monthly growth
• Temporary working space
• Import/export space
• Database index growth
• Log growth
• Snapshot storage
• Backup retention
• Restore testing space
• Rebuild margin
• Alert thresholds

A volume that is "just enough" today can become risky quickly.

For example:

Current database: 80 GB
Monthly growth: 12 GB
Import workspace: 20 GB
Safety margin: 30%

That workload should not start with an 80 GB volume.

Good sizing questions:

• How fast does the data grow?
• What happens when disk reaches 80%?
• Does the app need temporary files?
• Are indexes growing faster than data?
• How often are old files removed?
• How long are snapshots retained?
• Where will backups live?
• Can the volume be expanded without downtime?
• Does the filesystem support the planned growth?
• Who receives disk usage alerts?

Raff Volumes supports live resize, but resize should not replace monitoring. At $0.10 per GB-month, resizing should still be paired with growth estimates, retention planning, and disk usage alerts.

Multi-attach should be used carefully

Multi-attach can be useful, but it should not be treated like normal shared storage.

A disk attached to more than one machine can create data consistency problems if the filesystem or application is not designed for shared access. Many normal filesystems expect one writer. Many databases expect exclusive control over their data directory.

Use multi-attach carefully and only when the workload supports it.

Safer multi-node file sharing patterns often use:

• Object storage
• Managed databases
• Application-level coordination
• Distributed filesystems designed for shared access
• Cluster-aware storage systems

Do not attach one database volume to multiple VMs and write to it from all of them unless the database and storage design explicitly support that model.

For most small teams, multi-attach is an advanced feature. Use it for specific supported workflows, not as a shortcut to shared storage.

Security and access boundaries matter

Volumes can hold sensitive data.

A volume may contain:

• Database records
• Customer files
• Logs
• Application secrets accidentally written to disk
• Import files
• Export files
• Backups
• PII or business data
• Credentials or tokens in local files

Treat volumes as production data.

Security practices include:

• Attach volumes only to the VM that needs them
• Restrict SSH access to the VM
• Use OS-level permissions
• Keep application secrets out of data directories
• Avoid writing sensitive debug dumps
• Use private networking where relevant
• Snapshot and backup with retention rules
• Delete unused volumes
• Document volume purpose and owner
• Monitor disk usage and unexpected growth
• Keep database credentials scoped
• Avoid broad access to backup artifacts

Storage is not only capacity. It is part of the security boundary.

A practical Raff storage architecture

A clean Raff architecture uses each storage layer for the right job.

This architecture avoids forcing one storage product to solve every problem.

Example for a Docker app:

Raff VM
  ↓
Docker Compose app
  ↓
Attached volume for container data
  ↓
Object Storage for uploads
  ↓
Managed Database for records
  ↓
Snapshots and backups for recovery

Example for self-hosted database:

Raff VM
  ↓
Database service
  ↓
Attached volume for data directory
  ↓
Snapshots before risky changes
  ↓
Database-aware backup to retained storage

Example for media processing:

Object Storage input
  ↓
Worker VM with attached volume for temporary processing
  ↓
Object Storage output
  ↓
Database metadata

Use the smallest architecture that keeps data recoverable and easy to operate.

Volume readiness checklist

Before adding a production volume, check:

• The volume has one clear purpose.
• The workload needs disk behavior, not object storage.
• The VM disk is not being used as a catch-all data store.
• The mount path is documented.
• The filesystem choice is documented.
• The application knows where persistent data lives.
• Disk usage alerts are planned.
• Growth rate is estimated.
• Snapshot policy is defined.
• Backup policy is defined.
• Restore testing is planned.
• Sensitive data handling is understood.
• Unused volumes will be deleted.
• The team knows when object storage is better.
• The team knows when managed databases are better.
• The team knows who owns the volume.

A volume without an owner becomes forgotten infrastructure. Forgotten infrastructure becomes risk.

Common mistakes to avoid

Using the VM disk for everything

The system disk should not become the database store, upload store, log archive, and processing workspace forever.

Separate data when it creates clearer operations.

Using block storage for user uploads by default

User uploads are often better in object storage.

Use block storage when the app needs filesystem behavior.

Assuming replication means backup

Replication protects availability. It does not protect against accidental deletion, corruption, or bad migrations.

Use snapshots and backups.

Adding volumes without mount documentation

If nobody knows what is mounted where, recovery becomes harder.

Document mount paths, purpose, owner, and recovery process.

Treating multi-attach like simple shared storage

Shared write access requires careful design.

Do not use multi-attach as a shortcut unless the workload supports it.

Ignoring disk growth

Storage issues often arrive slowly, then suddenly.

Set alerts before the disk is nearly full.

Forgetting restore testing

A backup or snapshot strategy is incomplete until the team has tested recovery.

Block storage volumes should create clearer operations

A block storage volume is useful when it makes storage easier to scale, protect, recover, and reason about.

Use Raff Volumes when a VM workload needs persistent disk behavior for databases, container data, application files, media processing, or working storage. Use Raff Object Storage when files should live outside compute as durable objects. Use Raff Managed Databases when database operations should be managed rather than self-hosted. Use Raff Data Protection when recovery points, retention, and restore planning matter.

The best storage architecture is not the most complex one. It is the one where every layer has a clear job and the team can explain how data is recovered when something goes wrong.