Over the years, I’ve learned that high performance doesn’t just happen – neither in life nor in databases. When I transformed myself from an 85 kg couch potato into a 65 kg triathlete, I realized the same principle applies everywhere: performance is the result of conscious choices, discipline, and understanding what really goes on under the surface.
The same is true for databases and the infrastructure they run on. Recently, I took a closer look at the hard drives powering my NAS – one of the backbone of my home lab and my backup system for SQL Server and PostgreSQL. What I found reinforced one of my long-standing beliefs: if you care about predictability and reliability, choose technology that behaves consistently under pressure.
From Databases to Disks: Why I Chose CMR
When I built my old NAS back in the year 2015, I didn’t have any bad experiences with SMR drives personally. But I understood the risk profile – especially for workloads that involve frequent random writes, RAID rebuilds, or database snapshots. That’s why I opted for CMR-based drives, specifically the WD Red Pro series, which uses Conventional Magnetic Recording. They’re designed for NAS environments that run 24/7, where performance stability matters more than raw capacity.
The Hidden Difference Beneath the Surface
Every hard drive stores data by magnetizing microscopic regions on spinning platters, organized in circular tracks. The way these tracks are written determines how the drive behaves when data changes. In CMR (Conventional Magnetic Recording), each track is written side by side, with a tiny gap between them. This allows the drive to overwrite a sector directly without disturbing adjacent ones – simple, predictable, and reliable. The following picture illustrates this concept:
This independence is what makes CMR drives perfect for database workloads. Whether your SQL Server instance writes log records, checkpoints, or temporary objects – each write operation happens cleanly, without hidden firmware overhead or unexpected latency spikes.
When Density Becomes Fragility: The SMR Story
SMR (Shingled Magnetic Recording) takes a different approach. To increase data density, tracks overlap like roof shingles. This allows manufacturers to fit more data onto the same physical platter – but at the cost of complexity. Let’s have a look at the following picture:
In an SMR drive, rewriting even a small portion of data can force the drive to reorganize an entire “zone” of overlapping tracks. The drive’s firmware tries to hide this through caching and background reorganization – but when the workload stays busy (like a NAS running SQL backups or virtual machines), that reorganization often can’t keep up.
The Latest Warning: Data Recovery Experts Raise the Alarm
My decision to avoid SMR has recently been validated by worrying industry news. According to heise online, data recovery specialists are now warning of serious defects in older SMR-based WD drives. These issues involve internal translation tables that can corrupt themselves over time, leading to firmware failure and data loss – even during normal operation.
Drives from the WD Blue, WD Red, and WD Purple lines, especially in the 2 – 6 TB range, appear particularly affected. Experts now recommend immediate backups of these models, since the defect can render drives inaccessible without warning. That’s not the kind of risk I want anywhere near my backup chain or my databases.
Why CMR Still Feels Like the Smart Choice
For me, CMR drives represent something deeper than a technical preference – they represent predictability. I know that during a RAID rebuild, each track behaves independently. I know that database snapshots complete consistently. And I know that my backups don’t depend on fragile firmware translation tables.
In a world where capacity and price often drive buying decisions, reliability still wins in the long run – just like in endurance sports. You don’t need the “flashiest” gear – you need the gear that performs steadily when it matters most.
How I Catch Such Hidden Risks During a SQL Server Health Check
In my SQL Server Health Check, I often uncover problems that go far beyond bad query plans or missing indexes. Many performance bottlenecks come from underlying infrastructure misconfigurations – from wrong file placements to slow or inconsistent storage technologies like SMR-based NAS drives.
During a SQL Server Health Check, I perform a holistic health check across your SQL Server environment – and also across your storage subsystem:
- Storage latency and throughput
- TempDB and transaction log performance
- I/O subsystem reliability and write patterns
It’s in these deep inspections where such subtle but critical differences show up – before they become data-loss or performance incidents.
If you’d like me to take a look at your environment and help you achieve High Performance in Databases & in Life, you can learn more about my SQL Server Health Check here:
👉 Request the SQL Server Health Check
Thanks for your time,
-Klaus
