Disk types on serverplus: hdd, ssd, nvme
serverplus offers several disk types — they differ in speed (how many operations and megabytes per second they deliver) and, therefore, in purpose. The right choice directly affects site responsiveness, database speed and cost. Below are the specs and a simple rule for which disk to pick for which task.
In brief: IOPS and MB/s
- IOPS (input/output operations per second) — how many small operations the disk performs per second. This is the key metric for databases and apps with many small reads/writes.
- Throughput (MB/s) — how much data passes per second during large sequential operations. Matters for large files, media, backups and logs.
- Read vs write. Read IOPS is usually higher than write — account for your own workload profile (for example, for a database with heavy writes it is write that is critical).
serverplus disk types
| Disk type | IOPS read | IOPS write | MB/s | Typical use |
|---|---|---|---|---|
| hdd-basic | 320 | 120 | 100 | Archives, backups, cold data |
| ssd-basic | 640 | 320 | 150 | Small sites, dev/test |
| ssd-universal | 7000 | 4000 | 200 | Production: sites with traffic, databases |
| nvme-fast | 25000 | 15000 | 500 | Loaded databases and apps |
The numbers are a guideline. Real performance depends on the workload profile: block size, queue depth, read/write ratio. The values in the table are convenient for comparing types against each other.
Which disk to choose
hdd-basic — the most budget option. For cold data where speed is not critical: archives, backups, rarely used files. Do not put an active database on it — it will be slow.
ssd-basic — a universal low-cost option. Small sites and apps, test and dev servers, small projects with moderate load.
ssd-universal — the workhorse for production. Sites with real traffic, medium-sized databases, most web apps — a good balance of speed and price.
nvme-fast — maximum performance and minimum latency. Loaded databases with many transactions, high-load apps, caches, analytics — wherever high IOPS matters.
How to tell what you need
- Many small operations / a database → look at IOPS:
ssd-universal, for serious load —nvme-fast. - Large sequential operations (media delivery, backups, video) → MB/s matters more.
- Cold data and saving money →
hdd-basic. - Not sure →
ssd-universalcovers most tasks; upgrade tonvme-fastif you hit the disk as a bottleneck.
How to benchmark a disk on your own server
You can check real performance right on the VPS. Sequential write (MB/s) with the dd command:
dd if=/dev/zero of=~/testfile bs=1M count=1024 oflag=direct rm ~/testfile
Random operations (IOPS) are measured more accurately by fio:
sudo apt-get install -y fio fio --name=randrw --ioengine=libaio --rw=randrw --bs=4k \ --size=1G --numjobs=1 --iodepth=32 \ --runtime=30 --time_based --group_reporting
How to change a disk type
You cannot change the type of an existing disk directly in the panel. The working path is to create a new disk of the desired type and move the data to it. Exactly how depends on what kind of disk it is.
An additional data disk (volume)
The simplest case is when the data sits on a separate attached disk rather than on the system one.
- Create a new disk of the desired type in the panel (for example
nvme-fast) and attach it to the server. - Partition and mount it:
lsblk # find the new disk name, e.g. /dev/vdb sudo mkfs.ext4 /dev/vdb sudo mkdir -p /mnt/new && sudo mount /dev/vdb /mnt/new
- Stop the service writing to the old disk (for a database, prefer a dump — see the note) and copy the data preserving permissions:
sudo rsync -aAX /data/ /mnt/new/
- Switch the app to the new disk: add the mount to
/etc/fstaband remount it to the required path. - Make sure everything works, and only then detach and delete the old disk in the panel.
Databases — via a dump. Do not copy database files "live". Make a logical dump (
pg_dump,mysqldump) on the old disk and restore it on the new one — this avoids an inconsistent state.
The system (boot) disk
You cannot change the system disk type "on the fly" — the OS runs on it. The practical path is to recreate the server on a disk of the desired type:
- Take a snapshot of the current server and create a new one from it, choosing the desired disk type at creation (see the article on snapshots and backups), then move the IP/DNS.
- Or bring up a clean server on the desired disk type and transfer the data and settings — as with a regular migration (see "Migration to serverplus").
Via the API or support. Sometimes a volume type change can be done with the retype operation on the OpenStack side — it is not in the panel. Whether it is available in your case, check with serverplus support.
FAQ
Can I change the disk type later?
Not directly in the panel. The type is changed by moving data to a new disk of the desired type; the detailed procedure is in the "How to change a disk type" section above.
What does the disk affect more — the site or the database?
Most often the bottleneck is the database: high IOPS matters to it. If the site "slows down under load", look first at the disk under the database.
HDD or SSD for backups?
For backups, volume and price matter more than latency, so hdd-basic is usually enough. Even better — keep backups in S3 object storage, separate from the server.
What is the difference between read and write in the table?
Disks read faster than they write. If your workload is mostly writes (an active database, log ingestion), focus on the "IOPS write" column.