Skip to content

Distributed Backup Network Architecture

Context and Problem Statement

Traditional homelab solutions are single-node systems that provide self-hosted services but remain vulnerable to single-site failures (fire, theft, hardware failure). Cloud backup solutions provide redundancy but require trust in corporations and ongoing subscription costs.

How should Famlab be architected to provide true backup resilience while maintaining the self-hosting benefits families want?

Decision Drivers

  • Disaster resilience: Single-site homelab solutions are vulnerable to house fires, theft, natural disasters
  • Cost sustainability: Ongoing cloud subscription costs can become prohibitive for families
  • Trust model: Families already trust people they know, they shouldn't have to trust faceless corporations
  • Network effects: Solution should become more valuable as more family/friends adopt it
  • Simplicity: Must maintain "set and forget" principle despite distributed nature

Considered Options

  1. Traditional homelab: Single-node self-hosted services with local backup
  2. Homelab + cloud backup: Single node with cloud backup integration
  3. Distributed backup network: Multi-node family network with peer-to-peer backup replication

Decision Outcome

Chosen option: Distributed backup network - Famlab's core architecture is a mesh network of family/friend nodes that replicate each other's backup data.

Core Architecture Principles

Primary Function: Famlab is fundamentally a distributed backup system, not just a homelab platform with services.

Network Structure:

  • Each node serves local family as backup target
  • Each node stores encrypted backup replicas from other family nodes
  • Admin manages all nodes in the family network (remote access, configuration)
  • Nodes communicate directly in mesh topology (no central hub)

3-2-1 Backup Achievement:

  • Copy 1: Original data on user devices (laptops, phones)
  • Copy 2: Local Famlab node backup (network share)
  • Copy 3: Distributed replicas across family network nodes

Implementation:

  • Incremental replication between nodes over secure transport
  • Full-disk encryption for data at rest protection
  • Family trust boundary (nodes could access each other's data if needed)

Consequences

  • Good, because achieves true 3-2-1 backup without cloud dependencies
  • Good, because backup resilience increases with network size (network effects)
  • Good, because eliminates single points of failure across geographic locations
  • Good, because leverages existing family trust relationships
  • Good, because transforms backup from cost center to shared family resource
  • Good, because simple migration path from single-node homelab (just add peers)
  • Bad, because adds network management complexity vs. single-node solutions
  • Bad, because requires family/friend coordination for node enrollment
  • Bad, because backup restoration depends on network availability

Pros and Cons of the Options

Traditional homelab

  • Good, because simple single-node deployment and management
  • Good, because no network coordination required
  • Good, because maximum control over single system
  • Bad, because vulnerable to single-site disasters
  • Bad, because expensive to achieve true redundancy (requires separate hardware)
  • Bad, because no natural upgrade path to geographic distribution

Homelab + cloud backup

  • Good, because achieves offsite backup redundancy
  • Good, because single-node simplicity with cloud failover
  • Bad, because ongoing cloud storage costs
  • Bad, because vendor lock-in to cloud provider
  • Bad, because trust shifted to corporations
  • Bad, because no network effects (isolated solution)

Distributed backup network

  • Good, because true disaster resilience without cloud costs
  • Good, because leverages family trust relationships instead of corporate contracts
  • Good, because creates network effects (more valuable with more participants)
  • Good, because shared operational burden across family members
  • Good, because natural growth path (start with MVP 3-node configuration, add more over time)
  • Bad, because network management complexity
  • Bad, because requires coordination between family members
  • Bad, because backup restoration depends on peer availability

Implementation for MVP

Scope: Focus on pure backup replication between family nodes, not general homelab services.

Enrollment: Manual key distribution by admin, explicit peer list management.

Replication: Full replication of each node's backup data with incremental efficiency.

Storage allocation: Each node reserves space for both local backups and peer replicas.

Network topology: Mesh - all nodes replicate directly to all other nodes.

MVP trade-offs: Full replication may cause capacity mismatches (large node backing up to small node) and storage exhaustion from overuse. These limitations are acceptable for MVP validation and will be addressed by migrating to erasure coding in future releases.

Migration path: Start simple with full replication, migrate to erasure coding when storage efficiency becomes critical.