Chapter 10 — Exercises

Thirty problems, from concept checks to full reconstruction labs. They follow the order the chapter builds: levels and failure budgets, the six parameters, parity math, virtual reconstruction, the forced-rebuild disaster, then forensic rigor and the progressive project. (answer in Appendix) marks a worked solution in Answers to Selected Exercises; ⭐ marks a stretch problem. Problems tagged (lab) assume the practice images and tooling described in Appendix J. Several ask you to calculate and verify, assemble a virtual volume, or write the report — do those with a keyboard and a hex editor, not just in your head. Treat every reconstruction problem as a hypothesis test on copies; if a step would write to an original, you have answered it wrong.

Group A — RAID levels and failure budgets

Warm-up concept checks. If you cannot do these from memory, nothing downstream will stick — the level dictates the redundancy budget, and the redundancy budget dictates every recovery decision you make.

10.1 Build the master table. For each of RAID 0, 1, 5, 6, and 10, state: (a) the minimum number of disks; (b) the usable-capacity formula in terms of N members of equal size; and (c) the maximum number of simultaneous member losses the level can survive before data is unrecoverable from redundancy alone. Then extend the table with one row each for RAID 50 and RAID 60, describing their failure budget in terms of "per sub-array." Finally, compute the usable capacity of (i) a six-disk RAID 6 of 4 TB drives and (ii) an eight-disk RAID 10 of 2 TB drives. (answer in Appendix)

10.2 A client tells you, "We don't need backups — we run RAID 6, it's fully redundant." (a) Write a three-sentence rebuttal a non-technical owner would understand, naming at least three loss events RAID does not protect against. (b) To stay honest and balanced, also name the one thing RAID genuinely does protect against, so you are not overselling backups either. This is the single most consequential misconception in the chapter; practice saying both halves cleanly.

10.3 ⭐ Consumer SATA drives quote an unrecoverable read error (URE) rate of roughly 1 in 10¹⁴ bits. (a) Convert that to an approximate number of bytes read before one URE is statistically expected (show the arithmetic: bits → bytes → TiB). (b) A RAID 5 rebuild of six 4 TB drives must read the five survivors in full to recompute the sixth — roughly 20 TB. Explain why that puts the rebuild over the expected-URE line, and why the bigger the disks the worse the odds. (c) State in one sentence why this single statistic is the reason RAID 6 displaced RAID 5 for large arrays.

Group B — Geometry and the six parameters

These fix the vocabulary and the mental model. A startling fraction of failed reconstructions trace back to a sloppy answer to one of these — especially the strip-versus-stripe confusion.

10.4 Name the six parameters that fully define a striped array. Then: (a) state which of the six are irrelevant for a plain two-disk RAID 1 mirror, and why a mirror is the degenerate case of the model; and (b) state which are irrelevant for a two-disk RAID 0 (hint: there is no parity, but order, strip size, and offset still matter — explain why each does). (c) Briefly contrast RAID 10 (mirror-then-stripe) with RAID 01 (stripe-then-mirror): which tolerates a single disk loss more gracefully, why a second loss in the other set kills RAID 01, and why you must never assume "RAID 10" is classic nested 1+0 on a Linux box. (answer in Appendix)

10.5 Define strip and stripe precisely, in your own words. (a) Explain why the casual phrase "stripe size" causes reconstruction failures and which one this book means when it says "strip size." (b) On a four-disk RAID 5 with a 64 KB strip, how many bytes of data are in one full stripe (one horizontal row), counting only the data strips and not parity? Show the calculation.

10.6 A controller's spec sheet says the array uses a "256 KB stripe." (a) What single clarifying question must you ask before trusting that number for a reconstruction? (b) On a five-disk RAID 5, work through both interpretations — 256 KB as the per-disk strip versus 256 KB as the full-stripe width — and show the per-disk strip size each implies. (c) Explain why feeding the wrong one to a tool produces an off-by-a-factor-of-N error that scatters every file-system structure and fails the whole rebuild.

10.7 Match each on-disk metadata format to its signature and the place on a member you would look for it: (i) Linux mdadm v1.2 superblock, (ii) Linux mdadm v1.1 superblock, (iii) Linux mdadm v1.0 / legacy v0.90 superblock, (iv) SNIA DDF (hardware controller), (v) Intel Rapid Storage / IMSM. Use these facts: magic 0xA92B4EFC at offset 4096, at offset 0, or near the end of the device depending on version; DDF anchor 0xDE11DE11 in a reserved area at the end; the literal ASCII string Intel Raid ISM Cfg Sig. near the end. Then explain why so many formats reserve their metadata at the end of the disk rather than the start.

Group C — Parity, XOR, and rotation

Open a Python shell or a hex editor. Parity is arithmetic you can do by hand, and doing it by hand once is worth ten readings — it is the entire redundancy of RAID 5 in a single operator.

10.8 A three-data-disk RAID 5 holds two stripes of bytes. Stripe 0: D0 = 0x3C, D1 = 0xA5, D2 = 0x66. Stripe 1: D0 = 0x0F, D1 = 0xF0, D2 = 0xFF. Compute the parity byte P = D0 ⊕ D1 ⊕ D2 for each stripe, showing your work in binary, and present the result as a small table (stripe, D0, D1, D2, P). (answer in Appendix)

10.9 Continuing from stripe 0 of 10.8 (P = your computed value): (a) the disk holding D1 fails — reconstruct D1 from P, D0, and D2 using D1 = P ⊕ D0 ⊕ D2, and confirm it equals the original 0xA5. (b) Now instead suppose the parity disk for stripe 0 failed — show that you simply recompute P from the surviving data and lose nothing. (c) State in one sentence the property of XOR that makes both cases the same operation.

10.10 ⭐ Two disks in the same RAID 5 stripe are now missing — say D1 and D2. (a) Explain, in terms of "one equation, two unknowns," why a single parity strip cannot recover both. (b) Explain precisely what RAID 6's second syndrome Q adds that makes two-disk recovery possible — what does having two independent equations let you solve? (c) Explain why you cannot hand-compute Q the way you XOR P, naming the field (GF(2⁸)), the generator (g = 0x02), and the reduction polynomial (0x11D), and why that means you reach for a tool implementing the Anvin mathematics.

10.11 In a RAID 5 with rotating parity, the missing strip in a given stripe is sometimes a data strip and sometimes the parity strip, depending on the row. (a) Explain why recovering a missing parity strip is the identical operation to recovering a missing data strip, and why that means "the parity disk died" is no worse for any single stripe than "a data disk died." (b) Tie this back to why rotating parity (rather than a dedicated parity disk, as in RAID 4) spreads the write load instead of bottlenecking on one disk. (c) For a four-disk left-symmetric RAID 5, write out which disk (D0–D3) holds parity for stripe rows 0, 1, 2, 3, and 4, and confirm that the parity position returns to its starting disk every fourth row.

10.12 Reproduce and complete the four-layout map for RAID 5 on four disks (D0–D3). (a) Draw the block-numbering grids for left-asymmetric, left-symmetric, right-asymmetric, and right-symmetric. (b) Fill in the naming map: synchronous corresponds to which symmetry, and asynchronous to which? (c) State which layout is the mdadm default and the one-sentence performance reason it is the default. (d) Given this anonymous grid — row 0 parity on D3, row 1 parity on D2, with data block 3 appearing on D3 in row 1 — identify which of the four layouts it is.

Group D — Virtual reconstruction labs

Hands-on. Build, break, and rebuild on copies. A wrong guess here costs nothing but time — which is precisely why you do every real reconstruction this way too.

10.13 ⭐ (lab) Build a RAID 5 you can break safely, then reconstruct it blind. (a) Create four 256 MB image files, attach them as loop devices (losetup), and mdadm --create a RAID 5 across them with a known chunk size and the default left-symmetric layout. (b) Copy in a handful of files of different sizes — include at least one larger than the full-stripe width and one known-content file (e.g., a video) you can later spot-check. Record every parameter you set, then mdadm --stop. (c) Hand the four raw images to ReclaiMe Free RAID Recovery — or rebuild them by hand in R-Studio's RAID editor — pretending you do not know the parameters, and see whether the tool recovers the order, strip size, and layout you set. Document any mismatch between what you set and what the tool detected, and explain it. (d) Repeat the whole build-break-reconstruct cycle, but this time create the array as an mdadm RAID 10 using the far (f2) layout. Try to reconstruct it with the intuitive "find the mirror pairs, then solve a RAID 0" method, observe that it fails, and explain why — then describe how you would read the actual layout from the superblock rather than guessing it.

10.14 (lab) You are given four member images with intact mdadm superblocks. Running mdadm --examine on the first returns the excerpt below. (a) From this single block, list the values for as many of the six parameters as it answers. (b) State which one parameter it does not fully answer on its own, and what you must do to get it. (c) You then run --examine on the other three members and find one reports Events : 41208 while the rest report 41273. What does that mean, and what do you do with that member? (answer in Appendix)

          Magic : a92b4efc
        Version : 1.2
     Raid Level : raid5
   Raid Devices : 4
    Data Offset : 264192 sectors
         Layout : left-symmetric
     Chunk Size : 512K
   Device Role : Active device 1
   Array State : AAAA

10.15 Now suppose the same four images have proprietary or wiped metadata — --examine reports nothing. Write the empirical reconstruction sequence as an ordered checklist: which parameter do you solve first, which second, and how do you confirm each. Name the specific structures and signatures you align against — the NTFS boot-sector 55 AA at offset 0x1FE and EB 52 90 / NTFS at the start, FILE (46 49 4C 45) records at 1024-byte boundaries, and the ext4 0xEF53 superblock magic — and explain how a correct strip size makes those land exactly where the file system expects them. (d) Before you attempt any of this, how do you confirm you are even holding a classic, fixed-geometry array (RAID 0/1/5/6/10) and not a copy-on-write checksummed system (ZFS raidz, Btrfs) or a database-driven pool (Windows Storage Spaces)? Name one identifying tell for each, and explain why running a RAID-5 calculator against a raidz vdev produces confident, total garbage.

10.16 A reconstruction attempt produces high-entropy noise starting at logical byte 0 — no recognizable boot sector — even though the order, strip size, and parity layout all came from a trustworthy superblock. (a) Which of the six parameters is the most likely culprit, and why does an error in it shift everything downstream? (b) You recall the array was Linux software RAID rebuilt with mdadm --create on copies. Explain how that specific command could have introduced the error (hint: what does modern --create choose by default that --assemble instead reads from the superblock?). (c) State the fix. (d) Suppose you correct the offset, the boot sector now sits cleanly at logical byte 0, but a read-only consistency check still reports errors deep in the directory tree. What does that tell you about whether the offset was the only wrong parameter, and which two parameters would you re-test next?

Group E — The forced-rebuild disaster

Judgment under pressure, with a panicked owner watching. The technically correct move is almost always "slow down and image first"; these problems rehearse it until it is reflex.

10.17 Walk through the degraded-rebuild cascade on a RAID 5 as a numbered timeline, from "Day 0: disk fails" through "array offline." At each step, annotate the array's redundancy budget (how many further faults it can absorb), and identify the single exact moment at which a fully recoverable situation becomes mathematically unrecoverable. (answer in Appendix)

10.18 A healthy RAID 5 has just dropped one disk and gone degraded; you are first on the scene with the business owner watching anxiously. (a) List, in order, the correct first four actions. (b) Explain why the first action is essentially "stop and do nothing automatic" rather than "insert a replacement." (c) The owner asks, "Can we keep using it while you work?" — give your answer and the one-sentence reason. (d) Even in a pure (non-forensic) recovery where no court is involved, name two things you should still document before touching anything — and explain how that record helps you reassemble the array correctly later.

10.19 ⭐ A hardware controller's BIOS menu offers Rebuild, Initialize, Create New Array, and Verify / Consistency Check. For each of the four, state (a) whether it is safe to run on the original drives of a degraded array, (b) what it actually writes to the disks, and (c) which can be irreversibly destructive and how. Then explain in one sentence why "image first, act only on copies" makes the entire menu moot.

10.20 Explain why a degraded array that is powered off is in a stable state, while a degraded array being rebuilt is at maximum risk. Reference all three of the compounding factors from the chapter: latent sector errors that stay hidden until read, correlated (same-make, same-batch, same-age) failure, and the full-surface read load a rebuild imposes. Why is the rebuild often the first full-surface read in a year?

10.21 In a degraded RAID 5 you image even the member the controller marked "failed." (a) Explain why that disk is usually still mostly readable and therefore still useful. (b) Show, with the everyday example of a "failed" disk that has 312 bad sectors plus a survivor that has a handful of its own, why parity covers almost all of the gaps — and define the one condition under which a stripe is genuinely lost (two members bad at the same stripe offset). (c) Explain why this is why a controller's "double failure" so often becomes a near-total recovery on the bench.

Group F — Forensic reconstruction, reporting, and custody

The same reconstruction as Group D, now with courtroom stakes. The technical act is identical; the difference is documentation, hashing, scope discipline, and reproducibility.

10.22 (write the report) Draft the reconstruction-parameters block for a forensic report covering a four-disk RAID 5 you rebuilt from images. Include: array level; the member set with each disk's serial and original bay; disk order; strip size; parity layout; data offset; the source of each parameter (metadata vs. empirical); whether any member was stale or partially unreadable; and a one-line verification statement. Write it so precisely that a second examiner could reproduce the identical volume from the same images. (answer in Appendix)

10.23 You receive a sealed evidence box containing five physically identical, unlabeled drives pulled from a seized server, with no documentation of bay order. (a) List the chain-of-custody and documentation steps you perform before you image a single sector. (b) Explain why "which disk sat in which bay" can be the difference between a clean order determination and a guess. (c) Describe how you would label and track the drives so they never become anonymous again.

10.24 ⭐ A reconstructed RAID volume is described in this book as a "derived exhibit." (a) Explain what that phrase means and how its evidentiary lineage differs from a single forensic image. (b) Explain why it raises the bar above "here are the recovered files." (c) List the specific properties of your reconstruction that let it survive a Daubert challenge (Chapter 25) and cross-examination (Chapter 27) — and why an opposing expert reproducing your identical volume is a strength.

10.25 (calculate and verify the hash) You image four members and run sha256sum member*.img > members.sha256. The next morning you re-hash all four and member3.img's SHA-256 has changed while the other three match. (a) What does the change tell you with certainty? (b) Name the two most likely causes. (c) State what you do next, and tie your answer to the role of the write-blocker (Ch.14) and to why hashing happens immediately after imaging rather than the next day. (d) If this image were evidence and the changed hash could not be explained, what is the impact on the admissibility of anything derived from it, and why does that underscore acquiring through a verified write-blocker in the first place?

Group G — Progressive project: when your case source is an array

Carry the running case forward. Your Forensic Case File stops pretending evidence is ever a single tidy disk and starts handling the array the real world hands you.

10.26 Your Forensic Case File has so far treated evidence as single images. The case server in the corporate IP-theft matter (anchor case, Ch.1) turns out to be a four-disk RAID 5. Produce the four artifacts the chapter requires you to add, with realistic, internally consistent values: (1) a physical-configuration record (each drive's serial, bay, controller model, plus a note that you photographed the chassis); (2) a per-member acquisition log (image filename, SHA-256, ddrescue map note for each disk); (3) a reconstruction-parameters block (the six parameters and how each was derived); and (4) a verification note (the read-only consistency-check result and a sample of files opened to confirm geometry).

10.27 Once the array is reconstructed and verified, you run your timeline analysis (Ch.21) and Windows artifact analysis (Ch.16–20) against the reconstructed volume. (a) Explain what changes — and what does not change — compared with running those analyses against a single-disk image. (b) Explain why the reconstruction is now part of your method that you must be prepared to defend, and what would happen on cross-examination if you could not state the parameters and their derivation.

10.28 ⭐ One member of the array was stale — it had dropped out weeks before the others and held an older, internally consistent file system, so you excluded it from the rebuild. Write the one-paragraph explanation you would put in your report so that a non-technical judge understands (a) how you detected the stale member (event/sequence counters; parity inconsistency on that disk's strips), and (b) why including it would have produced silently wrong file contents with no obvious error — connecting it to the principle that the absence of a trace is itself a trace.

10.29 ⭐ Your verified reconstruction of the case server mounts — but the volume is encrypted: either it was a BitLocker-protected array all along, or the array was hit by ransomware before seizure and every member carries uniformly encrypted strips. (a) Explain why a perfect reconstruction still leaves you holding ciphertext, and why reconstructing an encrypted array is no different mechanically from reconstructing a plaintext one. (b) State which chapter you turn to for each case — Chapter 12 for ransomware, Chapter 29 for full-disk encryption. (c) Explain, for the ransomware case, why "but we had RAID" gave the business no protection at all — what does uniform encryption across every member do to the redundancy?

10.30 (write the report) The engagement is over. Write the three-to-five-sentence "lessons learned / recommendations" paragraph for your final report — or for a recovery client's debrief — translating this chapter's hard-won rules into plain guidance: treat RAID as uptime, not backup; never let an unsupervised rebuild run on aging, same-batch disks; image every member before any repair; and keep a tested, rotated, verified backup that lives off the array. Pitch it so a non-technical owner will actually follow it the next time an amber light comes on.

Self-check. You have mastered this chapter when you can take a pile of unlabeled disk images, prove which belong to the array and which is stale, derive all six parameters — from metadata when it exists and empirically when it does not — assemble a virtual volume that opens large files cleanly from deep in the directory tree, and write the reconstruction up so precisely that a second examiner reproduces it byte-for-byte, all without ever writing a single sector to an original. If the phrase "just force the rebuild" still sounds harmless to you, reread the degraded-rebuild cascade in index.md before you turn to Chapter 11 — phones fight back differently, but the discipline of image-first never changes.