Skip to content

Workstation — Brabham

Last Updated: 2026-09-23 Role: Dan's Windows 11 workstation, gaming PC and AI/dev machine IP: 192.168.1.40 (Ethernet, main LAN) · Tailscale: 100.83.17.77 Location: Office outbuilding

Not a server. It is on only sometimes, which is the single fact that most homelab assumptions about it get wrong — see Backup Strategy.

Disk layout

Six SSDs. Two NVMe, four SATA.

Vol Label Disk Bus Size Purpose
C: — WD SN550 500 GB NVMe 465 GB Windows, applications, user profile
E: NVME Samsung 990 PRO 2 TB NVMe 1863 GB Games · Docker · WSL
D: Downloads&Work Samsung 850 PRO 512 GB SATA 477 GB Downloads, working files
O: AI Samsung 850 PRO 512 GB SATA 477 GB AI/ML work
V: VideoEditing Samsung 850 PRO 512 GB SATA 477 GB Video projects
F: Cache Samsung 860 PRO 1 TB SATA 954 GB Cold caches (pip, conda, HF, npm)

The 990 PRO on E: is the fastest drive in the machine — faster than C: itself. The WD SN550 holding Windows is entry-level, DRAM-less NVMe.

Storage strategy

The allocation follows one rule: put workloads where their access pattern actually matters, and keep churn off the backed-up volume.

What goes where

  • C: (NVMe) — Windows, applications, user profile. Kept as lean as practical because it is the only volume imaged nightly, so everything here costs backup space forever.
  • E: (fastest NVMe) — games, plus Docker and WSL. The dev workloads live here because they are dominated by small random reads (package installs, builds, git metadata), which is exactly where NVMe IOPS beat SATA. Games are the least storage-sensitive thing on the machine — modern load times are CPU-decompression bound, and SATA-vs-NVMe is typically a 1–2 second difference. If E: runs short, move games to F: rather than moving Docker or WSL.
  • F: (SATA, 954 GB) — cold caches. Write-once, read-occasionally, speed irrelevant: pip, conda packages, Hugging Face models, npm. The right use of a large SATA disk.
  • D: / O: / V: (SATA) — data volumes by subject.

What is backed up

Veeam images C: (Operating system) + O: (AI) only. Everything else is deliberately excluded.

⚠️ Anything moved off C: stops being backed up. D:, E:, F: and V: are all outside the backup. That is fine for caches and games; it is a real decision for anything that is your own work.

Docker and WSL on E: is the ideal case — they need the speed, and their .vhdx files are the worst possible content for an image backup: large, and rewritten constantly, so they inflate every nightly incremental forever. Moving them off C: shrank both the full and the ongoing incremental stream.

AppData cleanup, 2026-09-23

C: had fallen to 57.6 GB free (12.4%), which was tight enough to break backups — the VSS shadow-copy diff area could not grow and Windows destroyed the snapshot mid-run (see Backup Strategy troubleshooting).

AppData alone was ~140 GB. Where it went:

Folder GB Action
Local\Docker 26.3 Moved to E:\Docker (Docker Desktop → Settings → Resources → Advanced → Disk image location; it migrates the data itself)
Local\NVIDIA\DXCache 20.9 Deleted. Pure DirectX shader cache, regenerates
Local\LccStudio\DATA 18.1 Left alone — real data, see below
Local\wsl 11.9 Moved to E:\wsl\Ubuntu (wsl --manage Ubuntu --move E:\wsl\Ubuntu)
Roaming\Claude\vm_bundles 8.9 Left — regenerable, but small
Local\Temp 9.4 Left — Veeam already excludes temporary files from the image
Local\Google 9.1 Left — Chrome profile + cache

Result: C: 57.6 → 128.9 GB free (12.4% → 27.7%).

Do NOT relocate AppData itself

Moving AppData wholesale (junction or registry redirect) is unsupported by Microsoft, gets broken by Windows feature updates, and some apps hardcode the path. Worse, AppData is where every application's real state lives — browser and mail profiles, settings, licence activations. Moving it to an excluded volume would shrink the backup while making a bare-metal restore produce a machine with every application reset to factory.

Relocate specific caches instead, which is supported and reversible:

Cache Control
Docker Desktop Settings → Resources → Advanced → Disk image location
WSL distro wsl --manage <Distro> --move <path> (WSL 2.x; shut it down first)
pip PIP_CACHE_DIR
conda packages CONDA_PKGS_DIRS
Hugging Face HF_HOME
PyTorch TORCH_HOME
npm npm_config_cache

LccStudio\DATA is NOT cache

18.1 GB of XGRIDS LCC Studio LiDAR scanner project data — .las point clouds, .ply geometry, 7228 .enx files. It looks like an application cache folder and is not. Do not clear it. It currently lives on C: and is therefore backed up; moving it to a data volume would stop that.

NVIDIA shader cache

Local\NVIDIA\DXCache had reached 20.9 GB because nothing ever caps it. Deleting it costs only slightly longer shader compilation on the next game launch.

Capped at 10 GB on 2026-09-23 (NVIDIA Control Panel → Manage 3D Settings → Shader Cache Size) so it cannot creep back.

The only cost of a smaller cache is shader recompilation — brief stutter the first time an evicted shader is needed, or a game re-running its "compiling shaders" startup screen. Nothing crashes and nothing renders wrong. Eviction only bites if you rotate across many large titles; a handful of regularly-played games fits in 10 GB easily. If stutter appears on a game played often, raise it to 20 GB — a smooth session is worth more than ~11 GB of backup. Volume-level imaging cannot exclude a folder, so the cap is the only control over how much of this cache ends up in the backup.