Benchmark the Disks Before You Migrate

On 25 May 2026 I ran a few quick benchmarks on the bare-metal servers I'd just moved an application onto. Sequential disk was 8 to 13 times slower than on the server they were replacing. SHA-256 hashing was about 4 times slower.

App traffic was already on the new hosts. I should have run those checks before moving anything.

How it happened

The project was moving a small startup's platform from hand-run scripts to Terraform on bare metal. Part of the plan was new servers: a separate box for git and CI, and fresh hosts for the cluster. The new hosts were an older generation, server CPUs with SATA SSDs. The box they were replacing was a newer machine with NVMe storage.

On paper the new hosts were fine. Enough cores, enough RAM, enough disk space. Nothing about the spec sheet said "this will be much slower". And the app ran on them. Pods started, pages loaded, health checks passed.

Benchmarks weren't in the plan before the move. I ran them after, as a sanity check, with the same few commands on old and new.

The ten-minute benchmark

Nothing fancy. Run these on the old server and the new one, same conditions, and compare.

Sequential write, bypassing the page cache:

dd if=/dev/zero of=/var/tmp/ddtest bs=1M count=2048 oflag=direct status=progress
rm /var/tmp/ddtest

Sequential read of the same kind of file:

dd if=/dev/zero of=/var/tmp/ddtest bs=1M count=2048 oflag=direct
echo 3 | sudo tee /proc/sys/vm/drop_caches
dd if=/var/tmp/ddtest of=/dev/null bs=1M iflag=direct status=progress
rm /var/tmp/ddtest

CPU work that databases, TLS and disk encryption all care about:

openssl speed -evp sha256
openssl speed -evp aes-256-xts

If you have more time, fio with a random read and write mix closer to your database's pattern is better. But even the crude version told me what I needed. The new disks were 8 to 13 times slower on sequential work, and the CPUs about 4 times slower on hashing.

Why it mattered more than it looked

The platform ran Postgres, Vault, object storage and k3s on the same hosts. All of those lean on the disk. On top of that, the plan was to encrypt production data at rest, and disk encryption adds CPU work on every read and write. Slower CPU plus slower disk plus encryption is three costs stacked on the same path.

The app was quiet enough that none of this was failing yet. It would have shown up later, under load, as "the database feels slow sometimes", which is the hardest kind of problem to trace back to a hardware choice made months earlier.

What I changed

Production went back onto the original NVMe server, this time with full-disk encryption.

Encrypting the fast server meant reformatting it, which is not something I wanted to try for the first time on production. So I rented a throwaway bare-metal box with the same layout and rehearsed it there: RAID1, LUKS2, LVM and XFS for the data volume, with a small SSH server in the initramfs so the disk can be opened remotely at boot. The rehearsal took about 2.5 hours and cost about 0.28 EUR.

It found three things I'd rather learn on a box I was about to delete:

• A trailing newline in the passphrase pipe made decryption fail. The key you pipe in has to match byte for byte.
• The initramfs needed network config to come up on the network at all before the root disk was decrypted. Without DHCP there, there's nothing to SSH into.
• The server takes about 3.5 minutes to get through its firmware checks before it even starts booting. Add the manual passphrase step and a reboot is no longer a quick fix. That changed the outage playbook: rebooting became a last resort, not a first step.

After that, the real cutover onto the encrypted NVMe server was mostly routine.

What I'd do differently

Benchmark before choosing hardware, not after moving onto it. It's ten minutes. The order should be:

1. Run the same disk and CPU checks on the current server.
2. Run them on the candidate server before you commit to it.
3. Compare the numbers against what your heaviest component needs: usually the database.
4. Only then plan the move.

I also wouldn't trust a server's spec sheet for storage. "SSD" covers a huge range. A SATA SSD and an NVMe drive are both SSDs, and the difference I measured was up to 13 times.

The trade-off I accepted

Encrypted disks are a choice with a cost. A reboot now needs a person to enter the disk passphrase, and it takes minutes longer than before. For this team, protecting customer data at rest was worth that. I wrote down the reboot steps so it doesn't depend on me remembering them.

Takeaway

Before any hardware move, benchmark old and new with the same commands, and rehearse anything destructive on a box you can throw away. Both are cheap compared with finding out in production.

If you're planning a move between servers or providers and want a second pair of eyes on it, get in touch.