JUMP TO SECTIONChoose a lesson section
What you'll be able to explain.
- 01Recognize CPU, ECC RAM, BMC, HBA, RAID controller, power, network, and storage roles.
- 02Compare RAID 0/1/5/6/10 capacity and failure tolerance without confusing RAID with backup.
- 03Collect evidence and identify the affected physical disk before recommending replacement.
- 04Distinguish storage redundancy, monitoring, and tested recovery as separate protections.
Which component actually owns the fault?
A production service depends on several physical layers. A healthy OS does not prove the underlying hardware is healthy.
Compute & memory
CPU cores process work; ECC RAM can detect and correct certain memory faults. Repeated corrected-memory alerts merit investigation before they become uncorrectable incidents.
Power & management
Redundant PSUs and UPS capacity reduce a single power component's impact. A baseboard management controller (iDRAC, iLO, or equivalent) exposes sensors, firmware inventory, and out-of-band diagnostics.
Storage & network paths
Disks, backplanes, HBAs or RAID controllers, NICs, cabling, and switches each form a failure domain. A device may be present in the OS while its physical path is degraded.
Operational takeawayStart with the affected service, then work downward: operating system → volume/filesystem → array/controller → physical drive and its path.
RAID protects availability—not recoverability.
A storage array can remain online after some disk failures. It cannot undo accidental deletions, ransomware encryption, or corrupted application data.
RAID 0 / 1
RAID 0 stripes data across drives and has no redundancy. RAID 1 mirrors data across two drives; usable capacity is one drive's size in the common two-drive configuration.
RAID 5 / 6
For equal-sized disks, RAID 5 uses capacity equivalent to one disk for parity and tolerates one disk failure. RAID 6 uses two disks' worth of parity and tolerates two disk failures.
RAID 10
Mirrored pairs are striped together. In typical even-disk arrays, usable capacity is half the raw total. It can survive multiple failures only when no mirror pair loses both members.
RAID 0: 8 TB, no disk failures tolerated
RAID 5: 6 TB, one disk failure tolerated
RAID 6: 4 TB, two disk failures tolerated
RAID 10: 4 TB, some two-disk failure combinations survivableOperational takeawayRAID capacity calculations assume equal-sized disks and ignore metadata, filesystem overhead, hot spares, and vendor-specific layout. Real usable capacity may be lower.
A green dashboard can hide a failing component.
Treat telemetry as evidence, not as permission to take destructive action.
Disk state
Inspect controller slot/bay identity, media errors, wear indicators, array membership, and hot-spare status. Match logical identifiers to the physical chassis label before any swap.
Capacity & latency
Inspect both free filesystem space and available datastore or array capacity. Storage latency can rise during a rebuild; do not equate a healthy-looking free-space counter with a healthy disk.
Recovery position
Before a risky repair, confirm whether reliable backups exist, the last successful recovery test, and what data the workload owner cannot afford to lose.
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINTS
df -h
cat /proc/mdstat # software RAID, where configuredOperational takeawayOn Linux, read-only checks like lsblk, df -h, and (where applicable) cat /proc/mdstat can reveal different storage layers; a hardware-controller-backed RAID needs its vendor tools as well.
The right drive, at the right time.
Hot-swappable does not mean risk-free. Array layout, replacement size, controller behavior and the current resilience state matter.
Before
Confirm affected service, identify the failed physical member, inspect other disk health, verify backup evidence and understand the approved replacement procedure.
During
Use the vendor-supported swap workflow with an authorized window if required. Monitor array state and rebuild progress. Do not remove a second healthy member to guess which bay is failing.
After
Confirm array healthy/rebuild complete, stable I/O latency, application access, alerts cleared, and up-to-date protection jobs; document the replacement serial or bay.
Ticket: Fileshare latency after a disk alert
- Array status: RAID 5 degraded, failed physical drive bay 3
- App latency increased during business hours; bay 4 reports corrected media errors
- Nightly backup reported success; no recent restore test is documented
Read the controller's drive identifiers and verify recovery options before planning an approved replacement. Consider whether another at-risk member changes the repair urgency.
A second failure can destroy RAID 5 availability. A successful backup job alone does not establish restorability.
Connect hardware decisions to the rest of the stack.
The disk is not the application. A technician must trace the dependency from physical health to the user workflow.
Virtualization
A datastore may serve many virtual machines. Disk latency or host-path failure can look like dozens of independent application problems.
Backups
Restore points depend on complete backup chains. An array rebuild and an unrelated immutable backup are different safety mechanisms.
Maintenance
Firmware, controller, and disk replacements may need different approvals and rollback plans. Don't combine unrelated changes during an outage.
Operational takeawayYour objective is not merely a healthy RAID label: it is a verified service with a reliable recovery path.
Can you defend the decision?
Try answering from memory before expanding each explanation. These checks support learning; they are not an exam-readiness score.
01A RAID 5 array contains four equal 2 TB drives. Approximately how much raw usable capacity is available before filesystem overhead?+
About 6 TB. For four equal disks in RAID 5, capacity is approximately (4 − 1) × 2 TB; one disk's worth supports distributed parity.
02A controller reports drive bay 3 failed. What evidence should you gather before physically replacing the drive?+
Match logical/physical identifiers, verify which array the bay belongs to, check all other members and spares, assess workload impact, confirm backups and the vendor-supported change process.
03Why is a fully redundant array not equivalent to a verified backup?+
Redundancy covers some hardware faults, but it does not independently preserve older data states or prove service recovery from deletion, encryption, corruption, or site loss.
Read from the source.
Vendor procedures depend on product version, hardware compatibility, and the environment's approved change controls. Verify the current documentation for any production task.