Almost every hosting page advertises “NVMe SSD” and stops there. It’s a useful number, but it only answers one question: how quickly can a single piece of media read and write? It says nothing about what happens when that media fails — and media always fails eventually. To understand whether your data is actually safe, you need to look at two things separately: the kind of disk, and the system the disk lives inside.
Short version: the disk type sets your speed ceiling, and the storage architecture sets your durability floor. Cybeward uses NVMe for speed and Ceph with triple replication for durability. You get both.
The storage media ladder
Storage media has climbed a ladder over the last fifteen years, and each rung changes the rules.
A spinning hard drive (HDD) stores data on magnetic platters and reads it with a physical arm. To reach a piece of data, the arm has to move and the platter has to rotate underneath it. That mechanical step costs milliseconds — an eternity for a CPU. HDDs are cheap per terabyte and fine for cold archives, but a busy database on an HDD spends most of its life waiting.
A SATA SSD has no moving parts. Data lives in flash chips, so there’s no arm to swing and no platter to wait for. Latency drops from milliseconds to tens of microseconds. The catch is the connection: SATA was designed for hard drives, so even a fast flash chip is forced to talk through a narrow, decades-old pipe.
NVMe removes that bottleneck. Instead of the SATA pipe, the flash talks to the CPU directly over PCIe — the same high-bandwidth lanes a graphics card uses. The difference is not subtle: where a SATA SSD might handle tens of thousands of operations per second, NVMe handles hundreds of thousands, with much lower latency under load. For anything that does a lot of small, random reads and writes — databases, container builds, busy web apps — this is the rung that matters.
So NVMe wins on speed. But speed is only half the story.
One disk is one point of failure
Picture the simplest possible setup: your server has one fast NVMe drive, and all your data lives on it. It’s quick. It’s also a single point of failure. When that drive dies — and drives do die — your data dies with it. No amount of raw speed changes that.
A fast disk that fails is still a disk that fails. Durability is a property of the system, not the media.
The traditional answer is RAID: put several disks in one machine and mirror data across them. That helps with a dead disk, but it doesn’t help when the whole machine goes down — a failed power supply, a bad motherboard, a kernel panic. Your data is intact on those disks, and you still can’t reach it. To survive that, the data can’t live in one box at all.
What Ceph is, in plain terms
Ceph is the system we use to spread storage across many machines instead of trapping it in one. Think of it less like a disk and more like a fleet.
Instead of writing your data to “drive number three,” Ceph treats a whole cluster of servers — each full of NVMe drives — as one large, shared pool. When your VDS writes a file, Ceph chops it into chunks and decides, automatically, which machines should hold each chunk. There’s no single disk and no single server that owns your data. The cluster owns it collectively, and it constantly keeps track of where every copy is.
The practical upshot: your storage is no longer tied to the physical server your VM happens to run on. That decoupling is what makes everything below possible.
Triple replication: three copies, three machines
Here’s the part that protects you. Every chunk Ceph writes is stored as three copies, on three separate machines (called nodes). A write isn’t acknowledged as “done” until enough of those copies are safely on disk.
The concrete value of that number three:
- A disk fails. Two other copies still exist. Ceph notices within seconds and immediately starts rebuilding a third copy onto a healthy drive elsewhere. You see nothing.
- A whole node fails. Same story — the other two copies live on different machines, so your data stays readable and writable while the cluster heals itself.
- Maintenance happens. We can take a node offline to replace hardware without your VM ever losing access to its disk.
Replication is not backup. Three copies protect against hardware failure, not against you deleting the wrong file or a bad migration. That's what snapshots and backups are for — they're a separate, deliberate layer, and you should still use them.
The trade-off, stated honestly
This isn’t free. A write to a single local NVMe drive finishes the moment one disk confirms it. A write to Ceph has to travel across the network and land on three machines before it counts as done. That adds latency — typically a fraction of a millisecond on our network, but it’s real, and we’d rather you hear it from us than discover it on a benchmark.
What you trade that small latency for is large: no single disk and no single server can take your data offline. For the overwhelming majority of real workloads — web apps, databases, APIs — the difference is invisible in day-to-day use, while the durability difference is the gap between “we restored from last night’s backup” and “you never noticed.”
How this ties to the SLA
Our 99.999% availability SLA isn’t a slogan bolted onto ordinary hardware — it’s a direct consequence of this design. Five-nines means roughly five minutes of downtime per year, and you simply cannot promise that if a single failed drive or a single rebooted server can interrupt a customer. Decoupled storage is the foundation: because your disk lives in the cluster rather than under your VM, we can lose hardware, replace it, and patch it without taking you with it.
It also makes snapshots clean and quick. Because Ceph already understands your data as managed chunks with known locations, capturing a consistent point-in-time copy is a metadata operation, not a slow full read of a physical disk. That’s why a snapshot before a risky change takes seconds — and why rolling back is just as fast.
When we say we don’t oversell, this is part of what we mean. The NVMe gives you the speed on the label. The Ceph cluster underneath is the part that keeps your data there tomorrow.
