A cloud server arrives with a disk. It is fast, it is local, and for most workloads it is all you need. So the reason to attach block storage is rarely that you have run out of room — it is that the disk and the server share a fate, and sometimes you need them not to.
What block storage actually is
Block storage presents raw storage to the operating system as if it were a physical disk. The server sees a device, you format it with a filesystem, mount it, and write to it like any other drive. Nothing about the application needs to know it is remote.
That is what separates it from object storage, which is accessed over an API and cannot be mounted, and from file storage, which serves a shared filesystem over a network protocol. A volume is block storage you attach to one server at a time.
The word *block* refers to how the data is addressed: in fixed-size chunks, with no notion of files. The filesystem you put on top supplies that notion.
The reason that matters: independent lifetime
A server's boot disk exists because the server exists. Delete the server and the disk goes with it. Resize the server and the disk is rebuilt. Rebuild the operating system and the disk is wiped.
A volume outlives all three. You can destroy the server, create a new one, attach the same volume, and the data is exactly where you left it. That single property is why volumes exist, and almost every good reason to use one comes back to it.
It changes how you treat servers. A machine whose data lives on its own disk is something you repair; a machine whose data lives on a volume is something you replace.
When a volume is the right answer
- A database you cannot afford to rebuild. The server becomes disposable and the data does not move.
- User uploads. Anything a customer put there should not be tied to the machine that happened to receive it.
- Data that outgrows the disk. A volume can be enlarged without touching the server; a boot disk usually cannot shrink back afterwards.
- Moving a workload to a bigger machine. Detach, attach elsewhere, start. No copying, no downtime spent transferring.
When it is the wrong answer
- The operating system and application code. They belong on the boot disk and are reinstalled, not preserved.
- Caches and scratch space. Losing them costs nothing, and local disk is faster.
- Anything latency-critical at small sizes. A volume travels over the network. The difference is small, but it is not zero, and a busy database with a tiny working set may prefer local NVMe.
- As a backup. This is the common and expensive mistake — see below.
A volume is not a backup
A volume is one copy of your data in one place. If a file is deleted, corrupted or encrypted by ransomware, the volume faithfully stores the deleted, corrupted or encrypted version. It protects against losing the *server*, not against losing the *data*.
Snapshots of a volume are closer, but they usually live on the same infrastructure, which is exactly what a real disaster takes out. Use a volume for continuity, and keep separate backups for recovery — the distinction is the whole subject of another article on this site.
What it costs
Volumes are billed per gigabyte per month for as long as they exist, whether or not the server they are attached to is running — which is the point, since the data survives the server. There is no charge for attaching or detaching, and no minimum size beyond the smallest volume offered.
The current rate is €0.0715 per gigabyte per month, excluding VAT. Multiply it by the size you are considering: for most volumes the result is small next to the server it attaches to, which is why the decision is really about lifetime rather than budget.
That is the live figure, not one typed into this article, and it is the same number the create dialog quotes you before you confirm. Server prices, which are the larger part of any bill, are listed in full on the pricing page.
The practical rule
Put on a volume anything you would be upset to lose if the server disappeared this afternoon, and leave everything else on the boot disk. That single question resolves almost every case without needing to think about storage architecture at all.