When to Add a Volume Instead of Resizing a VM Disk

Add a block storage volume when storage needs to grow independently from CPU, RAM, or the VM's system disk. Resize the VM disk when the operating-system disk itself is too small. If the workload also needs more compute, resize the VM rather than solving only the storage symptom.

That distinction matters because storage growth and compute growth do not always happen together. A database can grow while the application still has enough CPU. A Docker workload can need persistent data while the VM size remains appropriate. A processing workload can need workspace without requiring a larger server.

At Raff Technologies, the same decision applies: resize the VM when the server itself needs a larger system footprint, or attach Raff Volumes when persistent data needs a separate lifecycle from compute. Raff Volumes are priced at $0.08/GiB-month according to the current Raff pricing source.

This guide explains when to add a block storage volume, when resizing the VM disk is enough, when object storage is better, and how to choose a cleaner production storage layout.

If you are new to the storage model, read Block Storage Volumes for Databases, Containers, and App Data first.

VM disk resizing and attached volumes solve different problems

A VM disk resize increases the size of the main disk attached to the server.

An attached volume adds a separate disk-like storage resource.

VM disk resize
  ↓
Larger system disk

Attached volume
  ↓
Separate persistent data disk

The VM disk usually contains:

• Operating system
• System packages
• Application runtime
• Configuration files
• Local logs
• Temporary files

An attached volume usually contains:

• Database files
• Container state
• Application data
• Processing workspace
• Large working directories
• Persistent service data

The important question is not only:

Do I need more storage?

The better question is:

Should this data share the same lifecycle as the operating system?

If the answer is no, a separate volume is usually the cleaner boundary.

VM Disk vs Block Storage Volume: the short answer

Use the VM disk for the operating system, runtime, and simple workloads that do not need a separate data lifecycle. Use an attached block storage volume for persistent application or database data that should grow, be monitored, or be protected separately from the system disk.

A separate volume does not automatically make data safer. It still needs the right filesystem, mount configuration, monitoring, snapshots or backups, and restore testing.

The storage decision framework separates capacity from lifecycle

Use this framework before changing the VM size.

A simple rule:

Resize the VM when the server is too small. Add a volume when the data needs its own boundary.

Resize the VM disk when the system disk is the problem

Resizing is appropriate when the operating system disk itself has become too small.

Common examples:

• OS updates need more space
• Application packages grew
• Docker images consume the root filesystem
• Logs filled the system disk
• Temporary files consumed available space
• The original VM disk size was too small

Before resizing, check whether cleanup solves the issue:

• remove unused images
• rotate old logs
• clean package caches
• remove abandoned build artifacts
• investigate unexpectedly large files

A larger disk should solve a real capacity requirement, not hide uncontrolled growth.

Add a volume when storage grows faster than compute

Volumes are useful when disk requirements increase while CPU and RAM remain sufficient.

Example:

Current VM
2 vCPU
4 GB RAM
80 GB disk

Problem
Database needs 200 GB more storage

CPU and RAM
Still sufficient

A larger VM would add compute capacity that the workload does not need. A volume solves the storage requirement directly.

Add a volume when:

• data should be separated from the OS;
• storage grows independently from compute;
• databases need dedicated storage;
• containers need persistent state;
• recovery boundaries should be clearer;
• data may move separately from the VM later.

At the current Raff rate of $0.08/GiB-month, a 100 GiB volume costs $8/month before other infrastructure costs.

Databases often benefit from separate storage

Databases are one of the clearest cases for using a separate volume.

A database contains durable state: tables, indexes, transaction logs, temporary files, and metadata. Keeping that data separate from the operating system makes capacity planning and recovery easier.

A common layout:

Raff VM
  ↓
System disk
OS + application runtime

Raff Volume
Database data directory

A volume helps when:

• database data grows quickly;
• the team needs storage monitoring separately;
• the database may move independently later;
• risky changes need storage recovery points.

A volume does not replace:

• database-aware backups;
• restore testing;
• access control;
• monitoring;
• recovery planning.

For teams that do not want to operate database storage directly, Raff Managed Databases may be a better responsibility model.

Containers need persistent storage outside rebuilds

Containers are replaceable. Important data should not depend on a container filesystem.

Use a volume when:

• containers store application state;
• Docker volumes are growing;
• self-hosted services need persistent files;
• rebuilds should not remove important data.

Example:

Container
  ↓
Persistent mounted volume
  ↓
Application data

For user uploads, media, reports, and exports, object storage is usually a better fit.

Object storage solves file storage problems

A common mistake is increasing VM storage because uploaded files are growing.

Object storage is usually better for:

• user uploads;
• images;
• videos;
• reports;
• exports;
• archives;
• shared files across servers.

Use block storage when software expects filesystem behavior. Use object storage when files should exist independently from a VM lifecycle.

Read Object Storage vs Block Storage vs VM Disk for the broader comparison.

Volumes create clearer recovery boundaries

Separating data from the system disk makes recovery planning easier.

System disk
  ↓
Recover OS and runtime

Volume
  ↓
Recover persistent application data

Object storage
  ↓
Recover durable file objects

A volume can help define:

• what data is protected;
• what gets snapshotted;
• what requires database backup;
• who owns recovery;
• what can be rebuilt.

Use Raff Data Protection when snapshots, backups, retention, and recovery workflows are required.

A production volume needs ownership

Every production volume should have:

• a clear purpose;
• a documented mount path;
• an owner;
• monitoring;
• backup coverage;
• recovery instructions;
• deletion rules.

A volume named extra-disk-1 without context becomes forgotten infrastructure.

When resizing is still the better choice

Do not add a volume automatically.

Resize the VM when:

• CPU and RAM are also insufficient;
• the system disk is the real problem;
• the workload is simple;
• fewer moving parts are more valuable;
• data separation does not provide meaningful benefit.

A small application may correctly stay on one disk until growth or recovery requirements justify a change.

Decision checklist

Before resizing or adding storage, ask:

• Is compute also under pressure?
• Is only storage growing?
• Is the data durable?
• Should it survive VM replacement?
• Does it need filesystem access?
• Would object storage fit better?
• Does it need separate backup and recovery rules?
• Is there a clear owner?

If data needs its own lifecycle, add a volume. If the server itself is undersized, resize the VM. If the data is file-based, consider object storage.

Conclusion

Resize the VM when the whole server needs more capacity. Add a volume when persistent data needs a separate storage boundary. Use object storage when files should exist independently from compute.

The right storage design separates runtime, persistent data, durable files, and recovery points. That makes production systems easier to operate and easier to recover.