Storage user guide
What this is
Section titled “What this is”A volume is a block device you attach to one machine. It exists independently of any instance, it survives termination, and it grows but never shrinks.
There is no object storage, no file share, no managed database. Block storage is the only storage service, and this guide is how to use it well on the hardware it actually runs on.
Then: developer guide for the API mechanics, API reference for every operation.
Two kinds of disk, and only one survives
Section titled “Two kinds of disk, and only one survives”| Root disk | Attached volume | |
|---|---|---|
| Where it comes from | The instance shape, 20–160 GB | You create it, 1–1000 GB |
| Survives terminate | No — deleted with the instance | Yes |
| Resizable | No | Yes, upward only |
| How many per machine | One | Several |
| Cost | Included in the instance price | Not billed today |
Anything you want to keep goes on an attached volume. The root disk is scratch space with an operating system on it.
What the disk actually is
Section titled “What the disk actually is”One type, because the box has one kind of disk: 7200 rpm SATA. No SSD, no NVMe.
| Our name | hdd |
| Name on the wire | standard |
| Size | 1–1000 GB |
| IOPS | 48 |
| Throughput | 11 MB/s |
Those figures are measured and then divided: fio on the whole pool gave
580 random-read IOPS and 132 MB/s, divided by the twelve machines the box can
hold at once. So the number quoted to you is one every customer can have
simultaneously, not a best case that evaporates when a neighbour wakes up.
There is deliberately no gp3 or io2 alias. Those names promise SSD latency
this hardware cannot deliver, and a module that asks for gp3 gets an error
rather than a slow disk that looks like a fast one.
Sizing for spinning disks
Section titled “Sizing for spinning disks”48 IOPS is a small number and it is seek-bound, not bandwidth-bound.
| Workload | Verdict |
|---|---|
| Logs, backups, media, build artefacts, anything sequential | Good. 11 MB/s sustained per volume |
| A web app’s static files and code | Fine |
| Postgres, MySQL, anything doing small random writes | Bad. This is the worst fit for this storage |
| Search indexes, heavy analytics | Bad |
The way to win here is to buy memory instead of IOPS: the cd-memory-*
shapes exist because on this hardware RAM is the cheaper way to make a working
set fast. Put the hot data in page cache and the disk stops mattering.
If your workload genuinely needs SSD latency, this is the wrong platform, and we would rather you read that here than discover it during an incident.
What you must do yourself
Section titled “What you must do yourself”- Format and mount. Attaching does not partition, format or mount anything.
- Grow the filesystem. Growing the volume does not grow what is on it.
- Unmount before detaching. Detaching a mounted, written filesystem is pulling the disk out.
- Take your own snapshots — and delete them. Nothing is scheduled, and nothing expires them. They occupy the same pool as your volumes, so a forgotten nightly snapshot eventually fills it.
- Copy anything irreplaceable off the platform. There are no provider backups, and snapshots live in the same pool as the volume they protect.
Durability, plainly
Section titled “Durability, plainly”One box. One pool. The pool is not mirrored across disks today. There is no cross-host replication and no cross-region copy.
A volume is durable against a process crash, a bad deploy or an rm -rf you
took a snapshot before. It is not durable against the disk failing. Plan
accordingly, and do not let this platform hold the only copy of anything.
Identify disks by UUID, never by device name
Section titled “Identify disks by UUID, never by device name”The device name you ask for on attach is a request, not a guarantee — you may
ask for /dev/sdf and the guest kernel may call it /dev/vdb. A reboot can
renumber devices, and an /etc/fstab written against a path will then mount the
wrong disk.
blkid /dev/vdbecho 'UUID=<uuid> /data ext4 defaults,nofail 0 2' >> /etc/fstabnofail is not optional. Without it, a machine whose volume is missing at boot
drops into emergency mode wanting a root password that a cloud image does not
have — and recovering means detaching the root disk and mounting it elsewhere.
Capacity you share
Section titled “Capacity you share”Every volume and every instance root disk comes out of one 1400 GB pool, of which 1200 GB is reserved for root disks. Volumes are thin-provisioned but the sum sold is capped, so the pool cannot fill silently behind customers who are each within their quota.
A create that would take the pool past the cap fails with
InsufficientVolumeCapacity — capacity, not policy. A quota increase will not
fix it.
Snapshots come out of the same pool. See Snapshot actions.
Two things that are not yet true
Section titled “Two things that are not yet true”[!warning]
The IOPS figure is not enforced. The platform’s rule is that every capability figure is enforced rather than advertised; for volumes that limit does not exist yet, so one busy volume can take the pool’s throughput. This is a known defect.
Storage is not quota’d and not billed. Onboarding sets CPU and memory quotas only, and no volume is rated. Neither is a gift — both will change, and a cost model built on free storage will break.
Go further
Section titled “Go further”- Developer guide — the API mechanics
- API reference — every operation
- Volume types — the measurement in full
- Snapshot actions
- Compute user guide