Chapter 3: Storage Technology — Hard Drives, SSDs, Flash Media, RAID, and How Each Stores (and Loses) Data

Where you are: Part I, Chapter 3 of 40. Chapter 2 took you down to bits, bytes, sectors, and clusters and established this book's first law — deletion removes the pointer, not the data. This chapter zooms back out to the physical devices that hold those sectors: how a hard drive, an SSD, a flash card, and a RAID array actually store your data, and the very different ways each one loses it. The wedding-photos anchor — the client's accidentally reformatted family drive — returns here, because the first question in any recovery or investigation, "What kind of media is this?", decides everything that follows.

Learning paths: 💾 Data Recovery readers: this is bedrock — the failure modes here map directly onto the recovery chapters (Ch.8 HDD, Ch.9 SSD/flash, Ch.10 RAID). 🔍 Forensic Examiner: identifying the medium correctly determines whether deleted data even survives to be found — on a hard drive it usually does; on a TRIMmed SSD it often does not. 🛡️ Incident Response: the RAID/NAS/SAN sections tell you what you are really imaging when "the server" turns out to be twelve disks and a parity scheme. 📜 Legal/eDiscovery: understanding why an SSD can quietly destroy evidence between seizure and analysis shapes your preservation orders and your clients' expectations.

The first question on the bench: what am I holding?

A drive arrives at the lab in a padded envelope with a sticky note: "10 years of family photos. Wife reformatted it by mistake. Please help." Before you touch a single tool, before you write a line of a dd command, you have to answer one question that will dictate every decision afterward: what kind of storage device is this?

It matters more than beginners expect. If that drive is a conventional hard disk — spinning platters, magnetic coating — then Chapter 2's promise holds in its strongest form: the reformat almost certainly rewrote only a few small structures near the front of the disk, and ten years of photographs are still sitting in their original sectors as undisturbed magnetic patterns, waiting to be carved back out. The data is there. Your job is patience and method.

If that same enclosure contains a solid-state drive, the calculus changes completely. A modern operating system issues a TRIM command after a format, and the SSD's controller may have already begun erasing the flash blocks that held those photos — physically, irreversibly, in the background, with no tool on Earth able to bring them back. The pointer is gone and the data may be going. Same sticky note, same human need, two utterly different prognoses.

Why This Matters. This is theme #4 in action — technology changes, principles don't. The principle ("understand the medium before you act") is constant; the medium is anything but. A recovery tech who treats every drive like spinning rust will destroy SSD evidence by waiting, and an examiner who treats every SSD like a hard drive will promise a court recoveries that physics will not deliver. The discipline starts with correct identification.

Storage technology is also where the two disciplines of this book meet the metal. Data recovery asks how do I get the bytes back? Digital forensics asks how do I get the bytes back in a way I can prove is complete and unaltered? Both questions have the same prerequisite: you must understand how the device records data, where it hides data the user never sees, and how it fails. The rest of this chapter walks the four families of storage you will meet on the bench — magnetic hard drives, solid-state drives, removable flash, and multi-disk RAID/NAS/SAN — and for each one answers the two questions this book never stops asking: how does it store, and how does it lose?

A note on vocabulary before we start: Chapter 2 defined the logical view — the drive as a numbered array of 512-byte (or 4,096-byte) sectors addressed by Logical Block Address, with byte offset = LBA × sector size. This chapter is about the physical reality underneath that tidy abstraction. The gap between the two — the fact that "sector 15,234,567" is a polite fiction maintained by firmware — is exactly where both the difficulty and the opportunity of our craft live.

The hard disk drive: precision machining at nanometer scale

For four decades the hard disk drive (HDD) was the place data lived, and despite the SSD's rise it still stores the overwhelming majority of the world's bytes — in data centers, NAS boxes, archives, and the older consumer machines that fill a recovery shop's intake shelf. An HDD is, mechanically, one of the most astonishing mass-produced objects ever made: read/write heads the size of a speck fly three to five nanometers above platters spinning at 7,200 RPM, never touching, positioning themselves over tracks narrower than a wavelength of visible light. When that precision holds, it stores terabytes reliably for years. When it fails — and it is the only storage type in this chapter with moving parts that wear out — it fails in ways that are mechanical, dramatic, and often racing a clock.

HDD anatomy: the parts you must be able to name

              HARD DISK DRIVE — top view (lid removed) + side section

   TOP VIEW                                  SIDE SECTION (platter stack)
   +-------------------------------+
   |   spindle motor               |              spindle
   |       (O)===== platter =====  |               ||
   |      /                     \  |        =======[]=======  platter 0
   |     |    read/write HEAD ---+ |         head >--.   (surfaces 0 up / 1 down)
   |     |    (flies ~3-5 nm)    | |        =======[]=======  platter 1
   |      \                     /  |         head >--.
   |   actuator ARM ___________/   |        =======[]=======  platter 2
   |        \      /                |               ||
   |   VOICE COIL MOTOR (VCM)       |     actuator assembly: all arms/heads
   +-------------------------------+      move together as one comb
            |                   |
            | flex ribbon cable |
   +--------+-------------------+--+
   |  PCB (underside of drive)     |
   |  [ SoC controller ] [ DRAM ]  |
   |  [ motor driver  ] [ ROM/NVR] |
   |  [ TVS diodes - sacrificial ] |
   +-------------------------------+

   Hidden on the platters, in reserved "negative" cylinders:
   the SERVICE AREA (a.k.a. System Area) — firmware modules, the
   TRANSLATOR, P-list & G-list defect tables, SMART logs, head adaptives.

Walk the parts:

• Platters. Rigid disks (glass or aluminum) coated with a thin magnetic film. Data is written as tiny magnetized regions. A drive has one to several platters, and both surfaces of each are used, so a three-platter drive has up to six recording surfaces. Each surface is divided into concentric tracks, each track into sectors (the 512- or 4,096-byte unit from Chapter 2). The same-numbered track across all surfaces forms a cylinder. Modern drives use zoned recording: outer tracks are physically longer and hold more sectors than inner tracks, which is why the outer (lower-LBA) region of a disk is measurably faster.

• Read/write heads. One per surface, mounted on the ends of the actuator arms. The write element is a tiny electromagnet; the read element is a magnetoresistive sensor — historically GMR (giant magnetoresistance), now usually TMR (tunneling magnetoresistance) — whose resistance changes as it passes over magnetized regions. Heads do not touch the platter; they ride on a cushion of air (an "air bearing") at a flying height now measured in single-digit nanometers. A smoke particle is hundreds of times taller than that gap. This is why HDDs are sealed and why opening one outside a clean environment is a recipe for destruction.

• Actuator arm and voice coil motor (VCM). All the heads are mounted on a single rigid comb that pivots to position them over the right track. The VCM — a coil between strong rare-earth magnets — swings the comb with extraordinary speed and precision (servo feedback corrects position thousands of times per revolution). When you hear a healthy drive "seek," that is the VCM working.

• Spindle motor. Spins the platters at a constant rate — 5,400 or 7,200 RPM in consumer drives, 10,000 or 15,000 in older enterprise drives. Modern motors use a fluid dynamic bearing (FDB) for quiet, long-lived rotation.

• Printed circuit board (PCB). Bolted to the underside, the PCB carries the main controller (a system-on-chip handling the interface, cache, and ECC), a motor driver chip, cache DRAM, and a small ROM/NVRAM that holds firmware bootstrap code and — critically — drive-specific adaptive parameters. Many PCBs also carry TVS diodes (transient-voltage-suppression diodes) deliberately designed to short out and sacrifice themselves during a power surge, protecting the rest of the board.

• The service area (System Area). This is the part beginners never learn and professionals never forget. On reserved tracks — often described as "negative" cylinders outside the user-addressable range — the drive stores its own operating system: firmware modules, the translator (the map from logical LBA to physical platter location), the defect tables (P-list, the factory primary defect list; G-list, the grown defect list of sectors reallocated during the drive's life), SMART logs, and per-head adaptive calibration data. The service area is invisible to the host. When it corrupts, the drive may not report its correct model, may show zero capacity, may simply hang in a "busy" state — even though every byte of your data is still perfectly intact on the platters.

How an HDD stores data: magnetization, PMR, and SMR

At the lowest level, a hard drive stores bits as the direction of magnetization of microscopic grains in the platter coating. Each bit is encoded in the transition (or absence of a transition) between magnetized regions, run through channel-coding schemes that pack the data densely while keeping it readable. The figure of merit is areal density — bits per square inch — and the entire history of the HDD is the history of squeezing it higher.

Two recording geometries matter for our work:

• PMR (perpendicular magnetic recording). The grains are magnetized vertically, perpendicular to the platter surface, which packs them tighter than the older longitudinal method. PMR is the conventional, recovery-friendly baseline.
• SMR (shingled magnetic recording). To push density further, SMR partially overlaps adjacent tracks like roof shingles. Reading is fine, but you cannot rewrite one track without disturbing the ones overlapping it, so the drive must rewrite an entire zone (a band of tracks) to change any data in it. Drive-managed SMR (DM-SMR) hides this behind the firmware using a persistent-cache region, which means writes can be slow and unpredictable, and — importantly for us — the physical location of your data can shift around during background reorganization. SMR drives complicate both recovery (the on-platter layout no longer maps simply to LBA) and imaging (a drive thrashing through band rewrites is slow and stressed). Emerging energy-assisted methods (HAMR, MAMR) push density even higher and bring their own recovery wrinkles, covered in Chapter 8.

Recovery vs. Forensics. On a healthy magnetic platter, deleted ≠ destroyed in its purest form: a deleted, formatted, or even partition-wiped HDD usually retains the user's data as untouched magnetization until something overwrites those exact sectors. For recovery, that is the good news that makes the wedding photos saveable. For forensics, it is the reason a suspect's "I deleted everything" is so often disprovable — the bytes are still there, and a defensible image captures them. The same physical fact serves restoration and proof alike.

How an HDD loses data: the failure modes

Because the HDD is mechanical, its failures split cleanly into the physical (the device is hurt) and the logical (the device is fine; the data structures are damaged). Telling them apart at intake is one of the most valuable skills in recovery.

• Head crash. A head contacts the platter — from shock, wear, or contamination — and gouges the magnetic coating. This is catastrophic in two ways: the data in the scored region is physically scraped off (genuinely unrecoverable), and the debris circulates inside the sealed chamber, causing further crashes. The classic symptom is the "click of death": the drive spins up, the heads fail to read the servo data they need to position, the firmware retracts and retries, and you hear a rhythmic click… click… click. Every retry drags damaged heads across the platters, destroying more data. A clicking drive must be powered down immediately and sent to a clean-room specialist (Chapter 8); continuing to power it is the single most common way clients (and untrained techs) turn a recoverable drive into a paperweight.

• Motor seizure and stiction. The spindle motor's bearing fails, or the heads become stuck to the platter surface ("stiction"). The drive will not spin up at all, sometimes emitting a faint hum or a soft buzz as it tries. This is a mechanical repair (motor swap, head unsticking) for a clean-room lab — never a job for percussive "fixes."

• PCB failure. A power event (a bad supply, reversed polarity, a surge) burns the board. Sometimes only the sacrificial TVS diode blows, an easy fix; sometimes the motor driver or the controller is destroyed. The trap for the unwary: on most drives made in the last ~15 years you cannot simply swap on a donor PCB, because the ROM/NVRAM on the original board holds adaptive parameters unique to that drive's heads. A correct PCB repair transfers the original ROM chip (or its contents) to the donor board. Swap the board blindly and the drive may not initialize — or worse, mis-calibrate and damage itself.

• Firmware / service-area corruption. A module in the service area becomes unreadable or inconsistent. The drive may report a garbage model string, capacity 0, "0 LBA," or hang busy. Your data is untouched, but the drive cannot present it. Accessing and repairing the service area requires specialized hardware (the industry standard is the PC-3000, see Chapter 8 and Appendix C).

• Bad sectors. Localized media defects where the magnetic coating can no longer reliably hold data. When a sector fails to read even after ECC and retries, firmware marks it Current Pending (SMART attribute 197). On the next successful write, the drive reallocates it to a spare sector and increments the Reallocated Sectors Count (SMART attribute 5), recording the event in the G-list. A handful of reallocations is normal aging; hundreds or thousands of pending/reallocated sectors mean a drive that is dying and should be imaged once, carefully, before it gets worse.

• Logical damage. The platters and mechanics are perfectly healthy, but the data structures are corrupt: an accidental reformat (the wedding photos), a deleted partition, a corrupted file system, a failed OS update. No clean room needed — this is the domain of imaging plus the logical-recovery and carving techniques of Chapters 6 and 7.

War Story. A man brought in a drive that had clicked once, then gone silent. His nephew had told him to "freeze it overnight and it'll work long enough to copy the files" — folk advice from a different era of drives. He'd power-cycled it nineteen times trying. Each cycle, the damaged heads had scraped the platters a little more. We recovered roughly 60% of his files; the other 40% lived in regions the heads had by then physically destroyed. The lesson he learned the hard way is theme #2 — the original is sacred. On a failing drive, every spin-up is a withdrawal from an account you cannot refill. Image once, image early, or stop and call someone who can.

Chain of Custody. At intake, before any power is applied, record the device's identity exactly: manufacturer, model number, serial number, stated capacity, interface (SATA/SAS/IDE/USB), and visible condition (corrosion, burn marks, prior-repair tampering). For an HDD the serial and model are printed on the top label and burned into the firmware; capturing both — and later confirming they match what the drive reports electronically — is part of proving the evidence you analyzed is the evidence you received. This intake record is the first page of the case file you will build across this book.

The solid-state drive: no moving parts, entirely new problems

An SSD has no platters, no heads, no motor — nothing mechanical to crash or seize. It is, electrically, far more robust against shock and far faster. And yet SSDs fail more surprisingly than hard drives, because all of that mechanical simplicity is traded for a layer of staggering software complexity inside the drive. An SSD is not a passive array of sectors; it is a tiny, opaque computer running proprietary firmware that decides, moment to moment, where your data physically lives — and that occasionally decides to throw it away. Understanding the SSD means understanding that controller and the abstraction it maintains.

SSD anatomy: a small computer pretending to be a disk

              SOLID-STATE DRIVE  (2.5" SATA or M.2 NVMe)

   host  +---------------------------------------------------+
   <====>|  INTERFACE  (SATA  or  PCIe / NVMe)               |
         |     |                                             |
         |     v                                             |
         |  +---------------------+    +-------------------+  |
         |  |     CONTROLLER      |<==>|   DRAM cache      |  |
         |  |  (SoC: CPU cores,   |    |  (holds the FTL   |  |
         |  |   ECC / LDPC engine,|    |   mapping table)  |  |
         |  |   AES crypto engine,|    +-------------------+  |
         |  |   FTL firmware)     |   [DRAM-less drives use  |
         |  +----+----+----+----+-+    Host Memory Buffer]   |
         |       |    |    |    |   parallel channels         |
         |     [NAND][NAND][NAND][NAND][NAND][NAND]           |
         |      die   die   die   die   die   die             |
         |   each die: PLANES > BLOCKS > PAGES > CELLS         |
         |   [ PLP capacitors - enterprise drives only ]      |
         +---------------------------------------------------+

• Controller. A system-on-chip with one or more embedded CPU cores. It speaks the host interface (SATA or NVMe), runs the Flash Translation Layer (below), drives a powerful ECC engine (modern TLC/QLC needs LDPC error correction just to function), and very often contains a hardware AES engine that encrypts everything written to NAND with an internal key — even when the user has set no password. That last detail has enormous consequences for recovery and forensics, as we will see.

• NAND flash packages. The actual storage: several flash chips wired to the controller across multiple parallel channels (parallelism is where SSD speed comes from). Each package contains one or more dies, each die divided into planes, blocks, pages, and finally cells.

• DRAM cache. A small DRAM chip holding the FTL mapping table (and write buffering) for speed. Budget "DRAM-less" drives omit it and borrow a slice of system RAM via the NVMe Host Memory Buffer (HMB) — cheaper, and a meaningful difference in how a sudden power loss can corrupt the map.

• Power-loss protection (PLP). Enterprise SSDs carry on-board capacitors that hold enough charge to flush in-flight writes and the mapping table to NAND if power vanishes. Most consumer SSDs do not — which is the root of one of their nastiest failure modes.

How NAND flash stores data: floating gates and the bits-per-cell tradeoff

A NAND flash cell is a special transistor that traps electric charge. In classic floating-gate NAND, charge is stored on an isolated "floating gate" between the control gate and the channel; in modern 3D NAND, charge is trapped in an insulating layer (charge-trap flash). Either way, the presence or absence — and amount — of trapped charge sets the cell's threshold voltage, and reading the cell means sensing which voltage band it falls into. More charge bands per cell means more bits stored per cell, and that single design choice drives the entire economics and reliability of the drive:

Read that table as a reliability gradient. Cramming sixteen distinguishable voltage levels into one QLC cell (versus two in SLC) makes each level's window razor-thin, so charge drift, temperature, and wear corrupt QLC far sooner — which is why dense drives lean so hard on LDPC error correction and why they wear out in far fewer write cycles. Manufacturers claw back endurance with 3D NAND (stacking cells vertically — 64, 128, 232+ layers — which allowed a return to physically larger, more durable cells) and with SLC caching, where a TLC/QLC drive runs a region of its NAND in fast single-bit mode as a write buffer and folds the data down to dense storage later. (That cache is also why a cheap drive screams for the first few gigabytes of a big copy, then abruptly slows: the SLC cache filled.)

Now the structural detail that makes SSDs hard, the single most important idea in this section:

NAND ORGANIZATION  — read/program at the PAGE; erase only at the BLOCK

   PACKAGE
     +-- DIE 0
     |    +-- PLANE 0
     |    |    +-- BLOCK 0     <-- ERASE unit (e.g., 256 pages ~= 4 MB)
     |    |    |    +-- PAGE 0  <-- READ / PROGRAM unit (e.g., 16 KB)
     |    |    |    +-- PAGE 1
     |    |    |    +-- ...  PAGE 255
     |    |    +-- BLOCK 1
     |    |    +-- ...  BLOCK n
     |    +-- PLANE 1 ...
     +-- DIE 1 ...

   The asymmetry: you PROGRAM a page (write 0s into an erased page) but
   you can only ERASE a whole BLOCK back to 1s. You CANNOT overwrite a
   page in place. To "change" page 5, the controller writes the new data
   to a fresh page elsewhere, updates its map, and ERASES the old block
   later. This single fact is the root of everything below.

You can read or program (write) one page at a time — typically 4 KB to 16 KB. But you can only erase an entire block — hundreds of pages, often around 4 MB — at once. There is no "overwrite this 4 KB page" operation in NAND. To modify data, the controller must write the new version to a different already-erased page, mark the old page stale, and reclaim that whole block later. No host-visible "sector" maps permanently to one physical location. Something has to maintain that ever-shifting map — and that something is the FTL.

The Flash Translation Layer: the great abstraction (and the great obstacle)

The Flash Translation Layer (FTL) is the firmware inside the controller that makes a chaotic, erase-before-write, wear-limited grid of NAND blocks look to your operating system like a simple, stable array of rewritable 512-byte sectors. It is brilliant engineering, and it is the reason SSD recovery is so much harder than HDD recovery. The FTL handles:

• Logical-to-physical mapping. It maintains a table translating each host LBA to the physical NAND page currently holding that data. Because that page moves with every rewrite, the table changes constantly. It lives in DRAM for speed and is periodically persisted to NAND. If that table is lost or corrupted, the raw NAND is a scrambled jigsaw with no picture on the box.
• Wear leveling. NAND cells die after a finite number of program/erase cycles, so the FTL spreads writes evenly across all blocks. Dynamic wear leveling balances the actively written blocks; static wear leveling also periodically relocates cold, never-changing data so those blocks take their share of wear. A consequence: your "unchanged" file may have been physically moved many times without your knowledge.
• Garbage collection (GC). Because blocks fill with a mix of valid and stale pages, the controller periodically copies the still-valid pages out of a block, then erases the whole block to reclaim it. GC runs in the background, on the drive's own schedule, whether or not the host is doing anything — which is why an SSD can keep changing internally after you stop writing to it.
• Over-provisioning. Drives reserve spare capacity (the ~7% gap between GiB and GB, plus often more) invisible to the host, giving GC and wear leveling room to work and replacing worn-out blocks.
• Write amplification. Because a small host write can trigger read-modify-write and GC churn, one logical write can cause several physical writes. The Write Amplification Factor (WAF) is why SSD endurance specs are conservative and why heavy small-write workloads age a drive fast.
• Bad-block management and ECC. The controller retires failing blocks, and every read passes through error correction — the cell-level error rate of TLC/QLC is high enough that the raw data is wrong before correction; LDPC makes it right.

Limitation. The FTL is proprietary, undocumented, and unique to each controller family — often further obfuscated with vendor-specific scrambling, internal striping across dies, and XOR keys. This is why "chip-off" recovery, which works on simple flash, largely fails on modern SSDs: even if you desolder the NAND and dump every page, you still face an unknown FTL to reassemble it, plus the controller's encryption. On an SSD, the controller is not a passive bridge to your data — it is the only entity that knows where your data is. We return to this hard limit in Chapter 9.

How an SSD loses data: the failure modes

• Controller failure (the most common SSD death). The controller chip fails — from a firmware fault, a manufacturing defect, or a power event — and the drive vanishes from the system, reports 0 MB, or appears under a generic "panic"/"safe-mode" identity. The cruel part: the NAND is usually fine, full of intact data, but inaccessible because the one component that understands the FTL is dead. Unlike an HDD PCB, you generally cannot swap an SSD controller — the FTL state and adaptives are bound to that specific controller and configuration. Recovery, when possible, means specialized vendor-specific techniques or a "Spider Board"/test-point approach in a flash lab.

• NAND wear-out. Program/erase cycles are exhausted, blocks start failing program/erase operations (SMART program-fail/erase-fail counters climb), and the spare pool is consumed. Mercifully, many SSDs respond to end-of-life by dropping into a read-only state — a genuine recovery opportunity, if you image immediately and do not power-cycle hoping it improves.

• Sudden power-loss corruption. This is the consumer SSD's signature failure. If power drops while the controller is updating the FTL mapping table (and there are no PLP capacitors), the map can be left inconsistent. The drive may then "brick": report wrong/zero capacity, hang, or lose large swaths of mapping at once. The data pages may be intact in NAND, but the map that finds them is broken. This is why unexpected outages are far more dangerous to a cheap SSD than to a hard drive.

• Firmware bugs. SSDs run real software and ship real bugs. There is a notorious class of firmware defects that bricked certain enterprise SSDs after an exact number of power-on hours (e.g., a counter overflowing at 32,768 or 40,000 hours), and others that corrupted data under specific access patterns. Keeping firmware current is genuine data protection — and recognizing a known firmware-bug signature can save a recovery.

• Read disturb and retention loss (data fade). Reading a page slightly disturbs the charge in neighboring cells; over many reads, errors accumulate. Worse for our work: trapped charge leaks over time, especially in worn cells and at high temperature. A worn consumer SSD left unpowered can begin losing data in months. JEDEC's retention specs assume a powered, healthy drive; a seized SSD sitting in an evidence drawer for a year is operating well outside those assumptions.

Recovery vs. Forensics. The SSD inverts this book's comforting first law. On an HDD, deleted ≠ destroyed. On an SSD, deletion plus TRIM plus the controller's background garbage collection can mean deleted really does equal destroyed — often within minutes, with no host involvement. For recovery, that collapses the window: a deleted file on a TRIM-enabled SSD may be gone before the client even calls you. For forensics, it means an SSD can lawfully and irreversibly erase evidence after seizure, while it sits powered in your lab, simply because its firmware decided to tidy up. The forensic countermeasure — write-block and image fast, and document the device's TRIM state — is developed in Chapter 9 and Chapter 14.

Ethics Note. Because so many SSDs encrypt at rest with an internal controller key, a single firmware command can perform an "instant secure erase" by discarding that key, rendering terabytes unrecoverable in under a second. As a recovery professional you must set honest expectations; as a forensic examiner you must understand that a suspect (or a careless first responder) can trigger this — and that the absence of recoverable data is itself a finding to document, not a failure to hide. Full-disk and self-encrypting-drive details live in Chapter 29.

Flash media: USB drives, SD cards, and the monolith problem

USB flash drives, SD and microSD cards, CompactFlash, and the eMMC/UFS chips soldered inside phones and tablets are all built from the same NAND flash as SSDs — and every one of them contains a controller running an FTL, because NAND's erase-before-write nature demands it. A microSD card is, quite literally, a fingernail-sized SSD. What distinguishes flash media for the recovery professional is not the storage principle but the physical construction, because construction decides whether physical recovery is merely hard or essentially impossible.

USB / SD FLASH MEDIA — two constructions

  STANDARD (more recoverable)            MONOLITHIC (very hard)
  +----------------------------+         +---------------------------+
  | PCB                        |         |   one epoxy package       |
  |  [Controller]   [ NAND  ]  |         |  controller + NAND die +  |
  |  [crystal]  [passives ]    |         |  bond wiring ALL sealed   |
  +----------------------------+         |  inside a single block:   |
   The NAND chip can be          |       |   - no chip to desolder    |
   desoldered ("chip-off") and   |       |   - must locate TEST POINTS|
   read on a programmer; then     |      |     and read raw NAND via  |
   the FTL is reverse-engineered. |      |     ISP, then rebuild FTL  |
                                         +---------------------------+
  Older/larger USB sticks.               ALL microSD and most modern
                                         USB sticks are monolithic.

• Standard construction places a discrete NAND chip and a separate controller on a small PCB. If the controller dies but the NAND survives, a flash lab can desolder the NAND ("chip-off"), read its raw pages on a specialized programmer, and then attempt to reverse the FTL (descramble, correct ECC, de-interleave, and rebuild the page→LBA mapping) to reconstruct the file system. This is painstaking and tool-dependent (PC-3000 Flash, Rusolut Visual NAND Reconstructor; see Appendix C), but it is possible.

• Monolithic construction seals the controller, the NAND die, and all the bond wiring into one epoxy package — there is no separate chip to lift. All microSD cards and most modern USB sticks are monoliths. Recovery means finding the package's exposed test points, identifying the pinout (power, ground, clock, command, and data lines) by trial against known layouts, and reading the raw NAND through an in-system-programming (ISP) jig — and only then facing the FTL reconstruction. It is among the most specialized work in the field, with no guarantee of success.

• eMMC and UFS are the embedded equivalents soldered onto phone, tablet, and IoT mainboards. They too contain an FTL. Recovery and forensic acquisition use ISP test points or full chip-off (desoldering the BGA package and reballing it onto a reader). These techniques anchor the mobile chapters (Ch.11 recovery, Ch.24 forensics).

Tool Tip. Two failure modes peculiar to cheap flash deserve a place in your reflexes. First, counterfeit / fake-capacity media: the controller is reprogrammed to report (say) 256 GB while only 8 GB of real NAND exists; writes past the real capacity silently wrap and corrupt earlier data. Verify suspicious media with a write-and-read-back tester (f3 on Linux/macOS, h2testw on Windows) before trusting it. Second, a snapped USB connector — the most common "dead" USB drive — is often just mechanical: if the NAND and controller survived, a flash lab can read the chip directly. Never assume a physically broken stick means lost data until the chip itself is assessed.

RAID: combining disks for speed, redundancy, or both

So far every device has been a single unit. RAID — Redundant Array of Independent Disks — combines several disks into one logical volume to gain speed, fault tolerance, or both. RAID is everywhere a recovery or IR professional works: file servers, NAS boxes, virtualization hosts, video-surveillance recorders, databases. And RAID generates a distinct category of disaster, because its whole value proposition — "survive a disk failure" — lulls owners into skipping backups, so that when the array finally exceeds its redundancy, the loss is total and the data is large.

Three primitive techniques underlie every RAID level:

• Striping spreads consecutive chunks of data ("stripes," typically 16 KB–256 KB each) across multiple disks so reads and writes happen in parallel — pure speed, no protection.
• Mirroring keeps identical copies on two or more disks — pure protection, no capacity gain.
• Parity stores mathematical redundancy (computed with XOR) that lets the array reconstruct one missing disk's data from the survivors — a compromise: most of the capacity, plus single-disk fault tolerance.

The standard levels mix these three. For each, learn how it stores and how it dies.

RAID 0 — striping (speed, zero redundancy)

RAID 0 — STRIPING (minimum 2 disks; NO redundancy)

   logical data: A B C D E F        Disk 1   Disk 2
                                     +-----+  +-----+
                                     |  A  |  |  B  |   stripe 0
                                     |  C  |  |  D  |   stripe 1
                                     |  E  |  |  F  |   stripe 2
                                     +-----+  +-----+
   Capacity = N x smallest disk.  Fastest.  Tolerates ZERO failures:
   lose EITHER disk and the array is dead (you have A,C,E or B,D,F only).

RAID 0 interleaves data across all disks for maximum throughput and full combined capacity, with no redundancy whatsoever. Any single disk failure destroys the entire array, because every file is fragmented across all members. Recovery from a RAID 0 with a failed member requires first recovering the failed disk physically (it is now a single-disk recovery problem — see HDD/SSD sections above), then reassembling the stripe set. RAID 0 is for scratch data you can afford to lose; treating it as primary storage is a recovery case waiting to happen.

RAID 1 — mirroring (redundancy, not backup)

RAID 1 — MIRRORING (minimum 2 disks)

   logical data: A B C              Disk 1   Disk 2
                                     +-----+  +-----+
                                     |  A  |  |  A  |
                                     |  B  |  |  B  |
                                     |  C  |  |  C  |
                                     +-----+  +-----+
   Capacity = ONE disk.  Survives N-1 disk failures.
   BUT: a delete / format / ransomware write hits BOTH disks instantly.

RAID 1 writes the same data to two (or more) disks, surviving the loss of all but one member. If a disk dies, you simply read from a survivor — the easiest RAID recovery there is, because each mirror member is a complete, standalone copy you can image and analyze as an ordinary single disk. But here is the dangerous misconception: mirroring is redundancy against hardware failure, not a backup. A deletion, an accidental format, a corruption, or a ransomware encryption pass is replicated to both disks instantly — the array faithfully mirrors the disaster. The ransomware anchor case (Chapter 12) turns on exactly this: the victim "had RAID," believed they were protected, and watched the malware encrypt every mirror at once.

RAID 5 — striping with distributed parity

RAID 5 — STRIPING + DISTRIBUTED PARITY (minimum 3 disks)
         parity block = XOR of the data blocks in that stripe

   Disk 1   Disk 2   Disk 3
   +-----+  +-----+  +-----+
   | A1  |  | A2  |  | Ap  |   stripe 0  (parity on disk 3)
   | B1  |  | Bp  |  | B2  |   stripe 1  (parity rotates to disk 2)
   | Cp  |  | C1  |  | C2  |   stripe 2  (parity rotates to disk 1)
   +-----+  +-----+  +-----+
   Capacity = (N-1) x disk.  Survives ANY ONE disk failure:
   rebuild the missing block by XOR-ing the surviving blocks in the stripe.

RAID 5 stripes data across all disks like RAID 0 but adds one parity block per stripe, and rotates which disk holds the parity from stripe to stripe so no single disk becomes a write bottleneck. The parity is just the XOR of the data blocks in that stripe, and XOR's self-inverse property is the whole trick:

RAID 5 parity is just XOR. Take one byte per disk across a 3-disk stripe:

   Disk 1 (D1) = 0x6D = 0110 1101
   Disk 2 (D2) = 0x41 = 0100 0001
   ------------------------------- XOR
   Parity (P)  = 0x2C = 0010 1100   <- this is what gets stored on disk 3

   Now Disk 2 fails. Reconstruct it from the survivors (D1 and P):
   D1          = 0110 1101
   P           = 0010 1100
   ------------------------------- XOR
   recovered   = 0100 0001 = 0x41  <- D2, restored bit-for-bit.

Because P = D1 ⊕ D2 ⊕ D3 ⊕ …, any one missing term equals the XOR of all the others. That is why a RAID 5 survives exactly one disk: the array recomputes the dead disk's blocks on the fly from parity. Lose a second disk before the first is rebuilt and the math runs out — the array is gone.

Two ways RAID 5 kills data deserve emphasis. The write hole: if power is lost mid-stripe-write, the data and its parity can be left inconsistent, so a later rebuild silently produces wrong bytes (battery-backed controller caches and journaling mitigate this). The rebuild trap: replacing a failed disk forces the controller to read every sector of every surviving disk to recompute the new member — a brutal, hours-to-days stress test on aging drives that frequently triggers a second failure, or hits an unrecoverable read error (URE) that aborts the rebuild. With multi-terabyte disks, the cumulative probability of a URE across a full rebuild is high enough that RAID 5 has fallen out of favor for large arrays in exactly the moment its single redundancy is being spent.

RAID 6 — dual distributed parity

RAID 6 — DUAL DISTRIBUTED PARITY (minimum 4 disks)
         P = XOR parity,  Q = Reed-Solomon (Galois-field) parity

   Disk 1   Disk 2   Disk 3   Disk 4
   +-----+  +-----+  +-----+  +-----+
   | A1  |  | A2  |  | Ap  |  | Aq  |   stripe 0
   | B1  |  | Bp  |  | Bq  |  | B2  |   stripe 1
   | Cp  |  | Cq  |  | C1  |  | C2  |   stripe 2
   +-----+  +-----+  +-----+  +-----+
   Capacity = (N-2) x disk.  Survives ANY TWO disks at once.

RAID 6 adds a second, independent parity block (the "Q" syndrome, computed with Reed-Solomon coding over a Galois field rather than plain XOR) so the array survives two simultaneous disk failures. It costs two disks of capacity and slows writes (every write updates two parities), but it covers the exact gap that sinks RAID 5: a second failure during a long rebuild. For today's large-disk arrays, RAID 6 (or vendor equivalents) is the responsible parity choice.

RAID 10 — a mirror of stripes

RAID 10 (1+0) — STRIPE ACROSS MIRRORED PAIRS (minimum 4 disks)

           stripe ->        mirror pair A        mirror pair B
   logical: A B C D       Disk 1   Disk 2       Disk 3   Disk 4
                          +-----+  +-----+      +-----+  +-----+
                          |  A  |  |  A  |      |  B  |  |  B  |
                          |  C  |  |  C  |      |  D  |  |  D  |
                          +-----+  +-----+      +-----+  +-----+
   Capacity = N/2.  Fast + redundant.  Survives 1 disk PER mirror pair
   (best case N/2 failures) — but lose BOTH halves of one pair and it's gone.

RAID 10 combines the two safe primitives: it mirrors disks into pairs, then stripes across the pairs. You get striping's speed and mirroring's clean redundancy, at the cost of half your raw capacity. It survives losing one disk in each mirror pair (so potentially several failures), but it dies the instant both members of any one pair fail. Because rebuilds copy from a single surviving mirror rather than recomputing parity across the whole array, RAID 10 rebuilds far faster and gentler than RAID 5/6 — which is why databases and busy virtualization hosts favor it. (Nested levels like RAID 50 and 60 extend the same ideas to larger arrays; they appear in Chapter 10.)

The parameters that make or break RAID recovery

A RAID volume is not self-describing the way a single disk is. To turn a pile of member disks back into a readable volume — which is exactly what you do when the controller dies or the configuration is lost — you must recover its geometry:

• Disk order — which physical disk is member 0, 1, 2, …
• Stripe (chunk) size — 16 KB? 64 KB? 256 KB?
• Parity rotation and direction — left vs. right, synchronous vs. asynchronous (where parity sits relative to data in each successive stripe)
• Start offset — where the data area begins on each member (after any metadata/reserved region)
• The level itself — 0/1/5/6/10, and how many members

This metadata is stored differently by every RAID implementation. Hardware RAID controllers keep proprietary configuration in NVRAM and/or in a metadata region on the disks (some follow the SNIA DDF standard, signature 0xDE11DE11). Software RAID stores it on the disks themselves: Linux's md/mdadm writes a superblock whose magic number is 0xa92b4efc; Windows uses dynamic-disk/LDM or Storage Spaces metadata; Intel's motherboard "fakeRAID" (RST/IMSM) embeds an ASCII signature Intel Raid ISM Cfg Sig. near the end of each member.

0x001000:  fc 4e 2b a9 01 00 00 00  00 00 00 00 00 00 00 00  |.N+.............|
           ^^^^^^^^^^^                                        Linux md superblock:
           md magic 0xa92b4efc (stored little-endian = FC 4E 2B A9)
                       ^^ ^^ ^^ ^^  next field: major version = 1

When the metadata is gone entirely, you reverse the parameters from the data: locate file-system structures (a boot sector, an NTFS $MFT, an ext4 superblock) and known file signatures, observe at which byte boundaries they fall, run entropy analysis to spot parity blocks (parity looks like noise), and iterate until the reassembled volume mounts cleanly. Tools automate much of this (mdadm --assemble, testdisk, R-Studio, UFS Explorer, ReclaiMe — see Chapter 10), but they all rely on getting these five parameters right.

Recovery vs. Forensics. The cardinal RAID rule serves both disciplines: image every member disk individually, then reconstruct the array virtually — never rebuild on the original hardware. A hardware rebuild writes to your evidence and, if the parameters or a disk are marginal, can finish the job the failure started. For recovery, virtual reassembly lets you try different geometries non-destructively until the file system appears. For forensics, per-disk imaging with per-disk hashes preserves each member as independent, verifiable evidence, and the reconstruction becomes a documented, repeatable analysis step rather than an irreversible act on the originals. Same procedure; restoration on one side, admissibility on the other.

Limitation. RAID redundancy protects against disk failure — and only disk failure. It does nothing against deletion, formatting, file-system corruption, ransomware, controller faults that scribble on all members, fire, theft, or the all-too-common "rebuilt onto the wrong disk" human error. The hard-won professional mantra: RAID is not a backup. When a client says "we're safe, we have RAID," you are usually looking at a future recovery case.

NAS and SAN: storage that lives on the network

Once arrays leave the inside of a single computer, they become network storage, and two architectures dominate — distinguished by whether they serve files or blocks.

A NAS (network-attached storage) is an appliance that serves files over a network using protocols like SMB/CIFS, NFS, or AFP — the Synology, QNAP, or TrueNAS box humming in a closet. Inside, a NAS is a small computer (usually running embedded Linux) managing several disks, most often as Linux md/mdadm RAID layered with LVM and an ext4, Btrfs, or ZFS file system. Vendor schemes add a twist — Synology's SHR, for instance, is a flexible mdadm-plus-LVM arrangement that allows mixed disk sizes. For the professional, the practical implication is that you rarely recover or examine a NAS through its own web interface. You pull the disks, image each one individually (single-disk recovery rules apply to each), and then reconstruct the entire stack offline: rebuild the RAID virtually, reassemble LVM, then mount the file system read-only. Skipping a layer — or letting the NAS "repair" itself on boot — is how NAS data gets lost during recovery.

A SAN (storage-area network) serves raw blocks, not files, over a dedicated high-speed fabric — iSCSI over Ethernet, or Fibre Channel — presenting LUNs (logical unit numbers) that the connected servers see as ordinary local disks and format with their own file systems. SANs are enterprise-scale, often multi-tenant, and almost never something you can simply power down and image disk-by-disk. Forensically, that creates real constraints: you usually cannot attach a write-blocker to a live production SAN, so acquisition happens at the LUN level (a storage snapshot, or imaging the presented volume from a host) and in cooperation with the storage administrator. The unit of recovery and the unit of evidence is the LUN, not the physical disk.

Legal Note. A multi-tenant SAN can hold data belonging to many departments, customers, or even unrelated organizations on the same physical hardware. Your warrant, consent, or engagement scope almost certainly covers one tenant's LUNs — not the array. Imaging beyond your authority is both an evidentiary problem (a suppression risk, and a privacy breach of third parties) and an ethical one. Scope discipline starts at the storage layer: identify exactly which LUNs are in scope, document how you isolated them, and image only those. The legal machinery behind this — warrants, scope, and the constitutional limits — is developed in Chapter 25; cloud-hosted equivalents in Chapter 31.

A modern wrinkle worth flagging now: copy-on-write file systems like ZFS and Btrfs, common on NAS and enterprise storage, never overwrite live data in place — they write changes to new locations and update pointers, keeping checksums of everything and offering instant snapshots. For our work that is a gift on both sides: snapshots and copy-on-write remnants mean older versions of files frequently persist and can be recovered or examined, even after the "current" version was changed or deleted. We meet these file systems properly in Chapter 4.

A brief word on optical, tape, and "the cloud"

Two older media still surface at intake. Optical discs (CD, DVD, Blu-ray) store data as physical pits/marks read by laser; they fail through scratches, delamination, and "disc rot" (oxidation of the reflective layer), and recovery leans on repeated reads, error-correction, and specialized drives. Magnetic tape (LTO) remains the backbone of long-term archival and backup because it is cheap per terabyte, durable when stored well, and — being offline — immune to ransomware; it is sequential, so recovery and forensic review mean reading the whole tape and parsing its backup format. And "the cloud," for all the marketing, is simply someone else's storage — racks of the same HDDs, SSDs, and SANs in a data center you do not control — which makes its recovery and forensics a matter of access, authority, and provider cooperation rather than soldering irons. That distinct discipline is Chapter 31.

Tool demonstration: identifying and triaging media at intake

Correct identification is not guesswork — the device tells you what it is and how healthy it is, if you ask with the right tools, read-only. The commands below are illustrative (this book never executes tools in its sandbox), but the attributes and outputs are real and worth committing to memory. Always run identification behind a hardware write-blocker when the device is evidence (Chapter 14); these queries are low-risk, but on a failing drive even read activity has a cost, so query once and move on.

Start with the simplest question — rotational or solid-state? — on Linux:

# ROTA column: 1 = rotational (HDD), 0 = SSD/flash
$ lsblk -d -o NAME,ROTA,SIZE,TRAN,MODEL
NAME     ROTA   SIZE TRAN  MODEL
sda         1   1.8T sata  ST2000DM008-2FR102
sdb         0 931.5G sata  Samsung SSD 860 EVO 1TB
nvme0n1     0 953.9G nvme  WD_BLACK SN770 1TB

# Confirm via the ATA IDENTIFY data:
$ sudo hdparm -I /dev/sda | grep -i rotation
        Nominal Media Rotation Rate: 7200
$ sudo hdparm -I /dev/sdb | grep -i rotation
        Nominal Media Rotation Rate: Solid State Device

Then read SMART — the drive's self-recorded health log, and a perfect illustration of theme #3, every action leaves a trace: the drive quietly journals its own decline. For a hard drive, watch the reallocation and pending counts:

$ sudo smartctl -a /dev/sda
Device Model:     ST2000DM008-2FR102
Serial Number:    ZFL2X9KQ
Rotation Rate:    7200 rpm
SMART overall-health self-assessment test result: PASSED        <-- do not trust this alone

ID# ATTRIBUTE_NAME           VALUE WORST THRESH  RAW_VALUE
  5 Reallocated_Sector_Ct      072   072    010      1184       <-- 1,184 sectors already remapped
  9 Power_On_Hours             061   061    000     34122       <-- ~3.9 years powered on
197 Current_Pending_Sector     098   098    000       312       <-- 312 sectors failing NOW
198 Offline_Uncorrectable      098   098    000       312

Read that carefully: the drive says PASSED and its normalized values sit above their thresholds, yet the raw values describe a drive in active mechanical decline — over a thousand reallocated sectors and 312 currently failing reads. The headline "PASSED" is nearly worthless; the raw attributes are the truth. This is a drive to image immediately, once, gently — exactly the posture the wedding-photos client needs and exactly what an unwary tech destroys by running repeated scans.

For a SATA SSD, different attributes carry the story — endurance, not mechanics:

$ sudo smartctl -a /dev/sdb
Device Model:     Samsung SSD 860 EVO 1TB
Rotation Rate:    Solid State Device

ID# ATTRIBUTE_NAME           VALUE WORST THRESH  RAW_VALUE
177 Wear_Leveling_Count        001   001    000      4912    <-- normalized 001: endurance nearly spent
179 Used_Rsvd_Blk_Cnt_Tot      100   100    010         0
181 Program_Fail_Cnt_Total     100   100    000         0
241 Total_LBAs_Written         099   099    000  238900000000

Here the Wear Leveling Count has fallen to a normalized 1 (it starts at 100 and counts down as the average erase count climbs) — this drive is near the end of its rated writes. For NVMe SSDs, SMART data comes from the NVMe health log instead:

$ sudo nvme smart-log /dev/nvme0n1
critical_warning            : 0
temperature                 : 41 C
available_spare             : 100%
available_spare_threshold   : 10%
percentage_used             : 7%          <-- 7% of rated endurance consumed
data_units_written          : 48,236,118  <-- x 1000 x 512 bytes
media_errors                : 0
unsafe_shutdowns            : 9           <-- 9 ungraceful power losses (corruption risk)

percentage_used is the endurance gauge (it can exceed 100%), available_spare shows how much of the over-provisioned block pool remains, and unsafe_shutdowns quietly counts the power-loss events that threaten FTL integrity. On Windows, the same triage comes from PowerShell:

# Media type, bus, and overall health for every physical disk
Get-PhysicalDisk | Select-Object FriendlyName, MediaType, BusType,
    HealthStatus, OperationalStatus,
    @{N='SizeGB';E={[math]::Round($_.Size/1GB,1)}}

# Per-disk reliability counters (wear %, errors, temperature, hours)
Get-PhysicalDisk | Get-StorageReliabilityCounter |
    Select-Object DeviceId, Wear, ReadErrorsTotal, Temperature, PowerOnHours

Finally, a tiny piece of the math behind RAID recovery, so you can see that "reconstruct the missing disk" is concrete, not magic. This function rebuilds one missing member of a RAID 5 (or any single-parity) stripe by XOR-ing the survivors — the exact operation the controller performs internally:

def reconstruct_raid5_block(surviving_blocks):
    """Rebuild one missing block of a RAID-5 stripe by XOR-ing the survivors.

    surviving_blocks: list of equal-length bytes objects -- the data blocks
        AND the parity block from one stripe, in any order, with the failed
        member omitted.
    Returns: the missing block's bytes.

    Because P = D0 ^ D1 ^ ... ^ Dn, any single missing term equals the XOR
    of all the others. Illustrative: real recovery runs this over forensic
    IMAGES of each member, read-only -- never on the original disks.
    """
    if not surviving_blocks:
        raise ValueError("need at least the survivors of one stripe")
    size = len(surviving_blocks[0])
    result = bytearray(size)
    for block in surviving_blocks:
        if len(block) != size:
            raise ValueError("all blocks in a stripe must be equal length")
        for i, byte in enumerate(block):
            result[i] ^= byte
    return bytes(result)

# 3-disk RAID 5, one byte per disk, disk 2 dead. Survivors: D1 and parity P.
assert reconstruct_raid5_block([b"\x6d", b"\x2c"]) == b"\x41"   # recovers 'A'

Try This. On your own machine (never on evidence), run lsblk -d -o NAME,ROTA,SIZE,MODEL (Linux/macOS via diskutil) or Get-PhysicalDisk (Windows) and identify every drive as HDD or SSD, then pull its SMART data and find the reallocated-sector count or percentage_used. You are building the reflex that opens every job: know your medium, and know its health, before you act. A fuller command reference lives in Appendix H.

Worked example: triaging the mystery drive (the wedding photos, revisited)

Return to the envelope from the opening — "10 years of family photos, reformatted by mistake." Here is the triage, step by step, with the storage knowledge of this chapter applied. (The actual recovery of these photos is worked in Chapters 6 and 7; the point here is everything you decide before recovery, driven entirely by what the medium is and how healthy it is.)

Step 1 — Identify, before power. You photograph and record the device: a 2.5-inch SATA drive, label reads WD10SPZX-21Z10T0, serial WX..., 1 TB, with a WD10S model prefix indicating a conventional hard drive, not an SSD. That single fact is the best news of the day: a reformatted magnetic drive almost certainly still holds ten years of photographs as undisturbed magnetization. There is no TRIM on a SATA HDD; deleted ≠ destroyed applies in full force. Had the model decoded to an SSD, you would be having a very different, far more guarded conversation with the client about TRIM and garbage collection (Chapter 9).

Step 2 — Assess health, read-only, once. Behind a write-blocker you pull SMART. Reallocated sectors: 6. Pending: 0. Power-on hours: 19,000. The drive is aging but mechanically sound — no clicking, no busy-state, a low and stable defect count. This is a logical failure (a reformat), not a physical one. No clean room, no PCB work, no service-area repair. Good.

Step 3 — Decide the path the medium dictates. Because the failure is logical and the drive is healthy, the plan is the standard, safest one: image first (theme #2 — the original is sacred), verify with a hash, then do all recovery work on the copy. A reformat typically rewrites only the new file system's metadata near the start of the volume — a few megabytes against a terabyte of photos — so the file system's own deleted-entry records may still point at the originals (logical recovery), and wherever the new format did overwrite the old metadata, the photo data still sits intact in its sectors, recoverable by file carving on JPEG/HEIC/CR2 signatures regardless of any file system (Appendix A catalogs those signatures).

Step 4 — Honest expectation-setting. You tell the client the truth that the medium supports: because this is a magnetic drive that was only reformatted (not overwritten with new data, not an SSD that TRIMmed itself), the prognosis is genuinely good — but you will know for certain only after imaging and analysis, and any photos that happened to sit under the small region the reformat overwrote may be partially damaged. That is theme #5 — know your limitations — stated up front, not discovered later.

Notice that every decision in that triage flowed from two storage facts established before a single recovery tool ran: what the medium is (magnetic HDD, no TRIM) and how healthy it is (logical fault, low defects). Misread either — assume SSD, or miss a clicking head — and the entire plan, and the client's photos, would be at risk.

Common mistakes

• Treating an SSD like a hard drive. Waiting, "letting it rest," or running long surface scans on an SSD wastes the narrow window before garbage collection and TRIM finalize deletions, and risks the controller fading mapping for unpowered, worn NAND. SSD recovery is a race; HDD recovery is patience. Knowing which you hold is the whole game.
• Power-cycling a clicking or buzzing drive. Each spin-up of a drive with crashing heads or a seized motor destroys more data. The "freeze it / tap it / try again" folklore belongs to a dead era of drives. A drive making mechanical noise gets powered down and sent to a clean-room lab — full stop (Chapter 8).
• Blind PCB swaps. Swapping a donor circuit board without transferring the original ROM/adaptives leaves a modern drive unable to initialize — or mis-calibrating into self-harm. The board is not generic; it carries drive-specific data.
• Trusting SMART's "PASSED." The overall health flag is a coarse pass/fail; the raw attributes (reallocated, pending, wear-leveling, percentage-used, unsafe-shutdowns) tell the real story. A "PASSED" drive can be one scan from death.
• Believing RAID is a backup. Redundancy covers disk failure only. Deletion, format, corruption, ransomware, and human error replicate or strike across the whole array. "We have RAID" is not "we have a backup."
• Rebuilding a degraded RAID on the original disks. A hardware rebuild writes to your only copies and stresses aging survivors into a second failure. Image every member individually first, then reconstruct virtually, read-only.
• Chip-off as a first resort on an SSD. On modern SSDs the proprietary FTL and at-rest encryption usually defeat raw NAND dumps. Controller-level and vendor-specific techniques come first; chip-off is a specialized last resort, not a shortcut (Chapter 9).
• Ignoring the medium's geometry at intake. Failing to record model, serial, capacity, interface, and RAID position means you cannot later prove the evidence you analyzed is the evidence you received — and may not be able to reassemble an array at all.

Limitations: knowing when to stop

This chapter's recurring promise — deleted ≠ destroyed — has hard physical edges, and a professional names them honestly rather than overselling hope. Some data is genuinely, permanently gone, and recognizing that is a skill, not a defeat.

On a hard drive, data physically scraped off the platter by a head crash is gone — no tool reads magnetization that has been ground into debris. A platter shattered, deeply scored, or degaussed (exposed to a strong enough magnetic field) carries nothing back. SMR's band-rewrite behavior can also genuinely relocate and overwrite data during normal operation in ways that defeat naive sector-mapping assumptions.

On an SSD, the limits are sharper and arrive faster. Once TRIM plus garbage collection have erased the NAND blocks behind deleted files, the data is electrically gone — not hidden, not faint, gone — and no amount of skill recovers it (Chapter 9). A drive whose controller has issued a cryptographic erase (discarding the internal AES key) leaves NAND full of ciphertext that is, for practical purposes, random noise (Chapter 29). NAND that has exhausted its program/erase endurance, or that has sat unpowered long enough for charge to leak past ECC's ability to reconstruct, has lost its bits at the physical layer. And the proprietary, encrypted FTL means a dead controller can wall off perfectly intact NAND that no one outside the manufacturer can fully decode.

On RAID, redundancy is a fixed budget: a RAID 5 that loses two disks, or a RAID 6 that loses three, or a RAID 10 that loses both halves of one mirror, has mathematically exceeded what its parity or mirroring can reconstruct. The survivors hold only fragments. And across all media, a sufficiently overwritten sector — new data written over old — is the cleanest erasure of all; the comforting cases in this book are recoveries of data that was deleted (pointer removed) but not yet overwritten.

Limitation. The professional finding "the data is not recoverable from this medium" — or, in court, "the evidence is insufficient to reach a conclusion" — is a legitimate, defensible result, not a personal failure. Selling false hope to a grieving client or overstating certainty to a court is the real malpractice. Theme #5 is a discipline: know what your medium cannot give back, and say so plainly.

Progressive project: characterize the evidence device

Your Forensic Case File begins not with analysis but with the device itself. For this chapter's milestone, take the case's primary storage device (use a practice image's source profile or a spare drive of your own — see Appendix J) and produce a one-page Device Identification & Triage sheet that every later step will depend on:

1. Physical description and identity — manufacturer, model number, serial number, stated capacity, interface, and photographs of all labels and any visible damage.
2. Media classification — HDD, SSD, USB flash, SD/eMMC, or RAID member, with the evidence for your call (model-number decode, lsblk ROTA, ATA rotation rate, or physical construction).
3. Health triage — the key SMART/health attributes (reallocated and pending sectors for HDD; wear-leveling/percentage-used and unsafe-shutdowns for SSD), and your read of whether the device is mechanically sound, logically damaged, or physically failing.
4. Recoverability posture — given the medium and its health, what is realistic: full image expected, image-once-urgently, or specialist referral? Note any TRIM/encryption concerns that will shape acquisition.
5. If RAID/NAS — the array level, member count, your best estimate of disk order and stripe size, and the metadata format you found (md superblock, IMSM, DDF), feeding the virtual reconstruction plan.

This sheet is the foundation of the chain of custody and the acquisition plan you formalize in Chapter 5. Date it, sign it, and file it — it is page one of the case.

Summary

Storage technology is the ground every recovery and every investigation stands on, because the medium decides what is possible. You met the four families that fill a lab's intake shelf and, for each, answered this book's two questions — how does it store, and how does it lose? The hard disk drive records data as magnetization on spinning platters read by nanometer-flying heads, governed by firmware in a hidden service area; it stores generously and, crucially, holds deleted data until overwritten — but it fails mechanically, through head crashes, seized motors, blown PCBs, corrupted service areas, and growing bad-sector counts, often racing a clock that every power-cycle winds down. The solid-state drive stores charge in NAND cells (SLC through QLC, denser and less durable at each step), and hides NAND's erase-before-write nature behind a proprietary, encrypting Flash Translation Layer that wear-levels, garbage-collects, and — with TRIM — can make deleted truly mean destroyed; it fails through controller death, NAND wear-out, sudden-power-loss map corruption, and slow charge fade. Flash media are tiny SSDs whose construction — standard versus monolithic — decides whether physical recovery is hard or nearly impossible. RAID trades among striping, mirroring, and XOR/Reed-Solomon parity to buy speed and single- or dual-disk fault tolerance, but it is never a backup, and recovering it means imaging members individually and reconstructing their geometry virtually. NAS and SAN push these arrays onto the network as file- or block-level services that you acquire offline (NAS) or at the LUN level within strict scope (SAN). Through all of it ran the steady principle: technology changes, but the method — identify the medium, respect the original, image first, document everything, and know what cannot be recovered — does not.

You can now: - Identify a storage device as HDD, SSD, flash, or RAID member from its model, interface, rotation rate, and construction — and explain why that classification changes the entire recovery and forensic approach. - Name the parts of an HDD and an SSD and map each device's specific failure modes (head crash, motor seizure, PCB/service-area faults, bad sectors; controller death, NAND wear-out, power-loss corruption, charge fade) to symptoms at intake. - Explain NAND's page/block asymmetry and the Flash Translation Layer, and why TRIM, garbage collection, and at-rest encryption can make SSD deletion irreversible. - Diagram and distinguish RAID 0, 1, 5, 6, and 10 — how each stores data, how many disk failures each survives, and the geometry parameters required to reconstruct one. - Triage a drive read-only with SMART/NVMe health data and PowerShell/lsblk/smartctl, distinguishing a logical fault from a dying device. - State honestly, for any medium, the conditions under which data is genuinely unrecoverable.

What's next. Chapter 4 — File Systems — moves up one layer: now that you know how the hardware stores raw sectors, you will learn how NTFS, ext4, APFS, FAT, exFAT, and HFS+ organize those sectors into files and directories — and exactly what each one does, and leaves behind, when a file is "deleted."

Practice in exercises.md, test yourself with the quiz, apply it in the case studies, review the key takeaways, and go deeper with further reading.