Lesson 5: Diagnose the Missing or Failing Drive

Core path: 42 minutes

A drive that does not appear in the operating system is not automatically dead.

A drive that still appears is not automatically healthy.

You need to find the boundary where detection, performance, or integrity starts failing.

Start with the symptom family

A+ storage troubleshooting includes several different evidence patterns:

• LED/status indicators;
• grinding or clicking noises;
• bootable device or OS not found;
• data loss/corruption;
• RAID failure;
• SMART warning/failure;
• extended read/write times;
• low IOPS or degraded performance;
• missing drive in the OS;
• missing array;
• audible array/controller alarms.

Do not collapse all of those into "bad drive."

Scenario A: new drive missing from the OS

The computer powers on normally, but the new drive does not appear in File Explorer.

Check 1: firmware detection

Can BIOS/UEFI see the device?

If no, investigate hardware/platform issues first:

• seating;
• data connection;
• power connection;
• supported slot or protocol;
• disabled/shared port;
• failed device or port.

If yes, the hardware path is at least partly working. Move upward.

Check 2: operating-system disk management

A new drive may exist but have no partition, filesystem, mount point, or drive letter.

That is different from firmware not detecting the hardware at all.

Scenario B: SMART warning

A SMART warning is evidence that the drive/controller has recorded health indicators outside expected limits.

Do not wait for total failure to prove the warning mattered.

Priority becomes:

1. protect important data;
2. verify backup/recovery state;
3. collect health/status evidence;
4. follow replacement procedure;
5. verify restored/replaced storage.

Scenario C: clicking or grinding HDD

Mechanical noises from an HDD can indicate serious drive trouble. Do not repeatedly stress the disk just to hear the noise again.

Preserve data and escalate/recover according to procedure.

An SSD has no spinning platters, so HDD-style grinding/clicking reasoning does not transfer to it.

Scenario D: slow storage

Extended read/write times or low IOPS can come from:

• failing media;
• controller/interface limits;
• thermal throttling on some SSDs;
• array degradation/rebuild;
• workload saturation;
• filesystem/OS conditions.

Measure before replacing.

Scenario E: RAID warning

If an array reports a failed member, missing array, or audible alert, inspect controller/array state before swapping disks.

A degraded array and a completely missing array are different incidents.

The troubleshooting chain

Use this model:

physical device
→ interface/power
→ firmware/controller detects device
→ SMART/health or array state
→ OS detects device/array
→ partition/filesystem/mount
→ workload performance/integrity
→ user can access trusted data

Your job is to identify the first failed or suspicious boundary.

Service-ticket challenge

Complete this record for two different symptom families:

Symptom:

Visible in firmware/controller?

Visible in OS disk management?

SMART/LED/noise/alarm evidence:

Interface/protocol:

First theory:

Test:

Result:

Data-protection action:

Next action:

Final diagnosis:

Verification:

Week 3 completion criteria

You should now be able to:

• compare HDD, SSD, removable, and optical storage;
• identify HDD spindle/form-factor tradeoffs;
• separate M.2/mSATA form factors from SATA/NVMe/PCIe/SAS communication paths;
• explain RAID 0/1/5/6/10 at a functional level;
• explain why RAID is not backup;
• recognize SMART, audible, LED, noise, corruption, performance, missing-drive, and missing-array evidence;
• troubleshoot storage by locating the first failed or degraded boundary.

The technician goal is not "replace the drive." It is protect the data and prove where storage stopped behaving correctly.