Separate services
Running several jobs on one computer can save hardware; separating the software helps each job stay understandable.
I am not a network engineer, professional reviewer or seasoned homelab expert. I started with a convenient way to watch movies and learned the rest as the setup gradually acquired a rack, several dashboards and opinions about network storage. This site records the long, complicated process of figuring things out as I go.
The notes include wrong turns and decisions that made sense until the equipment submitted its rebuttal. They are written for another capable home user who wants to know why an option was chosen, when a simpler option would have worked and how the conclusion was reached.
Recent notes
Some pieces record what happened to equipment in my home. Others explain a general failure pattern without pretending I personally performed every possible test. The difference should be clear on each page.
Start with the storage and playback stories if you want the lived experience. The rest of the archive explores recovery, privacy, monitoring and security decisions in enough detail to help you decide whether they apply to your own setup.
Browse all nine notesOperations
A monitor can accurately report that a page answers while the job behind that page is failing. This explainer shows what each kind of check can and cannot establish.
Networking
A severe-looking notice does not, by itself, prove that someone got in. This guide explains the difference between a detection, a block and evidence of actual access without describing my private exposure rules.
Storage
A folder can disappear from the normal view while a recycle bin, snapshot or older version still retains the data. This explains a common storage puzzle; the example below is illustrative, not a claim about a specific deletion in my home.
Backups
A successful backup job is reassuring, but it cannot answer the question that matters after a failure: what can actually be restored, and in what order? This is a planning guide, not a report of a completed disaster-recovery test.
Media
The same server and file can behave perfectly on one playback device and badly on another. Useful diagnosis begins by naming the exact device, app and playback mode instead of treating Plex as one indivisible machine.
Storage
The server still had power and several local parts were running. Too many important actions were waiting on the same unavailable storage connection, which made one fault look like a failure of the entire platform.
The lab / general map
A network fault can look like a storage failure. A storage failure can make the server interface appear frozen. One incompatible playback device can make a healthy media server look underpowered. Understanding which job depends on which other job is more useful than memorizing model numbers.
The lab page explains why someone might split storage from applications, use cables for stationary devices or keep a second playback option. It also explains the price of those choices: each extra layer creates another thing that can fail.
See the lab mapRunning several jobs on one computer can save hardware; separating the software helps each job stay understandable.
The NAS manages shared data separately. That flexibility makes the network connection a dependency worth watching.
Fixed equipment benefits from predictable cables. Wireless still earns its place for everything that needs to move.
A good experience depends on what the screen can play, not just how powerful the computer in the other room is.
How I recommend things
I label the difference. Problems stay in the write-up, even when they make an expensive purchase look foolish. A product is not “best” merely because it survived long enough to appear in a photograph.
A useful recommendation explains the job first. If a less expensive or less complicated option does the same job, that belongs in the discussion too.
There are no paid placements or affiliate links here now. If I add affiliate links later, I will label them where they appear.