Laurent Brand home
← Portfolio homelab
Browse homelab topics

Homelab / Technical documentation

Observe first. Change with an explicit recovery plan.

Monitoring semantics, bounded checks, persistence and the difference between recovery evidence and recovery proposals.

Jump to a section

A health signal has a defined scope

Uptime Kuma runs in the ASUS Debian VM and monitors the primary host and its services in the user-confirmed layout. The exact monitor definitions and delivered alerts are not independently verified here.

The Command Center’s /healthz is application liveness. Its server-side HTTP probes report reachability and status codes, not a complete workflow. An authenticated service returning 401 can be reachable while a test expecting 200 fails. Neither outcome proves a user can complete a task.

Illustrative · read-only · selected state fields only
docker inspect <CONTAINER> --format '{{.State.Status}}'
docker inspect <CONTAINER> --format '{{if .State.Health}}{{.State.Health.Status}}{{else}}no healthcheck{{end}}'
docker inspect <CONTAINER> --format '{{.RestartCount}}'

Check identity, observation time and the signal’s definition before drawing a conclusion. A restart count is cumulative for that container instance.

Evidence: S14 · S19 · L02.

Before and after an approved change

  1. Establish the expected service and its persistent data. Capture a minimal baseline without environment variables, account records or full inspection dumps.
  2. Define rollback and data compatibility before an upgrade, mount edit or recovery action. Keep raw evidence private.
  3. After the approved change, compare mount destinations, selected state fields and restart counts. Check the application’s actual function using synthetic data.
  4. Record the test time, what passed and what was not tested. Do not silently promote a configuration syntax check into an end-to-end result.

These are illustrative operating procedures. Server evidence gathering for this documentation was read-only; no service was restarted, reconfigured or repaired.

Automatic recovery remains a proposal

The discussed recovery agent allowed automatic restarts only for Plex and Pi-hole. Proposed safeguards included dry-run mode, three unhealthy observations, a 30-minute cooldown, identity/state validation and healthcheck requirements. Other containers required explicit approval.

Proposed: no implementation or running agent was established by the available evidence. Historical permission for those two services is not a reason to run an agent while preparing documentation.

Evidence: S14.

Recoverability needs a demonstrated restore

The reported Plex configuration recovery and Command Center restart-persistence test are useful, scoped results. Neither establishes a general backup policy, off-host retention or restoration of the entire lab. Keep backup inventory and recovery evidence in protected operational records.

For failure-specific procedures, see storage recovery, DNS diagnostics and the incident records.

Evidence: S07 · L04.