3.2 Block and file storage
Describes the cloud storage and database landscape as of August 2026
What this is and why it exists
Object storage is reached over the network by name. Block and file storage are the other two shapes: a disk you attach to one machine, and a filesystem several machines can mount at once. Choosing the wrong one is not a performance mistake, it is a data-loss mistake — because one of the options quietly disappears when the machine does.
The vocabulary
- Block storage — a raw volume the operating system formats and treats as a disk. Amazon calls it EBS, Azure calls it Managed Disks, Google calls it Persistent Disk.
- File storage — a shared filesystem several machines mount at once: Amazon's EFS, Azure Files, Google's Filestore.
- IOPS — input/output operations per second; how many separate reads or writes the volume will do.
- Throughput — megabytes per second; how much data moves, regardless of how it is divided.
- Ephemeral (or instance) storage — a disk physically attached to the host, which is erased when the instance stops.
- Persistent volume — a volume that lives independently of the machine and survives it.
- Snapshot — a point-in-time copy of a volume, usually stored in object storage.
- Restore — building a usable volume back from a snapshot.
The mental model
Three shapes, three questions. Block storage is one disk for one machine, and it is what a database wants, because a database wants to control its own layout and needs low, predictable latency. File storage is one filesystem for many machines, and it is what you need when several servers must see the same files — a shared uploads directory, a content store — at the price of network latency on every operation. Object storage is neither: no filesystem semantics, no partial writes, reached by name over HTTP, and cheaper per gigabyte than both.
IOPS and throughput are two different taps and workloads pull on different ones. A database doing many small random reads is limited by IOPS; a backup job streaming one huge file is limited by throughput. Volume types are sold along those axes, and the trap is that many providers scale a volume's performance with its size, so a small volume can be slow for reasons that have nothing to do with the disk being full. If a workload is unexpectedly slow, ask which of the two taps is closed before buying a bigger machine.
Then the one that costs people data. Ephemeral storage is physically attached to the host and is very fast, and its contents do not survive the instance stopping — not a crash, not a planned stop, not the host being replaced under you. It is exactly right for scratch space, caches, and temporary files during processing. It is exactly wrong for anything you would miss, and the reason people get caught is that it behaves identically to a persistent disk right up until the moment it does not. Know which kind each of your volumes is, and be able to say it without looking.
Snapshots are the safety net, and the honest thing to say about them is that a snapshot is not a backup until it has been restored. A restore is a real operation with a real duration: the volume is created from object storage, and on several platforms it becomes available immediately but reads slowly at first while blocks are fetched on demand, so the first hour after a restore can be much slower than normal. That matters because recovery time is a number you promise, and the promise should be based on a restore you have actually timed. Snapshot regularly, keep them somewhere the loss of one region cannot reach, and restore one on a schedule — the point of the exercise is to discover the problems while nothing is on fire.
What you should now be able to explain or do
Choose between block, file and object storage for four different workloads and defend each. Say which of IOPS or throughput limits a given workload, and why a small volume can be slow. State plainly what happens to ephemeral storage when an instance stops, and name two things it is right for. Explain why a snapshot is not a backup until it has been restored, and what you learn from timing one.
Check yourself
A database and a group of web servers sharing an uploads directory. Which storage kind does each want?
The database wants block storage — one disk, one machine, low predictable latency. The shared uploads directory wants file storage, because several machines must see the same files at once.
Your volume is slow but not full. What are the two things to check?
Whether the workload is limited by IOPS or by throughput, and whether the volume's size is capping its performance — many providers scale a volume's speed with its capacity.
What exactly is lost when an instance with ephemeral storage stops?
Everything on that disk. It is attached to the host, not to the instance's identity, and a stop, a crash or a host replacement all erase it. Use it for scratch space and caches, never for anything you would miss.
Why is "we take snapshots nightly" not the same as "we have backups"?
Because nothing has been proven until a snapshot has been restored. Restores take real time, are often slow for the first period while blocks are fetched on demand, and are where you discover the problems — so time one before you promise a recovery figure.
Where should snapshots be kept, and why?
Somewhere the failure you are protecting against cannot reach — another region at least. A copy that shares a fate with the original is not a copy.
Go deeper
We haven't checked most of these for screen reader use yet.