The goal

A forensics “kit” isn’t a flash drive full of random tools. It’s a repeatable workflow in a box: predictable folder structure, known-good tools, and documentation for what changed and when.

Design constraints

• Predictable: same paths every time so you don’t hunt for tools in a panic
• Verifiable: tool binaries and reference files can be hashed and periodically re-verified
• Separable: one area for tools, one for case outputs, one for documentation
• Safe by default: read-only workflows first; write actions are explicit

High-level structure

• tools/ — portable executables and scripts
• docs/ — quickstart, runbooks, vendor manuals
• reference/ — known-good utilities, checksums, test images
• cases/ — never store long-term evidence here; this is working space only

What I’m documenting as I go

• How I version the toolkit
• How I verify tool integrity (hash manifests)
• How I keep case outputs separated and attributable

Next iteration

• Add a “field checklist” you can print or keep as a pinned note
• Add a minimal evidence intake form template
• Build a small script to generate a fresh case folder + hashing manifest automatically

Why this exists

I build storage projects with one goal: make recovery boring…

Early decisions

• Separate “fast scratch” from “archival”
• Treat snapshots as part of the product, not a nice-to-have
• Assume at least one disk will fail at the worst time

What I’m testing

• Restore speed (not just backup success)
• Bit rot detection
• Permissions model for shared working folders

Next steps

• Document the final topology and parts list
• Add automated health reporting (smart, scrub, snapshot status)
• Write the “what I broke” section