Laurent Brand home
← Portfolio homelab
Browse homelab topics

Homelab / Technical documentation

Persistent paths, external disks and recovery.

What the mount evidence proves, how the USB/ext4 interruption was handled, and where backup claims stop.

Jump to a section

Follow paths through every layer

  1. Physical storageDisk attachment and filesystem
  2. Debian guestMount under /mnt/media
  3. Container bind mountStable paths such as /downloads and /shows
Conceptual path model. Physical attachment and guest passthrough are not independently verified by the container mount evidence.

The history mentions an 8 TB external source disk and a 2 TB disk later considered for a transcode cache. Their current physical attachment and mount arrangement are not established by the recovered capacity descriptions.

Illustrative configuration · historical path convention · not an exported stack
services:
  media-tool:
    image: <REVIEWED_IMAGE_REFERENCE>
    volumes:
      - /opt/docker/appdata/<SERVICE>:/config
      - /mnt/media/Downloads:/downloads
      - /mnt/media/Media:/media:ro

The read-only media example is suitable for a reader, not a tool that must replace files. Adapt access to the actual application. This snippet does not prescribe disk devices, UUIDs or a transcode cache.

Evidence: S04 · S05 · S09.

27 September: external ext4 volume disappeared

Recovered report. The old homeserver lost access to the external disk during a USB/xHCI-related interruption. Troubleshooting included deauthorizing a Bluetooth USB device. That sequence does not establish Bluetooth as the root cause.

The reported recovery stopped consumers, checked the filesystem while unmounted, remounted it read/write and resumed services. The filesystem check used e2fsck -f -p; the reported exit status was 0. The recovery recap reported no new I/O, ext4 or USB errors during its observation window.

Command reference: e2fsck manual; this explains repair semantics, not the lab’s current condition.

Evidence: S06.

Read-only triage before a repair decision

Illustrative · read-only · inspect locally; redact device identifiers before sharing
findmnt --target /mnt/media -o TARGET,FSTYPE,OPTIONS
lsblk -o NAME,TYPE,SIZE,FSTYPE,MOUNTPOINTS
journalctl -k --since '-30 min' --no-pager | grep -Ei 'usb|xhci|ext4|I/O error'
  1. Compare the expected mount with the actual filesystem. A missing mount can expose an empty directory on the root disk.
  2. Correlate kernel errors with the time consumers lost access. Do not infer a causal device from one coincident disconnect.
  3. If repair is required, stop consumers through an approved maintenance procedure and verify the unmounted state before choosing a filesystem-specific action.
  4. After recovery, check mount mode, application reads and new kernel errors. A clean observation window is evidence of recovery during that window, not a permanent hardware fix.

A configuration copy is not a backup strategy

The Plex incident includes a configuration backup. The newer Command Center implements two rotating catalog recovery generations. Neither establishes full homelab backup coverage, offline retention or a demonstrated recovery of all services.

A useful recovery record would identify the protected data, a separate copy, restore prerequisites and the result of a restoration test using synthetic or non-sensitive data. No such lab-wide claim is made here.

Evidence: S07 · L02.