Week 3: Storage, M.2, SATA, NVMe, SAS, and RAID

A drive can be installed and still be invisible.

A drive can be visible and still be failing.

A RAID array can stay online while already being in trouble.

Storage problems get confusing when every symptom is reduced to "the drive is bad."

This week we build a better model.

The system question

The question for Week 3 is:

Where does storage stop behaving normally, and what evidence tells us whether the problem is media, interface, controller, operating system, array state, or data integrity?

A storage device sits inside a longer path:

physical device
      ↓
interface + power
      ↓
firmware/controller detection
      ↓
health or array state
      ↓
operating-system detection
      ↓
partition + filesystem + mount
      ↓
application access
      ↓
trusted data

A failure at each layer looks different.

If firmware cannot see the device, formatting is not your first problem. If firmware sees the drive but the operating system does not expose a usable volume, the hardware path may already be working well enough to move higher. If a RAID controller reports a degraded array, "the files still open" does not mean the array is healthy.

Storage troubleshooting is about finding the first boundary that stopped behaving normally while protecting the data that may still be recoverable.

How the chapter moves

Lesson 1 compares hard drives, SSDs, removable flash media, memory cards, and optical storage by workload instead of by one marketing number.

Lesson 2 separates the names people constantly mix together: SATA, PCIe, NVMe, SAS, M.2, and mSATA. Some describe form factor, some describe transport, and some describe protocol. Mixing those layers is how compatible-looking parts become unusable systems.

Lesson 3 moves from one drive to arrays. You will trace RAID 0, 1, 5, 6, and 10, then separate fault tolerance from backup and recovery.

Lesson 4 turns the chapter into a storage-selection problem. You will choose technology for a workload, prove platform compatibility, decide whether RAID is justified, and design the recovery path too.

Lesson 5 starts with failure evidence: missing drives, SMART warnings, clicking or grinding HDDs, slow I/O, boot-device errors, degraded or missing arrays, and controller alarms.

What you should be able to defend

By the end of the week, you should be able to explain:

• why HDD spindle speed and 2.5-inch versus 3.5-inch form factor affect design choices;
• why an SSD can use SATA, PCIe/NVMe, or other controller paths;
• why M.2 and mSATA are not interchangeable names for NVMe;
• where SAS belongs and why controller support matters;
• when removable flash, memory cards, or optical media still make sense;
• how RAID 0, 1, 5, 6, and 10 distribute data and tolerate different failures;
• why RAID is not backup;
• how workload, latency, IOPS, throughput, capacity, durability, cost, and recovery requirements change a storage recommendation; and
• how to locate the earliest broken storage boundary without destroying the evidence.

The rule that matters most

Protect the data before performing destructive changes.

Do not initialize, format, rebuild, wipe, secure-erase, or replace storage because a dialog box suggests it.

First decide what data matters, what recovery state exists, and what the current evidence actually says.

A storage repair that destroys the only good copy is not a repair.