Longhorn role in the homelab / farm platform¶
Purpose: Define what Longhorn adds to k3s in this doctrine—distributed block storage for PVCs—and what it does not replace (backups, geographic DR, bulk file semantics). Official baseline: Longhorn documentation, especially installation on K3s and prerequisites (iSCSI, disks).
Package: Platform doctrine package — homelab / farm edge. Comparison (when not Longhorn): Central vs distributed storage architecture.
What Longhorn is responsible for¶
| Responsibility | Notes |
|---|---|
| Dynamic PVs / PVCs | CSI-provisioned volumes for StatefulSets (e.g. database data directories, broker persistence). |
| Replication within the cluster | Replica count across nodes—LAN scope; not multi-building without network design. |
| Snapshots / backups (Longhorn features) | Volume-level tooling; still pair with application-consistent backup for databases (Backup strategy comparison). |
Operational cost (honest)¶
- iSCSI client packages on every node (
Longhorn CSI on K3s). - CPU/RAM for engine + replica management—on Pi, keep few large PVCs vs many tiny ones.
- Disk: SD-only nodes are a poor fit for Longhorn backing stores; prefer USB3 SSD or better per operator narratives in
Pi + k3s + Longhorn capture.
What Longhorn does not guarantee¶
| Expectation | Reality |
|---|---|
| “HA database” without app backup | PostgreSQL still needs logical dumps / PITR policy for farm records. |
| Geo-redundancy | Longhorn is not cross-region object storage. |
| Ransomware-proof immutability | Use object-lock, air-gap, or offline copies—see DR package. |
Diagram — Longhorn relative to workloads¶
```mermaid flowchart TB pod["StatefulSet pod"] pvc["PVC"] lh["Longhorn volume"] disk1["Node A disk"] disk2["Node B disk"]
pod --> pvc pvc --> lh lh --> disk1 lh --> disk2 ```