Lesson 4: Storage Selection Lab

The fastest drive is not automatically the right drive.

Neither is the biggest one.

Storage design is a tradeoff between workload, interface, capacity, durability, cost, recoverability, and the platform you are installing it into.

This lab is about making that decision from requirements instead of preference.

Start with the workload, not the product

Pick one supplied scenario.

Student laptop

Needs:

• fast startup;
• quiet operation;
• low power use;
• enough capacity for school applications and projects;
• reasonable cost.

Media workstation

Needs:

• fast active-project storage;
• large source-footage capacity;
• reliable export workflow;
• separate recovery copies.

Esports station

Needs:

• fast game loading;
• enough local capacity for several large titles;
• predictable performance;
• a practical budget.

Small file server

Needs:

• shared capacity;
• replaceable drives;
• fault-tolerance planning;
• separate backup and recovery.

The hardware comes second.

First identify which requirements are actually important.

Separate must-have from nice-to-have

Suppose an esports station requirement says:

must boot quickly
must hold 1.5 TB of installed games
budget: moderate
noise: low priority
fault tolerance: not required

A 4 TB enterprise SAS array might be technically impressive and completely inappropriate.

It solves requirements the system does not have and adds controller, cost, power, and complexity.

Do not confuse sophistication with fit.

Compare candidates by the same criteria

Evaluate at least three candidate storage classes using a table like this:

The point is not to produce a table full of adjectives.

Tie each judgment to the scenario.

For example:

The NVMe SSD is a stronger fit for the active media-project drive because the workload needs high throughput and low latency. It is a weaker fit for the entire archive if cost per terabyte is the dominant requirement.

That is a technical recommendation.

Compatibility can reject a good drive

Now verify the system can actually use the candidate.

Check:

• physical space;
• supported slot or connector;
• SATA versus PCIe/NVMe support;
• available power connection;
• M.2 length and keying when relevant;
• SAS or other controller requirements;
• lane or port sharing documented by the motherboard.

A drive can be perfect for the workload and still be wrong for the machine.

That does not make the recommendation bad.

It means the system has another constraint.

Add redundancy only when a requirement justifies it

If the scenario uses multiple drives, decide whether RAID solves a real problem.

If yes, explain:

• RAID level;
• minimum drive count;
• usable-capacity cost;
• tolerated member failure;
• degraded-state behavior;
• separate backup requirement.

If no, say why.

This is a valid answer:

RAID adds complexity here without addressing a stated availability requirement. A single SSD plus independent backup is the cleaner design.

You do not get extra credit for unnecessary architecture.

Design the recovery path too

A storage recommendation is incomplete if it ignores what happens when the device fails.

Ask:

• What data is unique?
• Where is the second copy?
• How recent is it?
• Is the backup isolated from the primary failure?
• Has recovery ever been tested?

A fast storage system with no recovery plan is still fragile.

Controlled failure: the selected drive disappears

Now the scenario changes.

The selected storage device no longer appears where the user expects it.

Do not replace it yet.

Use the Week 3 path:

physical device
      ↓
interface + power
      ↓
firmware/controller
      ↓
OS detection
      ↓
partition/filesystem/mount
      ↓
application access

Choose your first three checks based on the evidence you have.

If firmware cannot see a SATA SSD, useful checks may include SATA power, SATA data, supported motherboard port, or a known-good cable or port.

If firmware sees the device but the operating system does not show a usable volume, the investigation moves higher.

That distinction should control your troubleshooting path.

Build the storage decision record

Preserve:

1. user and workload requirements;
2. must-have versus nice-to-have priorities;
3. three candidate comparisons;
4. platform compatibility checks;
5. final selection;
6. one rejected alternative and why;
7. RAID decision;
8. backup and recovery decision;
9. missing-drive troubleshooting path.

Another technician should be able to read the record and understand why the recommendation exists.

A good storage decision can be defended without mentioning a favorite brand.

Next, we move from design to diagnosis and look at what storage failure evidence actually means.