Backup and disaster recovery package — smart farm stack¶
Purpose¶
Canonical navigation spine for backup and disaster recovery across farmOS, PostgreSQL-backed services, k3s control plane (etcd), Longhorn volumes, Rancher, configuration and secrets, and edge gateways / field devices where they affect whether backups complete or what must survive a site loss.
Topic router (same content, navigation-first): Backup and disaster recovery — doctrine hub.
Design stance: Prefer restore-tested procedures (tabletop or staging) over decorative backup jobs that never complete a full restore. Distinguish backup from synchronization, and block/volume copies from application-consistent recovery.
Evidence stance: Operational claims on this page (what to back up, in what order, and what “consistent” means for PostgreSQL) defer to vendor/project primary documentation in Backup / DR — official documentation cluster and project captures—not forum threads. Broader corpus hygiene: Source authority hardening audit.
Official pointers + captures: Backup / DR — official documentation cluster · homelab backup stack captures · backup-dr link batch.
Platform provisioning context: Platform doctrine package — homelab / farm edge · How to provision k3s, Longhorn, and Rancher on a Raspberry Pi fleet · Platform strategy for farm and homestead services.
Business execution context: Pilot and validation work should prove backup/restore paths—not only deploy clusters—before G*-class spend. Router: Business plan execution and pilot operations hub · Validation backlog and decision gates.
Scope (what this package covers)¶
| Component | In scope for doctrine |
|---|---|
| farmOS + PostgreSQL | Logical exports, version expectations, SoR alignment |
| k3s control plane | Embedded etcd (or external datastore per your install)—snapshots off node disk |
| Longhorn | Volume backup, system backup, CSI—not a substitute for logical DB path unless restore-tested |
| Rancher | Optional; backup/restore in addition to cluster state—encryption config out of band |
| Configuration, secrets, GitOps | Helm values, Sealed Secrets/SOPS/KMS—not fully captured by naive etcd story alone |
| Edge gateways & farm-adjacent services | Config exports, queue disks, central replication policy—Central vs local backup scope |
Recommended read order¶
- Distinctions (below): backup vs sync; volume vs app-aware.
Backup strategy comparison — farmOS, homelab, PostgreSQL, containers— pick mechanisms.Restore and recovery tiers — homelab farm systems— label your targets; fill RPO/RTO after drills.Kubernetes platform backup / DR — Pi fleet, k3s, Longhorn— parallel tracks A–E.Disaster recovery decision rules — farm edge stack— failure classes and restore order.Runbook — backup validation and recovery drill— restore-tested evidence.Central vs local backup scope — farm edge stack·Off-grid implications — backup and networking choices— two-site / power / WAN.
Package map¶
| Topic | Canonical page | What it decides |
|---|---|---|
| Granularity & mechanisms | Backup strategy comparison — farmOS, homelab, PostgreSQL, containers |
Logical DB vs volume vs restic patterns; backup vs sync |
| Tiers & expectations | Restore and recovery tiers — homelab farm systems |
Tier 0–3; RPO/RTO as your filled targets, not wiki-invented SLAs |
| k3s + Longhorn + workloads | Kubernetes platform backup / DR — Pi fleet, k3s, Longhorn |
Parallel tracks (app / Longhorn / etcd / Rancher / secrets) |
| Pi fleet sequence | Raspberry Pi k3s fleet — backup and restore sequence |
Ordered steps aligned to platform guide |
| Central vs edge scope | Central vs local backup scope — farm edge stack |
What must land in one backup store vs local queue |
| DR decision rules | Disaster recovery decision rules — farm edge stack |
Failure classes, restore order, rebuild vs restore |
| Validation & drills | Runbook — backup validation and recovery drill |
Prove restores before an outage |
| Off-grid scheduling | Off-grid implications — backup and networking choices |
Power/WAN vs backup windows |
Core distinctions (non-negotiable)¶
Backup vs synchronization¶
| Backup | Synchronization |
|---|---|
| Point-in-time copies for recovery (rollback, disaster) | Continuous or frequent mirroring for availability or multi-writer convenience |
| Immutability-oriented retention (snapshots, restic generations) | Often overwrites destination—wrong tool for “oops” recovery if conflicts are resolved the wrong way |
| Restore drills prove value | Sync drills prove replication—not the same as application rollback |
Rule: Do not label a sync job (e.g. mirror to second disk) as your only “backup” without a separate versioned recovery path for farm records.
Volume backup vs app-aware restore¶
| Volume / block backup | App-aware (logical) restore |
|---|---|
| Longhorn backup, disk snapshot, cold copy of data directory | pg_dump / vendor export while quiesced or consistent per PostgreSQL rules |
| Fast whole-PVC rollback when files are consistent | Portable restore across versions and hosts for farmOS / Drupal + Postgres |
| Risk: dirty DB pages if captured mid-write without coordination | Preferred for canonical farm records (Tier 2 in restore tiers ) |
Rule: Longhorn volume backup does not replace logical exports for farmOS unless you have proven crash-consistent recovery and accept that risk.
Scope diagram¶
mermaid
flowchart TB
subgraph apps [Application plane]
F[farmOS + PostgreSQL]
B[Brokers / other stateful]
end
subgraph k8s [Kubernetes plane]
E[etcd / k3s]
L[Longhorn volumes]
R[Rancher data]
end
subgraph cfg [Configuration]
S[Secrets + Helm values]
G[Edge gateway / field service config]
end
F --> L
B --> L
R --> L
E --- E
apps --> |logical dumps| Restic[restic / object store]
L --> |volume backup| Restic
E --> |etcd snapshot| Snap[Snapshot store]
S --> |export policy| Restic