📖 Chapter 01 — The Lab as a System
The home lab is for learning. The family data is for keeping. These are different jobs, and the system should treat them differently.
Learning Objectives
- Define the "blast radius" of a lab mistake and how to limit it
- Set up the dataset boundaries that separate lab from family
- Apply the principle of least privilege to lab operations
- Establish a "before you push to prod" discipline
Introduction
Every home lab has two kinds of data: the production data the family relies on (photos, videos, documents, calendars), and the experimental data the lab produces (test VMs, scratch containers, half-finished side projects). Mixing them is the most common home lab mistake.
This chapter is about the structure that keeps them separate.
The blast radius principle
The blast radius is the maximum damage a single mistake can cause. In the home lab:
- A bad command on a lab VM: blast radius = the VM and its data. Recoverable.
- A bad command on the family NAS: blast radius = the family data. Potentially catastrophic.
The discipline of home lab is to keep the blast radius of lab mistakes small. The way to do this is to make sure lab experiments cannot, by design or by accident, affect the family data.
Three rules
Three rules that, together, limit the blast radius:
Rule 1: Lab data lives in its own dataset
From Volume 1, Chapter 4, the dataset tree included tank/Lab as a separate top-level dataset. This is the dataset for lab work:
tank/Lab is owned by TK only (mode 700), encrypted (in case the lab contains sensitive data), and has ABSE (Access Based Share Enumeration) on so the family can't see it.
Lab VMs mount tank/Lab for their storage. They cannot mount tank/Family, tank/Photos, or any other family dataset. The mount permissions enforce this; even if a VM is compromised, the family data is invisible.
Rule 2: Lab VMs and containers cannot access the family SMB shares
SMB shares for the family are protected by the dataset permissions above. Lab VMs can be configured with the Family group in TrueNAS users; don't do that. Lab VMs and lab containers should be authenticated as a separate user (or not at all, in the case of containers) that has access to tank/Lab and nothing else.
The principle of least privilege: the lab user can only see the lab data. The family users can see the family data. Neither can see the other's data.
Rule 3: Lab experiments are tested in isolation first
Before any lab change touches the "real" lab, it's tested in a separate test environment. For Docker, this means: a separate docker-compose.yml file, run with a different project name. For VMs, this means: a clone or a fresh VM, not the one with the actual lab work in it.
The discipline: never run a new config against your real data without testing it first. The 10 minutes of testing is worth the hours of cleanup when the config is wrong.
The "production" vs "lab" boundary
Even within the lab, there's a hierarchy:
- Production lab services: the apps the family actually uses (Immich, Jellyfin, Vaultwarden, Paperless, Nextcloud). These run on the Apps dataset, with the Apps snapshot policy, with full backups. They are treated as production.
- Lab services: the apps only TK uses (a personal project, a development environment, a test instance of something). These run on the Lab dataset, with a less aggressive snapshot policy, with no family backup.
The boundary is: would the family notice if this app disappeared tomorrow? If yes, it's a production lab service. If no, it's a lab service.
The snapshot policy difference
From Volume 1, Chapter 9, the snapshot policy for the Lab dataset is intentionally less aggressive:
| Dataset | Snapshot policy | Why |
|---|---|---|
| Apps/immich | Before each update, plus daily for 7 days | Family data; needs protection |
| Apps/jellyfin | Before each update, plus weekly | Family data; needs protection |
| Lab (general) | Daily for 7 days | Lab work; less critical |
| Lab/<specific project> | None | Ephemeral; can be recreated |
The lab snapshots are real (so a mistake can be undone), but not as extensive as the production lab snapshots. The space savings are real; the discipline is the same.
The "before you push to prod" discipline
For every lab service that's "production lab" (family-facing), the discipline is the same as a real production system:
- Test in a separate environment first.
- Document the change (a commit message, a wiki entry, a comment in the docker-compose.yml).
- Take a snapshot of the current state before changing it.
- Apply the change.
- Verify the change works (does the family still have access? are the photos still there?).
- If something's wrong, roll back to the snapshot.
This is the same discipline used in real production systems. The home lab is the right place to learn it, because the cost of a mistake is small (your own data, not your company's data) and the learning is real.
The "test data" pattern
For development and learning, the right approach is to use test data, not real data.
- Learning Docker? Use a test container (Nginx, Redis, anything), not a production lab app.
- Learning Kubernetes? Set up a single-node k3s cluster in a VM. Use test workloads.
- Learning a new monitoring tool? Point it at a test VM, not the real NAS.
Test data is the laboratory. Real data is the production system. The two should not be in the same place. The blast radius of a learning exercise is a test container, not a family photo library.
Documenting the lab
Lab work is easy to forget. The fix: document it. The minimum useful documentation:
- For each lab service: a one-page note explaining what it is, why it exists, and how to access it.
- For each lab dataset: a note explaining what's in it and the snapshot policy.
- For each "this was a learning exercise" project: a note explaining what you learned, what worked, what didn't.
Store the documentation in the Lab dataset itself. A tank/Lab/docs/ folder. Markdown files. Editable from any device with access to the share.
The "lab is for learning, family is for living" summary
| Dimension | Family | Lab |
|---|---|---|
| Dataset | Family, Photos, Videos, Documents, etc. | Lab |
| Snapshot policy | Aggressive (multi-tier, long retention) | Light (daily for 7 days, or none for ephemeral) |
| Backups | 3-2-1 (Chapter 05) | None, or single copy to an external drive |
| Access | Family users | TK only |
| Encryption | Only for Private subdatasets | Yes, for the whole Lab dataset |
| Discipline | Treat as production | Treat as a workshop |
Engineering Note
The lab exists to be broken. The family data does not. The discipline is to keep those two facts separate. When you do something in the lab, the worst case is "I have to set this up again." When you do something to the family data, the worst case is "I lost years of irreplaceable photos." The two should never be in the same risk profile.
If you find yourself "just quickly trying this thing" on the family data, stop. Set up a test environment. Use test data. The 30 minutes of setup is worth the hours of cleanup when the experiment goes wrong.
Summary
The home lab and the family data live on the same hardware but in different datasets, with different users, different snapshot policies, and different backup strategies. The blast radius of a lab mistake is bounded to the Lab dataset. Test in isolation. Use test data. Document the lab in the Lab dataset. The discipline is what makes the lab a learning environment instead of a risk to the family.
Checklist
- ⬜ Verify the Lab dataset exists and has the right permissions (TK only, mode 700, encrypted)
- ⬜ Verify lab VMs/containers have a separate user with access only to
tank/Lab - ⬜ Document each lab service: what it is, why, how to access
- ⬜ For every "before you push to prod" change, follow the 6-step discipline
Looking Ahead
Chapter 02 is networking fundamentals. The home network is the layer that connects everything: the NAS, the family's devices, the lab VMs, the internet. Understanding the basics of IPs, subnets, and VLANs is what makes the rest of the volume make sense.